docs: restore long-term Strategy and separate six-month horizons

docs/strategy/roadmap.mdx

@@ -1,7 +1,7 @@
 ---
 id: roadmap
 title: Roadmap
-description: Proposed month-by-month work, capacity, dependencies and decisions for a solo AI Architect.
+description: Build proven skills in human and AI Agent work, starting with Delivery, as the foundation for the future autonomous SDLC.
 hide_table_of_contents: true
 ---
 
@@ -9,45 +9,37 @@ import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
 
 <div className="strategy-content">
 
-## Six months, two investment decisions
+## Two stages toward the long-term Target
 
-<ArchifyDiagram name="strategy-roadmap" title="Proposed months 1–4: learn and test; months 5–6: retain or stop, then hand over" story />
+<ArchifyDiagram name="strategy-roadmap" title="Adopt skills → Future Autonomous Agent" story />
 
-**Humans direct, guide and review throughout.** This is a proposed plan, not an agreed schedule or budget. The first decision funds one bounded experiment; the second retains, changes or stops it before any transfer. The [six-month strategy](./target-operating-model.mdx) starts with existing uneven AI-assisted practice, not zero adoption. A Target operating model is only a conditional long-term reference.
+**Humans direct, guide and review throughout.** Stage 1 standardizes skills in human + AI Agent work across the SDLC. Proven skills, measurements and working practices become the foundation for Stage 2: the future Autonomous Agent in [Target](./target-operating-model.mdx).
 
-**Month 1 — Discover and earn trust.** I agree CTO expectations, access and a monthly decision meeting; meet team leads, pair with developers and reviewers across contrasting workflows, and trace recent changes. Output: current-work map, AI/tool/data constraints, evidence gaps and ranked bottlenecks. Dependency: willing access to real work. Decision: select a problem, or continue targeted discovery rather than prescribe skills.
+This is the broad progression, not a month-by-month schedule. The [6 Months Target](./six-months-target.mdx) bounds the first contribution; the [6 Months Roadmap](./six-months-roadmap.mdx) owns the concrete action plan.
 
-**Month 2 — Agree one experiment.** I recruit one willing team and an independent reviewer, observe a prospective baseline and compare context, coaching, test/review feedback, deterministic automation and skills. Output: the [experiment packet](./stage-01-skills-adoption.mdx), effort cap, acceptance rules and stop date. Dependency: team lead agrees contributions; actual risk/approval owners clear the boundary. No partner, reliable checks or lawful evidence means no live pilot.
+Target operating model—not deployed autonomy, an agreed schedule or approved KPI thresholds. Stage 1 is useful in its own right; Stage 2 requires a separately justified change in authority, not graduation for using enough skills.
 
-**Month 3 — Work beside the team.** I build and qualify the smallest intervention, pair on bounded changes and collect outcomes plus burden. Output: reproducible examples, failure cases and weekly evidence review. Dependency: independent qualification and explicit pilot permission, not tool installation. Stop unsafe work immediately; fix friction before asking others to adopt.
+## Stage 1: Delivery first
 
-**Month 4 — Compare and choose.** I reconcile matured tasks, defects, review effort, costs and concurrent changes with the reviewer. Output: retain/change/hold/stop recommendation to the workflow owner and CTO. Dependency: comparable matured tasks and reconciled sources. Low task supply or missing follow-up means inconclusive, not success. Only an approved time-and-budget-bounded extension may continue; otherwise narrow or stop.
+<ArchifyDiagram name="strategy-roadmap-adoption" title="Delivery first → Other SDLC phases, order undecided" story />
 
-**Month 5 — Transfer selectively.** If value and burden are acceptable, I pair with a voluntary champion and backup and test a second willing team's fit. Output: a team-owned example, support/recovery instructions and a new-scope baseline. Dependency: team capacity and funded upkeep. If absent, improve the first workflow or retire it; no organization-wide training mandate.
+Start with Delivery, then extend skills adoption to the remaining SDLC phases. Their order is not yet decided. **Delivery keeps improving as adoption expands.**
 
-**Month 6 — Handover and CTO evidence review.** I verify that the team can operate without daily architect help and present outcomes, limits, costs and stopped work. Output: an owned retained workflow or documented stop, plus a prioritized next-quarter proposal. Dependency: independent evidence and actual owner acceptance. The CTO decides the next investment, not an automatic autonomy phase.
+## Improve within each phase
 
-## Delivery first, replication only if earned
+<ArchifyDiagram name="strategy-roadmap-loop" title="Each phase: understand → baseline → topology → use → collect → reassess → repeat" story />
 
-<ArchifyDiagram name="strategy-roadmap-adoption" title="One willing Delivery team → a separately agreed transfer, or stay and improve" story />
+Repeat this loop within every phase—not as six global roadmap stages. Skills topology defines **what skills exist, how they relate, when they are used and how they work together**, including handoffs—not just a catalogue.
 
-**Delivery keeps improving** whether transfer happens or not. The order of any other workflows is not yet decided. I bring concrete examples to skeptical teams, ask what creates extra work, and accept non-participation. A skeptic can help judge a demo without joining a pilot. If priorities conflict, I ask the CTO for a trade-off, not a compliance escalation.
+## Delivery in practice
 
