Add knowledge-backed AL development

[Jesper Schulz-Wedde (JesperSchulz)]

Summary

• add al-development-plan, a read-only interface that turns existing AL development plans into referenced BCQuality constraints
• add al-development, which applies those constraints to features, bug fixes, refactors, upgrades, and maintenance before the existing AL review gate
• ingest seven Microsoft Learn-derived knowledge articles and correct ApplicationArea inheritance guidance
• add Microsoft Learn coverage tracking plus review, development, and planning evaluation fixtures

Specialized orchestrator boundary

Repository-specific workflows such as BCAppsBugFix retain ownership of issue intake, TDD baselines, AL container tooling, MiApp propagation, critique, commits, and pull requests. They can invoke al-development-plan after their own planning phase and feed its read-only guidance report into implementation, while keeping their existing BCQuality-backed final review gate.

The guidance fixtures now include the exact BCFIX-HANDOFF v1 shape (rootCause, harnessMap, iterationsUsed, filesCommitted, lastTestResult, deadEnds, and nextStep) plus a separate upgrade-planning case.

Review feedback addressed

• bound the post-implementation review/fix loop to three rounds with convergence detection and partial non-convergence output
• include each action skill's output kind in Entry dispatch so consumers can identify repository-changing work before invocation
• enforce a 50% fixture-backed capability floor and add install/upgrade coverage
• define and evaluate explicit BCFIX-HANDOFF v1 normalization
• make no-knowledge an intentional, actionable refusal without code changes
• reject absolute, malformed, and repository-escaping skill paths

The BCAppsBugFix team is specifically invited to review this boundary and propose changes if the contract still does not fit their roadmap.

Validation

• frontmatter and action-skill schema validation
• deterministic knowledge-index validation
• 34 review fixtures across 17 review domains
• Microsoft Learn coverage-ledger validation
• 5 development fixtures covering 5 of 10 tracked capabilities, with the 50% floor enforced
• 2 read-only development-guidance fixtures, including BCFIX-HANDOFF v1
• positive, malformed-result, traversal, and bounded-review scoring probes

[github-actions]

👋 Heads up Jesper Schulz-Wedde (@JesperSchulz) — and cc maintainers — this PR introduces new top-level entries that aren't part of BCQuality's known repository structure:

• 📁 coverage/ (new top-level folder)
• 📁 evaluation/ (new top-level folder)

This isn't a block — just a flag. 🚩 New top-level folders and files are usually unintended (a stray export, a tool's scratch dir, or content that meant to land inside an existing layer like /community/knowledge/). BCQuality keeps a deliberately small root: .github/, community/, custom/, microsoft/, skills/, and tools/, plus a handful of root docs.

If this was intentional and the new entry genuinely belongs at the repo root, a maintainer can review and merge as normal — no action needed beyond a quick sanity check. If it wasn't, please move the content into the right existing layer (or drop it) and push an update. 🙏

A maintainer will take a look before merging.