Add read-only AL development plan guidance

[Jesper Schulz-Wedde (JesperSchulz)]

Summary

Narrow this PR to the shared, read-only foundation for knowledge-backed AL authoring. Existing development and bug-fix workflows retain ownership of execution.

• Add al-development-plan and its host-native adapter: enrich an existing plan and repository context with referenced BCQuality constraints, companion samples, validation considerations, and unresolved applicability.
• Keep seven developer-knowledge articles, the ApplicationArea inheritance correction, and their review-skill integration.
• Retain output-kind dispatch metadata and reference/path hardening while preserving the existing findings-report contract.
• Remove the generic implementation skill/adapter, implementation-report and review/fix-loop policy, implementation fixtures/scorer, capability-percentage claims, and ancillary Learn catalog/ingestion tracking.

Consumer boundary

The proposed flow is: existing analysis and normalized plan -> read-only BCQuality guidance -> existing implementation phases -> independent final BCQuality review -> delivery.

Consumer-specific plan and continuation-state normalization stays in the consumer. The fixtures use a synthetic metadata-and-Markdown initial plan rather than treating BCFIX-HANDOFF as the normal planning interface. BCQuality does not own TDD, environment provisioning, retries, state, propagation, critique, commits, or PR creation.

no-knowledge means no additional applicable BCQuality constraints, not that the change is unsafe or unimplementable. Consumers retain their ordinary gates and own handling of partial, failed, and materially unresolved guidance.

Consumers should persist guidance within their own state lifecycle, re-enrich when the plan materially changes, and record/verify the same immutable BCQuality checkout and filtering policy for guidance and final review. This PR does not implement consumer uptake or establish that a configured ref is enforced at runtime.

Evaluation and evidence

• Add runner-owned, outside-workspace baseline capture and a runner-retained digest for scoring. Compare repository identity, HEAD/refs/index, tracked/untracked/ignored content, and stable metadata; reject unsupported filesystem layouts rather than follow escapes.
• Add 5 guidance fixtures and 98 credential-free evaluator regression checks, including repository mutations, malformed results, path/reference integrity, and distinct guidance outcomes.
• Local frontmatter validation reports no errors/warnings; the deterministic knowledge index contains 307 articles; existing 34 review fixtures across 17 domains pass.
• Wire guidance preparation and evaluator regressions into Ubuntu and Windows CI.

These checks establish contract/scorer behavior, not improved generated code. Snapshot comparison is not a sandbox or a monitor of reverted transient writes; it cannot prove that articles were opened or prose constraints are semantically faithful. Real model/runtime evidence remains separate.

Explicit follow-up

• Agree the input/output contract and insertion point with the consuming bug-fix workflow owners.
• Implement consumer-owned guidance persistence and phase injection, with verified runtime pinning.
• Run a reproducible pilot against pinned baselines, comparing repairs with and without early guidance for correctness, avoided late findings, unnecessary changes, and cost.
• Reconsider standalone authoring only after the shared interface and consumer benefit are demonstrated.

Consumer rollout and the authoring-quality pilot are not completed or claimed by this PR.

[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.