-## Keep one learning loop
+**Understand the engineering path first:** codebase structure and existing principles → system-logic source → tests → builds and packaging → deployments. Inspect actual practices, tooling, controls and problems with the people doing the work, rather than assuming the documented process is the real one.
 
-<ArchifyDiagram name="strategy-roadmap-loop" title="Understand current AI work → baseline → choose intervention → bounded pilot → evidence → retain, change or stop" story />
+**Establish the comparison, then choose the intervention.** Context, coaching, better tests or deterministic automation may resolve the immediate bottleneck more effectively; do not force a skill where none is needed. Select relevant metrics/KPIs and a baseline for comparable work before changing it. [Measurement](./measurement/index.mdx) supplies optional definitions; [Baseline](./baseline.mdx) records the actual starting position or gaps. Connect skills to the engineering path, with clear triggers, dependencies and acceptance checks; [Quality](./skills-quality.mdx) qualifies the candidate before bounded real use.
 
-Repeat the learning loop, not a predetermined tool rollout. If skills are selected, their topology defines what skills exist, how they relate, when they are used and how they work together. Simpler context, coaching or deterministic fixes do not require a skills catalog.
+**Use, collect, compare, repeat.** A human works with an AI Agent on real changes. Collect results, friction and feedback alongside quality, cost and verification effort. Compare with the baseline to understand the new current situation; retain, improve, stop or propose expansion. Changed revisions return to qualification; changed workflows need a fresh comparison.
 
-## Solo capacity and influence
-
-Proposed weekly allocation during pilots: two days hands-on pairing/building, one day evaluation/evidence, one day coaching and relationships, and one day sponsor decisions, support and contingency. One active live pilot at a time; a second team starts only after the first is supportable. This is a capacity envelope, not known company availability.
-
-Ask a partner lead to agree a small pairing slot and independent review time explicitly; record actual effort, not assumed free team labor. Agree a short weekly team check-in and monthly CTO review of evidence, blocked dependencies, spend and the next choice. Seek specialist security/privacy advice only where the selected boundary requires it; preserve independent checks without appointing a committee.
-
-Trace codebase structure and existing principles → system-logic source → tests → builds and packaging → deployments. Repair critical acceptance/data gaps before live use. Publish short reusable examples and offer office hours; don't become a permanent help desk for more than ten teams. Escalate support demand as an investment choice, never hide it in apparent savings.
-
-Follow the **illustrative Delivery workflow** in [the experiment packet](./stage-01-skills-adoption.mdx). Its diagram and worked decision keep benefit, burden and safety connected. [Measurement](./measurement/index.mdx) supplies optional definitions; [Baseline](./baseline.mdx) records actual starting evidence. Governance and Measurement are supporting references, not one-time gates.
+Follow the **illustrative Delivery workflow** in [Stage 01](./stage-01-skills-adoption.mdx): prepare a bounded code change and regression tests, then hand the exact artifact to independent review. Its dependency diagram shows what passes between activities and who decides whether work can progress. Governance and Measurement support the whole loop; they are not one-time gates.
 
 <details>
 <summary>Readiness questions behind the roadmap</summary>
@@ -64,7 +56,7 @@ Inventory actual client hosts/builds, provider/data terms, authority and event a
 
 Close critical gaps such as exposed secrets, unclear approval authority or unreliable acceptance checks. Broader refactoring and non-critical debt can run alongside the selected work. Stage 1 introduces no new privileged autonomous actions.
 
-### If skills are the chosen intervention
+### Engineer and evaluate connected skills
 
 Use a small registry, immutable skill contracts, qualified client adapters, evaluations and coaching. Verify the measurement calculations with synthetic fixtures before interpreting real outcomes. Require mandatory safety checks, independent task acceptance, reconciled source coverage and user feedback. Hold or narrow scope if quality or coverage is inadequate; usage alone does not justify expansion.
 
@@ -74,12 +66,12 @@ Prove canary updates, effective-version readback, version locking, exception exp
 
 Use evidence to choose the next SDLC phase; no second or third phase is assigned here. Continue the improvement loop in Delivery and every phase already using skills.
 
-### Consider autonomy only as a separate future option
+### Prepare for the future Autonomous Agent
 
-Beyond six months may mean deeper coaching, deterministic tooling or no expansion. If additional autonomous authority solves an evidenced problem, [future options](./stage-02-autonomous-agent.mdx) require a separate authority/readiness decision. Recommended controls include exact-artifact approvals, idempotency, duplicate/outage recovery, separation of duties, audit and kill-switch drills. Prove human takeover; never infer permission from missing evidence. Keep sensitive decisions human. Changed client, provider, data or authority boundaries reopen the relevant checks.
+Stage 2 builds on proven skills, measurements and working practices—not permission inferred from adoption alone. [Beyond 6 Months](./stage-02-autonomous-agent.mdx) owns the separate authority/readiness decision. Recommended controls include exact-artifact approvals, idempotency, duplicate/outage recovery, separation of duties, audit and kill-switch drills. Prove human takeover; never infer permission from missing evidence. Keep sensitive decisions human. Changed client, provider, data or authority boundaries reopen the relevant checks.
 
 </details>
 
-**Next:** [Work through one bounded experiment →](./stage-01-skills-adoption.mdx)
+**Next:** [6 Months Target →](./six-months-target.mdx)
 
 </div>