Development plan proposal

[manul7]

I would like to propose a development plan for the MVP system that can process unit-test regressions (the simplest case). The plan is based on the content and assumptions of the proposal/components PR.

Structure

• planning/plan.yaml defines 18 phases (or epics) and tasks. It is the single source of truth for task metadata and dependencies.
• Each task has its own file under planning/tasks/ with a description, contribution, acceptance criteria, and links to its design sources.
• Phases composed in recommended execution order, not completion barriers. A task may start as soon as its own dependencies are complete.

Phases

• Phases 1–2 fix the design groundwork: the dev environment, the unit-test CR fields, and the BCO and BTO OpenAPI specs.
• Phases 3–8 build the components in parallel across streams: BCO, BTO, Commit selector, Decision engine, Results Analyzer, and execution adapters. I assume that results analyzer can be reused from other parts of the existing KCI system or LKFT.
• Phases 9–11 close the campaign loop. Each phase is one milestone rather than a parallel batch; dependencies inside those phases are serial by design.
• Phase 12 proves the minimal unit-test path end to end.
• Phase 13 checks the MVP contract rules for that path.
• Phase 14 defines the admission, limit, cancellation, auth, and recovery rules, and runs one MVP campaign executor.
• Phases 15–16 enforce those rules and add duplicate prevention and restart recovery.
• Phases 17–18 test cancellation and crash recovery, ending with a crash during BTO backend work.

In other words, phases 1-10 = core machinery, 11-13 = MVP completion, 14–18 = hardening.

Tooling

• scripts/publish-tasks.py creates one GitHub issue per task marked publish: true, labeled with its phase. It also links each published task to its published dependencies with blocked-by relationships, so the issue graph mirrors depends_on in plan.yaml. Re-runs are idempotent. A dependency without a published issue is reported and
  skipped, and gets linked on a later run once its issue exists.
• .github/workflows/publish-tasks.yml runs the script on every push to main that touches planning/plan.yaml, the task files, or the script itself.

Please take a look.