feat(cli): emit rules in Kilo flat builds #868

Problem

Kilo flat support was delivered by #744 and PR #745, but buildKiloFlatContract() still marks plugin rules/ as unsupported. A framework archive produced by aidd framework build --target kilo --flat therefore omits canonical plugin Rules even though Kilo can load Markdown Rules referenced from kilo.json[c].instructions.

This is separate from #914, which owns direct Kilo-native generation inside a host project. This issue owns flat archive distribution.

Scope

• Materialize canonical all-files plugin Rules, meaning Rules without paths, as collision-free, plugin-namespaced Markdown under the Kilo Rules location resolved by the Kilo profile.
• Merge the generated Rule references into the instructions array of the resolved Kilo project configuration.
• Preserve every pre-existing instructions value and its relative order. Generated entries are appended in deterministic order.
• Keep repeated builds idempotent: generated files and instruction entries remain stable and are never duplicated.
• Preserve Rule content and rewrite relative links for the materialized location.
• Reject a canonical Rule containing paths with an explicit build error that identifies the Rule and its unsupported scope. Never silently drop its scope or broaden it into an all-files Rule.
• Cover JSON and JSONC configuration, existing instructions, multiple plugins, repeated builds, an unsupported path-scoped Rule, and a flat archive installed into a clean project.

Configuration preservation is semantic: existing values and instruction ordering are preserved, but JSONC comments and formatting may be reserialized.

Acceptance criteria

• An all-files plugin Rule is emitted under the Kilo Rules location and referenced from the resolved kilo.json[c].instructions.
• Existing user-owned instructions values remain unchanged and in the same relative order.
• Generated instruction entries use deterministic, collision-free paths and follow the existing user-owned entries.
• Rebuilding creates neither duplicate Rule files nor duplicate instruction entries.
• A Rule containing paths fails the build with a diagnostic naming the Rule and its unsupported scope; it is not emitted or referenced.
• Relative links in an emitted Rule still resolve after materialization.
• A supported Kilo runtime discovers and applies the generated all-files Rule from a clean installed archive.

Relations

• feat(cli): add Kilo Code support #744 and PR feat(cli): add Kilo Code support #745 are completed prerequisites that provide the Kilo profile, configuration resolution, and runtime contract.
• feat(aidd-context): add Kilo-native generation targets #914 owns direct Kilo-native context generation.
• feat(cli): emit rules and commands in OpenCode flat builds #789 owns OpenCode flat Rule and command distribution. It may share a generic flat-Rule implementation seam with this issue, but neither feature blocks the other.

References

• Kilo custom Rules: https://kilo.ai/docs/customize/custom-rules
• Kilo migration and Rule-scope limitations: https://kilo.ai/docs/getting-started/migrating
• Verified: 2026-09-24

Out of scope

• Translating path-scoped Rules into Kilo custom modes.
• Direct artifact generation in a project, owned by feat(aidd-context): add Kilo-native generation targets #914.
• Kilo flat command distribution. Kilo supports Markdown workflows, but that is a separate feature.
• Changes to Kilo lifecycle hooks or plugins delivered by feat(cli): add Kilo Code support #744.