Open Problems

The Full Integration stage assumes a separate harness workspace and production repo, with a sync pipeline between them. Teams that run a single repo on trunk don't have that boundary — the promotion flow doesn't apply. Candidates under consideration: short-lived branches off trunk, stacked changes, or a different mental model for what "production ready" means when you're already in production. Unresolved.

In a multi-repo setup, steering document changes pass through the harness repo's own review before they affect anything. In a single-repo trunk shop, a steering change lands in main and immediately steers every agent interaction. How formal does that review need to be, and who owns it? The governance model for this case isn't settled.

The harness is generated from a specification by whatever agent the org has approved. The spec includes a conformance checklist the generating agent must self-verify — but how much generated output varies across agents and model versions, and where the spec needs to be more prescriptive to prevent drift, is still being mapped. The honest answer today: the spec has been validated, but not yet against every agent an org might bring.

Full Integration means PM-originated, agent-generated, validated components entering production branches. Engineering cultures vary enormously in their readiness for that — and the framework currently reads that readiness through judgment, not instrumentation. What observable signals reliably indicate a team is ready (or isn't) remains an open question. The current guidance — default to Production Connection until engineering leads the move — is a safe heuristic, not a measure.

The framework comes from sustained practice, and the early signal is what motivated building it. What doesn't exist yet is longitudinal, multi-org outcome data — cycle time, rework rates, decision quality across adoptions over time. Every methodology starts here; pretending otherwise is the failure mode this page exists to avoid. As engagements produce measured outcomes, the strongest of them belong here, with their limitations stated.

The discovery nodes scale by the size and risk of the work — but purely exploratory initiatives (no committed outcome, no timeline) sit awkwardly in any structured model. When structure helps exploration and when it strangles it is a judgment the framework currently leaves entirely to the PM. Whether it should offer more is open.

The repo structure — feature-folders, a small working set, an archive — holds cleanly for one team on one product. At ten teams the question is unanswered: one shared harness, or one per product with org-wide steering pulled in? The credible direction is shared, versioned steering that teams extend locally (the same trade-off as monorepo vs. polyrepo in code) — but what is genuinely org-wide versus team-local, how shared steering versions and propagates without a central bottleneck, and how a team overrides a standard without forking it, are not specified. The framework today is implicitly single-team. The multi-team federation model is open.

At the Production Connection stage the harness mirrors part of the production codebase so generated components match what ships. That only works if the mirror stays a staging area for components actively in flight — pulled in to prototype, removed once production becomes their home of record. If it instead accumulates into a standing copy of production, it diverges, and a stale mirror steers the agent toward patterns engineering has already moved past — worse than no mirror. The discipline that keeps the mirror transient, and a reliable way to detect drift between mirror and production, are not yet fully specified. Today this rests on team discipline, which is exactly the kind of unenforced convention this framework otherwise tries to replace.