fix: label slide 13 as an example weekly allocation

.gitignore

@@ -6,3 +6,4 @@ build/
 .env.*
 !.env.example
 static/diagrams/
+static/presentations/

README.md

@@ -31,6 +31,10 @@ Top-level sections are Organization, Strategy, and Contribution, each with an in
 
 Archify 3.0.1 is vendored under `vendor/archify/` from commit `d5a1333d7447c866a765adac7d4d062f2f02e4d2`. MIT and third-party notices are preserved. `diagrams/` holds editable JSON; `pnpm diagrams:build` validates and generates local standalone viewers before every site build. The iframe is sandboxed without same-origin permission. See `docs/contribution/diagrams.md` for capability analysis, authoring, boundaries, and upgrade procedure.
 
+The build checks upstream provenance before applying the portal integration: `scripts/inline-viewer.css` restores compact embed controls, two guarded preset restrictions are removed from generated viewers only, and `scripts/viewer-theme-bridge.js` synchronizes theme with the portal through source-validated messages. Vendor files remain unchanged. Delivery receipts describe the upstream artifact before this integration, not the final served bytes. Theme changes do not reload viewers or discard visual presets. PNG, JPEG, WebP and SVG downloads remain available; browser-dependent exports stay disabled when unsupported.
+
+For interaction acceptance, serve the production build on port 4173 and run `pnpm test:browser` with an installed Playwright Chromium (or `PLAYWRIGHT_CHROMIUM_EXECUTABLE`). This checks story layouts, portal/diagram theme synchronization, all four presets, actual exported artifact decoding, route changes, and fullscreen click/Escape/focus behavior at desktop and mobile widths. Screenshots, downloads and results are saved under ignored `.cache/` directories.
+
 ## Design
 
 Inspired by https://www.eldorado.gg/: Lato, near-black navigation, charcoal, gold `#ffc950`, light panels, bold headings. Original documentation artwork and square panels; no official marketplace assets or business claims. See `docs/core/reference.md`.

diagrams/ai-adoption-target.architecture.json

@@ -0,0 +1,39 @@
+{
+  "schema_version": 1,
+  "diagram_type": "architecture",
+  "meta": {"title": "TO-BE: governed AI adoption", "output": "static/diagrams/ai-adoption-target/index.html", "quality_profile": "showcase"},
+  "components": [
+    {"id":"people","type":"external","label":"Accountable people","sublabel":"Existing teams; approved work","pos":[40,80],"size":[240,80]},
+    {"id":"coordinator","type":"backend","label":"One SDLC coordinator","sublabel":"Data & AI; durable task ledger","pos":[440,80],"size":[240,80]},
+    {"id":"registry","type":"database","label":"Governed skills registry","sublabel":"Pinned bundles + qualified adapters","pos":[840,80],"size":[260,80]},
+    {"id":"provider","type":"cloud","label":"Model providers","sublabel":"Approved data + retention terms","pos":[40,340],"size":[240,80]},
+    {"id":"clients","type":"frontend","label":"Local laptop contributors","sublabel":"Copilot / Claude Code / Cline","pos":[440,340],"size":[240,80]},
+    {"id":"gates","type":"security","label":"Repository + CI gates","sublabel":"Independent exact-revision checks","pos":[440,600],"size":[240,80]},
+    {"id":"approval","type":"external","label":"Human release approval","sublabel":"Exact artifact; scoped; expires","pos":[840,600],"size":[260,80]},
+    {"id":"release","type":"security","label":"Release service","sublabel":"Production credentials only here","pos":[840,860],"size":[260,80]},
+    {"id":"audit","type":"database","label":"Audit + measurement","sublabel":"Restricted evidence; feedback","pos":[40,860],"size":[240,80]}
+  ],
+  "boundaries": [
+    {"kind":"security-group","label":"Supply-chain review","wraps":["registry"]},
+    {"kind":"security-group","label":"Data / egress boundary","wraps":["provider"]},
+    {"kind":"security-group","label":"Untrusted local proposals","wraps":["clients"]},
+    {"kind":"security-group","label":"Independent delivery authority","wraps":["gates","approval","release"]}
+  ],
+  "connections": [
+    {"id":"approved-work","from":"people","to":"coordinator","label":"Authorize scope","variant":"security"},
+    {"id":"coord-skills","from":"registry","to":"coordinator","label":"Pinned skills"},
+    {"id":"task-proposals","from":"coordinator","to":"clients","label":"Route tasks","variant":"dashed"},
+    {"id":"local-skills","from":"registry","to":"clients","label":"Qualified bundle","fromSide":"bottom","toSide":"right"},
+    {"id":"inference","from":"clients","to":"provider","label":"Allowed data","variant":"security"},
+    {"id":"proposals","from":"clients","to":"gates","label":"Propose changes","variant":"dashed"},
+    {"id":"evidence","from":"gates","to":"approval","label":"Verified evidence"},
+    {"id":"authorize","from":"approval","to":"release","label":"Approve artifact","variant":"security"},
+    {"id":"outcomes","from":"release","to":"audit","label":"Outcome evidence"},
+    {"id":"feedback","from":"audit","to":"people","label":"Review outcomes","variant":"dashed"}
+  ],
+  "cards": [
+    {"dot":"cyan","title":"Target, not deployed","items":["One logical coordinating function; resilient ledger and human takeover.","Registry content is guidance, not authority. No laptop or coordinator production credentials."]},
+    {"dot":"rose","title":"Human authority","items":["Department leaders retain accountability; independent reviewers accept actual artifacts.","CI and release controls fail closed; approval is bound to the exact revision."]},
+    {"dot":"emerald","title":"Evidence loop","items":["Audit feedback informs people and the next authorized coordinator task.","Approved provider routing applies to coordinator and local inference; no silent policy-changing fallback."]}
+  ]
+}

diagrams/organization-reporting.architecture.json

@@ -77,7 +77,7 @@
       "id": "engineers",
       "type": "frontend",
       "label": "Software engineers",
-      "sublabel": "Product Engineering teams",
+      "sublabel": "Product Engineering team",
       "pos": [
         1480,
         40
@@ -220,10 +220,10 @@
     },
     {
       "dot": "amber",
-      "title": "Cross-functional execution",
+      "title": "Interdepartmental collaboration",
       "items": [
         "Product Owners, Designers and Tech Leads align on product outcomes.",
-        "AI Enablement works across engineering teams."
+        "Data & AI enables AI adoption across Technology."
       ]
     }
   ]

diagrams/organization-structure.architecture.json

@@ -23,7 +23,7 @@
       "label": "Management",
       "sublabel": "CEO / COO",
       "pos": [
-        680,
+        820,
         40
       ],
       "size": [
@@ -37,11 +37,11 @@
       "label": "Product",
       "sublabel": "Experience and product outcomes",
       "pos": [
-        600,
+        40,
         280
       ],
       "size": [
-        240,
+        280,
         80
       ]
     },
@@ -51,11 +51,11 @@
       "label": "Technology",
       "sublabel": "Engineering and platform",
       "pos": [
-        880,
+        360,
         280
       ],
       "size": [
-        240,
+        280,
         80
       ]
     },
@@ -65,11 +65,11 @@
       "label": "Operations",
       "sublabel": "Service, resolution and trust",
       "pos": [
-        40,
+        680,
         280
       ],
       "size": [
-        240,
+        280,
         80
       ]
     },
@@ -79,11 +79,11 @@
       "label": "Marketing",
       "sublabel": "Brand and customer growth",
       "pos": [
-        320,
+        1000,
         280
       ],
       "size": [
-        240,
+        280,
         80
       ]
     },
@@ -93,11 +93,11 @@
       "label": "Finance & Accounting",
       "sublabel": "Financial performance and controls",
       "pos": [
-        1160,
+        1320,
         280
       ],
       "size": [
-        240,
+        280,
         80
       ]
     },
@@ -107,123 +107,165 @@
       "label": "HR & Administration",
       "sublabel": "People and workplace",
       "pos": [
-        1440,
+        1640,
         280
       ],
       "size": [
-        240,
-        80
-      ]
-    },
-    {
-      "id": "shared-delivery",
-      "type": "frontend",
-      "label": "Product & Technology Squads",
-      "sublabel": "Up to seven cross-functional squads",
-      "pos": [
-        660,
-        520
-      ],
-      "size": [
-        360,
-        80
-      ]
-    },
-    {
-      "id": "squad-discovery",
-      "type": "frontend",
-      "label": "Discovery & Categories",
-      "sublabel": "Browse, search and conversion",
-      "pos": [
-        40,
-        760
-      ],
-      "size": [
-        200,
-        80
-      ]
-    },
-    {
-      "id": "squad-orders",
-      "type": "frontend",
-      "label": "Orders & Delivery",
-      "sublabel": "Purchase and post-purchase",
-      "pos": [
         280,
-        760
-      ],
-      "size": [
-        200,
         80
       ]
     },
     {
-      "id": "squad-seller",
+      "id": "product-team-1",
       "type": "frontend",
-      "label": "Seller Platform",
-      "sublabel": "Seller tools and integrations",
+      "label": "Product Management",
+      "sublabel": "Strategy, priorities and outcomes",
       "pos": [
-        520,
-        760
+        100,
+        480
       ],
       "size": [
-        200,
+        220,
         80
       ]
     },
     {
-      "id": "squad-payments",
+      "id": "product-team-2",
       "type": "frontend",
-      "label": "Payments & Wallet",
-      "sublabel": "Checkout, balances and payouts",
+      "label": "Product Design",
+      "sublabel": "Research and experience design",
       "pos": [
-        760,
-        760
+        100,
+        620
       ],
       "size": [
-        200,
+        220,
         80
       ]
     },
     {
-      "id": "squad-trust",
+      "id": "technology-team-1",
       "type": "frontend",
-      "label": "Trust & Safety",
-      "sublabel": "Risk and resolution tooling",
+      "label": "Product Engineering",
+      "sublabel": "Marketplace software delivery",
       "pos": [
-        1000,
-        760
+        420,
+        480
       ],
       "size": [
-        200,
+        220,
         80
       ]
     },
     {
-      "id": "squad-data",
+      "id": "technology-team-2",
       "type": "frontend",
-      "label": "Data & Intelligence",
-      "sublabel": "Ranking, analytics and ML",
+      "label": "Platform & IT",
+      "sublabel": "Reliability and internal systems",
       "pos": [
-        1240,
-        760
+        420,
+        620
       ],
       "size": [
-        200,
+        220,
         80
       ]
     },
     {
-      "id": "squad-platform",
+      "id": "technology-team-3",
       "type": "frontend",
-      "label": "Platform & AI",
-      "sublabel": "Reliability and engineering AI",
+      "label": "Architecture & Security",
+      "sublabel": "Technical standards and protection",
       "pos": [
-        1480,
+        420,
         760
       ],
       "size": [
-        200,
+        220,
+        80
+      ]
+    },
+    {
+      "id": "technology-team-4",
+      "type": "frontend",
+      "label": "Quality Engineering",
+      "sublabel": "Testing and release quality",
+      "pos": [
+        420,
+        900
+      ],
+      "size": [
+        220,
+        80
+      ]
+    },
+    {
+      "id": "technology-team-5",
+      "type": "frontend",
+      "label": "Data & AI",
+      "sublabel": "Analytics, ML and AI enablement",
+      "pos": [
+        420,
+        1040
+      ],
+      "size": [
+        220,
+        80
+      ]
+    },
+    {
+      "id": "operations-team-1",
+      "type": "frontend",
+      "label": "Operations Squad",
+      "sublabel": "Service, resolution, risk and quality",
+      "pos": [
+        740,
+        480
+      ],
+      "size": [
+        220,
+        80
+      ]
+    },
+    {
+      "id": "marketing-team-1",
+      "type": "frontend",
+      "label": "Marketing Squad",
+      "sublabel": "Brand, acquisition and retention",
+      "pos": [
+        1060,
+        480
+      ],
+      "size": [
+        220,
+        80
+      ]
+    },
+    {
+      "id": "finance-team-1",
+      "type": "frontend",
+      "label": "Finance & Accounting Squad",
+      "sublabel": "Planning, controls and payments",
+      "pos": [
+        1380,
+        480
+      ],
+      "size": [
+        220,
+        80
+      ]
+    },
+    {
+      "id": "people-team-1",
+      "type": "frontend",
+      "label": "People & Administration Squad",
+      "sublabel": "Talent, people and workplace",
+      "pos": [
+        1700,
+        480
+      ],
+      "size": [
+        220,
         80
       ]
     }
@@ -233,140 +275,164 @@
       "id": "management-product",
       "from": "management",
       "to": "product",
-      "label": "Coordinates",
-      "variant": "default"
+      "variant": "default",
+      "fromSide": "bottom",
+      "toSide": "top"
     },
     {
       "id": "management-technology",
       "from": "management",
       "to": "technology",
-      "label": "Coordinates",
-      "variant": "default"
+      "variant": "default",
+      "fromSide": "bottom",
+      "toSide": "top"
     },
     {
       "id": "management-operations",
       "from": "management",
       "to": "operations",
-      "label": "Coordinates",
-      "variant": "default"
+      "variant": "default",
+      "fromSide": "bottom",
+      "toSide": "top"
     },
     {
       "id": "management-marketing",
       "from": "management",
       "to": "marketing",
-      "label": "Coordinates",
-      "variant": "default"
+      "variant": "default",
+      "fromSide": "bottom",
+      "toSide": "top"
     },
     {
       "id": "management-finance",
       "from": "management",
       "to": "finance",
-      "label": "Coordinates",
-      "variant": "default"
+      "variant": "default",
+      "fromSide": "bottom",
+      "toSide": "top"
     },
     {
       "id": "management-people",
       "from": "management",
       "to": "people",
-      "label": "Coordinates",
-      "variant": "default"
+      "variant": "default",
+      "fromSide": "bottom",
+      "toSide": "top"
     },
     {
-      "id": "product-squads",
+      "id": "product-1",
       "from": "product",
-      "to": "shared-delivery",
-      "label": "Shared delivery",
-      "variant": "default"
+      "to": "product-team-1",
+      "variant": "default",
+      "fromSide": "bottom",
+      "toSide": "left"
     },
     {
-      "id": "technology-squads",
+      "id": "product-2",
+      "from": "product",
+      "to": "product-team-2",
+      "variant": "default",
+      "fromSide": "bottom",
+      "toSide": "left"
+    },
+    {
+      "id": "technology-1",
       "from": "technology",
-      "to": "shared-delivery",
-      "label": "Shared delivery",
-      "variant": "default"
+      "to": "technology-team-1",
+      "variant": "default",
+      "fromSide": "bottom",
+      "toSide": "left"
     },
     {
-      "id": "delivery-discovery",
-      "from": "shared-delivery",
-      "to": "squad-discovery",
-      "label": "Squad",
-      "variant": "default"
+      "id": "technology-2",
+      "from": "technology",
+      "to": "technology-team-2",
+      "variant": "default",
+      "fromSide": "bottom",
+      "toSide": "left"
     },
     {
-      "id": "delivery-orders",
-      "from": "shared-delivery",
-      "to": "squad-orders",
-      "label": "Squad",
-      "variant": "default"
+      "id": "technology-3",
+      "from": "technology",
+      "to": "technology-team-3",
+      "variant": "default",
+      "fromSide": "bottom",
+      "toSide": "left"
     },
     {
-      "id": "delivery-seller",
-      "from": "shared-delivery",
-      "to": "squad-seller",
-      "label": "Squad",
-      "variant": "default"
+      "id": "technology-4",
+      "from": "technology",
+      "to": "technology-team-4",
+      "variant": "default",
+      "fromSide": "bottom",
+      "toSide": "left"
     },
     {
-      "id": "delivery-payments",
-      "from": "shared-delivery",
-      "to": "squad-payments",
-      "label": "Squad",
-      "variant": "default"
+      "id": "technology-5",
+      "from": "technology",
+      "to": "technology-team-5",
+      "variant": "default",
+      "fromSide": "bottom",
+      "toSide": "left"
     },
     {
-      "id": "delivery-trust",
-      "from": "shared-delivery",
-      "to": "squad-trust",
-      "label": "Squad",
-      "variant": "default"
+      "id": "operations-1",
+      "from": "operations",
+      "to": "operations-team-1",
+      "variant": "default",
+      "fromSide": "bottom",
+      "toSide": "left"
     },
     {
-      "id": "delivery-data",
-      "from": "shared-delivery",
-      "to": "squad-data",
-      "label": "Squad",
-      "variant": "default"
+      "id": "marketing-1",
+      "from": "marketing",
+      "to": "marketing-team-1",
+      "variant": "default",
+      "fromSide": "bottom",
+      "toSide": "left"
     },
     {
-      "id": "delivery-platform",
-      "from": "shared-delivery",
-      "to": "squad-platform",
-      "label": "Squad",
-      "variant": "default"
+      "id": "finance-1",
+      "from": "finance",
+      "to": "finance-team-1",
+      "variant": "default",
+      "fromSide": "bottom",
+      "toSide": "left"
+    },
+    {
+      "id": "people-1",
+      "from": "people",
+      "to": "people-team-1",
+      "variant": "default",
+      "fromSide": "bottom",
+      "toSide": "left"
     }
   ],
   "cards": [
-    {
-      "dot": "cyan",
-      "title": "Shared delivery squads",
-      "items": [
-        "Product owns priorities and outcomes; Technology owns engineering capability.",
-        "Each squad combines product ownership, engineering, design, QA and data skills.",
-        "Functional teams support squads; they are not extra delivery squads."
-      ]
-    },
     {
       "dot": "cyan",
       "title": "Product",
       "items": [
-        "Orders; Categories",
-        "Sellers & Operations",
-        "Data & Intelligence; Product Design"
+        "Product Management",
+        "Product Design"
       ]
     },
     {
       "dot": "amber",
       "title": "Technology",
       "items": [
-        "Product Engineering; Quality Engineering",
-        "Platform & Reliability; Architecture & Security",
-        "AI Enablement; Internal IT"
+        "Product Engineering",
+        "Platform & IT",
+        "Architecture & Security",
+        "Quality Engineering",
+        "Data & AI"
       ]
     },
     {
       "dot": "cyan",
       "title": "Operations",
       "items": [
+        "Operations Squad",
         "Customer Support; Trust & Resolution",
         "Risk & Fraud",
         "Operational Quality"
@@ -376,6 +442,7 @@
       "dot": "amber",
       "title": "Marketing",
       "items": [
+        "Marketing Squad",
         "Brand & Community; Creative; SEO",
         "PPC & Affiliate; Influencer",
         "CRM"
@@ -385,6 +452,7 @@
       "dot": "cyan",
       "title": "Finance & Accounting",
       "items": [
+        "Finance & Accounting Squad",
         "Financial Planning & Analysis",
         "Accounting, Tax & Controls",
         "Treasury & Payment Operations"
@@ -394,6 +462,7 @@
       "dot": "amber",
       "title": "HR & Administration",
       "items": [
+        "People & Administration Squad",
         "Talent Acquisition",
         "People Operations",
         "Office & Administration"

diagrams/strategy-adoption-mobile.architecture.json

@@ -0,0 +1,245 @@
+{
+  "schema_version": 1,
+  "diagram_type": "architecture",
+  "meta": {
+    "title": "TO-BE: Adoption",
+    "output": "static/diagrams/strategy-adoption-mobile/index.html",
+    "quality_profile": "showcase",
+    "legend": {
+      "mode": "hidden"
+    },
+    "viewBox": [
+      880,
+      2040
+    ]
+  },
+  "components": [
+    {
+      "id": "delivery",
+      "type": "external",
+      "label": "Delivery first",
+      "tag": "Start with a real workflow",
+      "sublabel": "Workflow baseline + canary",
+      "pos": [
+        60,
+        120
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "human",
+      "type": "backend",
+      "label": "Human",
+      "tag": "Direct + guide + review",
+      "sublabel": "Define outcome; inspect artifacts",
+      "pos": [
+        60,
+        1280
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "agent",
+      "type": "external",
+      "label": "AI Agent",
+      "tag": "Qualified client + authorized pilot",
+      "sublabel": "Produce work within the boundary",
+      "pos": [
+        60,
+        910
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "learn",
+      "type": "external",
+      "label": "Learn from real work",
+      "tag": "Ongoing, reviewed improvement",
+      "sublabel": "Feedback + selected measures\nRetain a manual path\nNo quotas or rankings",
+      "pos": [
+        60,
+        490
+      ],
+      "size": [
+        740,
+        270
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "expand",
+      "type": "backend",
+      "label": "Decide from evidence",
+      "tag": "Owner; new scope is separate",
+      "sublabel": "Retain / improve / hold / stop\nExpansion is a new proposal",
+      "pos": [
+        60,
+        1650
+      ],
+      "size": [
+        740,
+        240
+      ],
+      "icon": "none"
+    }
+  ],
+  "connections": [
+    {
+      "id": "delivery-agent",
+      "from": "delivery",
+      "to": "agent",
+      "label": "Practice",
+      "fromSide": "right",
+      "toSide": "right",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          850,
+          230.0
+        ],
+        [
+          850,
+          1020.0
+        ]
+      ],
+      "labelAt": [
+        780,
+        870
+      ]
+    },
+    {
+      "id": "human-agent",
+      "from": "human",
+      "to": "agent",
+      "label": "Direction",
+      "fromSide": "right",
+      "toSide": "right",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          824,
+          1390.0
+        ],
+        [
+          824,
+          1020.0
+        ]
+      ],
+      "labelAt": [
+        770,
+        1240
+      ]
+    },
+    {
+      "id": "agent-human",
+      "from": "agent",
+      "to": "human",
+      "label": "Work to inspect",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        610,
+        1185
+      ]
+    },
+    {
+      "id": "agent-learn",
+      "from": "agent",
+      "to": "learn",
+      "label": "Observe",
+      "fromSide": "top",
+      "toSide": "bottom",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        610,
+        815
+      ]
+    },
+    {
+      "id": "learn-delivery",
+      "from": "learn",
+      "to": "delivery",
+      "label": "Improve",
+      "fromSide": "left",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          42,
+          625.0
+        ],
+        [
+          42,
+          230.0
+        ]
+      ],
+      "labelAt": [
+        620,
+        80
+      ]
+    },
+    {
+      "id": "human-expand",
+      "from": "human",
+      "to": "expand",
+      "label": "Accepted work",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        610,
+        1555
+      ]
+    },
+    {
+      "id": "learn-expand",
+      "from": "learn",
+      "to": "expand",
+      "label": "Feedback",
+      "fromSide": "left",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          20,
+          625.0
+        ],
+        [
+          20,
+          1770.0
+        ]
+      ],
+      "labelAt": [
+        620,
+        1610
+      ]
+    }
+  ]
+}

diagrams/strategy-adoption.architecture.json

@@ -0,0 +1,243 @@
+{
+  "schema_version": 1,
+  "diagram_type": "architecture",
+  "meta": {
+    "title": "TO-BE: Adoption",
+    "output": "static/diagrams/strategy-adoption/index.html",
+    "quality_profile": "showcase",
+    "legend": {
+      "mode": "hidden"
+    },
+    "viewBox": [
+      2040,
+      1160
+    ]
+  },
+  "components": [
+    {
+      "id": "delivery",
+      "type": "external",
+      "label": "Delivery first",
+      "tag": "Start with a real workflow",
+      "sublabel": "Workflow baseline + canary",
+      "pos": [
+        60,
+        350
+      ],
+      "size": [
+        470,
+        210
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "human",
+      "type": "backend",
+      "label": "Human",
+      "tag": "Direct + guide + review",
+      "sublabel": "Define outcome; inspect artifacts",
+      "pos": [
+        700,
+        90
+      ],
+      "size": [
+        570,
+        190
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "agent",
+      "type": "external",
+      "label": "AI Agent",
+      "tag": "Qualified client + authorized pilot",
+      "sublabel": "Produce work within the boundary",
+      "pos": [
+        700,
+        440
+      ],
+      "size": [
+        570,
+        190
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "learn",
+      "type": "external",
+      "label": "Learn from real work",
+      "tag": "Ongoing, reviewed improvement",
+      "sublabel": "Feedback + selected measures\nRetain a manual path\nNo quotas or rankings",
+      "pos": [
+        700,
+        800
+      ],
+      "size": [
+        570,
+        270
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "expand",
+      "type": "backend",
+      "label": "Decide from evidence",
+      "tag": "Owner; new scope is separate",
+      "sublabel": "Retain / improve / hold / stop\nExpansion is a new proposal",
+      "pos": [
+        1460,
+        360
+      ],
+      "size": [
+        520,
+        240
+      ],
+      "icon": "none"
+    }
+  ],
+  "connections": [
+    {
+      "id": "delivery-agent",
+      "from": "delivery",
+      "to": "agent",
+      "label": "Practice",
+      "fromSide": "right",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          585,
+          455
+        ],
+        [
+          585,
+          535
+        ]
+      ],
+      "labelAt": [
+        570,
+        600
+      ]
+    },
+    {
+      "id": "human-agent",
+      "from": "human",
+      "to": "agent",
+      "label": "Direction",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        1100,
+        360
+      ]
+    },
+    {
+      "id": "agent-human",
+      "from": "agent",
+      "to": "human",
+      "label": "Work to inspect",
+      "fromSide": "left",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          630,
+          535
+        ],
+        [
+          630,
+          185
+        ]
+      ],
+      "labelAt": [
+        470,
+        240
+      ]
+    },
+    {
+      "id": "agent-learn",
+      "from": "agent",
+      "to": "learn",
+      "label": "Observe",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        1100,
+        720
+      ]
+    },
+    {
+      "id": "learn-delivery",
+      "from": "learn",
+      "to": "delivery",
+      "label": "Improve",
+      "fromSide": "left",
+      "toSide": "bottom",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          295,
+          935
+        ]
+      ],
+      "labelAt": [
+        450,
+        900
+      ]
+    },
+    {
+      "id": "human-expand",
+      "from": "human",
+      "to": "expand",
+      "label": "Accepted work",
+      "fromSide": "right",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          1720,
+          185
+        ]
+      ],
+      "labelAt": [
+        1550,
+        140
+      ]
+    },
+    {
+      "id": "learn-expand",
+      "from": "learn",
+      "to": "expand",
+      "label": "Feedback",
+      "fromSide": "right",
+      "toSide": "bottom",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          1720,
+          935
+        ]
+      ],
+      "labelAt": [
+        1480,
+        895
+      ]
+    }
+  ]
+}

diagrams/strategy-baseline-mobile.architecture.json

@@ -0,0 +1,144 @@
+{
+  "schema_version": 1,
+  "diagram_type": "architecture",
+  "meta": {
+    "title": "Workflow baseline",
+    "output": "static/diagrams/strategy-baseline-mobile/index.html",
+    "quality_profile": "showcase",
+    "legend": {
+      "mode": "hidden"
+    },
+    "viewBox": [
+      880,
+      2050
+    ]
+  },
+  "components": [
+    {
+      "id": "workflow",
+      "type": "external",
+      "label": "Current workflow",
+      "tag": "01 / Understand",
+      "sublabel": "Task, scope, people\nTools + handoffs\nCurrent practice",
+      "pos": [
+        90,
+        50
+      ],
+      "size": [
+        700,
+        350
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "selection",
+      "type": "frontend",
+      "label": "Relevant selection",
+      "tag": "02 / Choose",
+      "sublabel": "Registry candidates\nReasons for inclusion\nDefer what does not fit",
+      "pos": [
+        90,
+        450
+      ],
+      "size": [
+        700,
+        350
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "evidence",
+      "type": "frontend",
+      "label": "Feasible evidence",
+      "tag": "03 / Agree",
+      "sublabel": "Sources + period\nPrivacy, access, owner\nTest joins + coverage",
+      "pos": [
+        90,
+        850
+      ],
+      "size": [
+        700,
+        350
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "position",
+      "type": "backend",
+      "label": "Starting position",
+      "tag": "04 / Record",
+      "sublabel": "Actual values + limits\nOr unavailable gaps\nNo invented baseline",
+      "pos": [
+        90,
+        1250
+      ],
+      "size": [
+        700,
+        350
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "comparison",
+      "type": "backend",
+      "label": "Later comparison",
+      "tag": "05 / Evaluate",
+      "sublabel": "Comparable rules\nContext + uncertainty\nNot causal ROI",
+      "pos": [
+        90,
+        1650
+      ],
+      "size": [
+        700,
+        350
+      ],
+      "icon": "none"
+    }
+  ],
+  "connections": [
+    {
+      "id": "workflow-selection",
+      "from": "workflow",
+      "to": "selection",
+      "label": "",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default"
+    },
+    {
+      "id": "selection-evidence",
+      "from": "selection",
+      "to": "evidence",
+      "label": "",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default"
+    },
+    {
+      "id": "evidence-position",
+      "from": "evidence",
+      "to": "position",
+      "label": "",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default"
+    },
+    {
+      "id": "position-comparison",
+      "from": "position",
+      "to": "comparison",
+      "label": "",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default"
+    }
+  ]
+}

diagrams/strategy-baseline.architecture.json

@@ -0,0 +1,184 @@
+{
+  "schema_version": 1,
+  "diagram_type": "architecture",
+  "meta": {
+    "title": "Workflow baseline",
+    "output": "static/diagrams/strategy-baseline/index.html",
+    "quality_profile": "showcase",
+    "legend": {
+      "mode": "hidden"
+    },
+    "viewBox": [
+      2400,
+      1120
+    ]
+  },
+  "components": [
+    {
+      "id": "workflow",
+      "type": "external",
+      "label": "Current workflow",
+      "tag": "01 / Understand",
+      "sublabel": "Task, scope, people\nTools + handoffs\nCurrent practice",
+      "pos": [
+        40,
+        55
+      ],
+      "size": [
+        440,
+        290
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "selection",
+      "type": "frontend",
+      "label": "Relevant selection",
+      "tag": "02 / Choose",
+      "sublabel": "Registry candidates\nReasons for inclusion\nDefer what does not fit",
+      "pos": [
+        510,
+        235
+      ],
+      "size": [
+        440,
+        290
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "evidence",
+      "type": "frontend",
+      "label": "Feasible evidence",
+      "tag": "03 / Agree",
+      "sublabel": "Sources + period\nPrivacy, access, owner\nTest joins + coverage",
+      "pos": [
+        980,
+        415
+      ],
+      "size": [
+        440,
+        290
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "position",
+      "type": "backend",
+      "label": "Starting position",
+      "tag": "04 / Record",
+      "sublabel": "Actual values + limits\nOr unavailable gaps\nNo invented baseline",
+      "pos": [
+        1450,
+        595
+      ],
+      "size": [
+        440,
+        290
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "comparison",
+      "type": "backend",
+      "label": "Later comparison",
+      "tag": "05 / Evaluate",
+      "sublabel": "Comparable rules\nContext + uncertainty\nNot causal ROI",
+      "pos": [
+        1920,
+        775
+      ],
+      "size": [
+        440,
+        290
+      ],
+      "icon": "none"
+    }
+  ],
+  "connections": [
+    {
+      "id": "workflow-selection",
+      "from": "workflow",
+      "to": "selection",
+      "label": "",
+      "fromSide": "right",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          495.0,
+          200.0
+        ],
+        [
+          495.0,
+          380.0
+        ]
+      ]
+    },
+    {
+      "id": "selection-evidence",
+      "from": "selection",
+      "to": "evidence",
+      "label": "",
+      "fromSide": "right",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          965.0,
+          380.0
+        ],
+        [
+          965.0,
+          560.0
+        ]
+      ]
+    },
+    {
+      "id": "evidence-position",
+      "from": "evidence",
+      "to": "position",
+      "label": "",
+      "fromSide": "right",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          1435.0,
+          560.0
+        ],
+        [
+          1435.0,
+          740.0
+        ]
+      ]
+    },
+    {
+      "id": "position-comparison",
+      "from": "position",
+      "to": "comparison",
+      "label": "",
+      "fromSide": "right",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          1905.0,
+          740.0
+        ],
+        [
+          1905.0,
+          920.0
+        ]
+      ]
+    }
+  ]
+}

diagrams/strategy-governance-mobile.architecture.json

@@ -0,0 +1,247 @@
+{
+  "schema_version": 1,
+  "diagram_type": "architecture",
+  "meta": {
+    "title": "TO-BE: Governance",
+    "output": "static/diagrams/strategy-governance-mobile/index.html",
+    "quality_profile": "showcase",
+    "legend": {
+      "mode": "hidden"
+    },
+    "viewBox": [
+      880,
+      2710
+    ]
+  },
+  "components": [
+    {
+      "id": "owner",
+      "type": "external",
+      "label": "01  Propose",
+      "tag": "Owning team",
+      "sublabel": "Scope + testable outcome",
+      "pos": [
+        60,
+        120
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "review",
+      "type": "external",
+      "label": "02  Review independently",
+      "tag": "Quality + Security",
+      "sublabel": "Author is not sole approver",
+      "pos": [
+        60,
+        490
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "canary",
+      "type": "external",
+      "label": "03  Authorize pilot",
+      "tag": "Owning team approver",
+      "sublabel": "Qualified; pin, load, pilot",
+      "pos": [
+        60,
+        860
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "approve",
+      "type": "backend",
+      "label": "04  Decide exact scope",
+      "tag": "Accountable approvers",
+      "sublabel": "Compare pilot: approve / hold",
+      "pos": [
+        60,
+        1230
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "publish",
+      "type": "backend",
+      "label": "05  Publish the bundle",
+      "tag": "Data & AI catalog",
+      "sublabel": "Pin skill, adapter + dependencies",
+      "pos": [
+        60,
+        1600
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "distribute",
+      "type": "backend",
+      "label": "06  Verify loaded state",
+      "tag": "Platform & IT",
+      "sublabel": "Read revision; verify reload",
+      "pos": [
+        60,
+        1970
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "withdraw",
+      "type": "security",
+      "label": "Withdraw / roll back",
+      "tag": "Unsafe revision",
+      "sublabel": "Revoke; restore or remove candidate",
+      "pos": [
+        60,
+        2340
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    }
+  ],
+  "connections": [
+    {
+      "id": "owner-review",
+      "from": "owner",
+      "to": "review",
+      "label": "",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        610,
+        395
+      ]
+    },
+    {
+      "id": "review-canary",
+      "from": "review",
+      "to": "canary",
+      "label": "",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        610,
+        765
+      ]
+    },
+    {
+      "id": "canary-approve",
+      "from": "canary",
+      "to": "approve",
+      "label": "",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        610,
+        1135
+      ]
+    },
+    {
+      "id": "approve-publish",
+      "from": "approve",
+      "to": "publish",
+      "label": "",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        610,
+        1505
+      ]
+    },
+    {
+      "id": "publish-distribute",
+      "from": "publish",
+      "to": "distribute",
+      "label": "",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        610,
+        1875
+      ]
+    },
+    {
+      "id": "approve-owner",
+      "from": "approve",
+      "to": "owner",
+      "label": "Rework",
+      "fromSide": "left",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "security",
+      "via": [
+        [
+          20,
+          1340.0
+        ],
+        [
+          20,
+          230.0
+        ]
+      ],
+      "labelAt": [
+        620,
+        80
+      ]
+    },
+    {
+      "id": "distribute-withdraw",
+      "from": "distribute",
+      "to": "withdraw",
+      "label": "Unsafe",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "security",
+      "labelAt": [
+        610,
+        2245
+      ]
+    }
+  ]
+}

diagrams/strategy-governance.architecture.json

@@ -0,0 +1,277 @@
+{
+  "schema_version": 1,
+  "diagram_type": "architecture",
+  "meta": {
+    "title": "TO-BE: Governance",
+    "output": "static/diagrams/strategy-governance/index.html",
+    "quality_profile": "showcase",
+    "legend": {
+      "mode": "hidden"
+    },
+    "viewBox": [
+      1760,
+      1420
+    ]
+  },
+  "components": [
+    {
+      "id": "owner",
+      "type": "external",
+      "label": "01  Propose",
+      "tag": "Owning team",
+      "sublabel": "Scope + testable outcome",
+      "pos": [
+        80,
+        60
+      ],
+      "size": [
+        500,
+        170
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "review",
+      "type": "external",
+      "label": "02  Review independently",
+      "tag": "Quality + Security",
+      "sublabel": "Author is not sole approver",
+      "pos": [
+        300,
+        280
+      ],
+      "size": [
+        500,
+        170
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "canary",
+      "type": "external",
+      "label": "03  Authorize pilot",
+      "tag": "Owning team approver",
+      "sublabel": "Qualified; pin, load, pilot",
+      "pos": [
+        520,
+        500
+      ],
+      "size": [
+        500,
+        170
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "approve",
+      "type": "backend",
+      "label": "04  Decide exact scope",
+      "tag": "Accountable approvers",
+      "sublabel": "Compare pilot: approve / hold",
+      "pos": [
+        740,
+        720
+      ],
+      "size": [
+        500,
+        170
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "publish",
+      "type": "backend",
+      "label": "05  Publish the bundle",
+      "tag": "Data & AI catalog",
+      "sublabel": "Pin skill, adapter + dependencies",
+      "pos": [
+        960,
+        940
+      ],
+      "size": [
+        500,
+        170
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "distribute",
+      "type": "backend",
+      "label": "06  Verify loaded state",
+      "tag": "Platform & IT",
+      "sublabel": "Read revision; verify reload",
+      "pos": [
+        1180,
+        1160
+      ],
+      "size": [
+        500,
+        170
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "withdraw",
+      "type": "security",
+      "label": "Withdraw / roll back",
+      "tag": "Unsafe revision",
+      "sublabel": "Revoke; restore or remove candidate",
+      "pos": [
+        80,
+        1160
+      ],
+      "size": [
+        660,
+        170
+      ],
+      "icon": "none"
+    }
+  ],
+  "connections": [
+    {
+      "id": "owner-review",
+      "from": "owner",
+      "to": "review",
+      "label": "",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          330,
+          255
+        ],
+        [
+          550,
+          255
+        ]
+      ]
+    },
+    {
+      "id": "review-canary",
+      "from": "review",
+      "to": "canary",
+      "label": "",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          550,
+          475
+        ],
+        [
+          770,
+          475
+        ]
+      ]
+    },
+    {
+      "id": "canary-approve",
+      "from": "canary",
+      "to": "approve",
+      "label": "",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          770,
+          695
+        ],
+        [
+          990,
+          695
+        ]
+      ]
+    },
+    {
+      "id": "approve-publish",
+      "from": "approve",
+      "to": "publish",
+      "label": "",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          990,
+          915
+        ],
+        [
+          1210,
+          915
+        ]
+      ]
+    },
+    {
+      "id": "publish-distribute",
+      "from": "publish",
+      "to": "distribute",
+      "label": "",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          1210,
+          1135
+        ],
+        [
+          1430,
+          1135
+        ]
+      ]
+    },
+    {
+      "id": "approve-owner",
+      "from": "approve",
+      "to": "owner",
+      "label": "Rework",
+      "fromSide": "left",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "security",
+      "via": [
+        [
+          40,
+          805
+        ],
+        [
+          40,
+          145
+        ]
+      ],
+      "labelAt": [
+        180,
+        680
+      ]
+    },
+    {
+      "id": "distribute-withdraw",
+      "from": "distribute",
+      "to": "withdraw",
+      "label": "Unsafe",
+      "fromSide": "left",
+      "toSide": "right",
+      "route": "straight",
+      "width": 4,
+      "variant": "security",
+      "labelAt": [
+        950,
+        1220
+      ]
+    }
+  ]
+}

diagrams/strategy-journey-mobile.architecture.json

@@ -0,0 +1,130 @@
+{
+  "schema_version": 1,
+  "diagram_type": "architecture",
+  "meta": {
+    "title": "TO-BE: Skills before authority",
+    "output": "static/diagrams/strategy-journey-mobile/index.html",
+    "quality_profile": "showcase",
+    "legend": {
+      "mode": "hidden"
+    }
+  },
+  "components": [
+    {
+      "id": "skills",
+      "type": "backend",
+      "label": "Govern skills",
+      "sublabel": "Owner + pinned revision",
+      "pos": [
+        20,
+        20
+      ],
+      "size": [
+        180,
+        60
+      ]
+    },
+    {
+      "id": "prove",
+      "type": "backend",
+      "label": "Prove quality",
+      "sublabel": "Independent evaluation",
+      "pos": [
+        20,
+        140
+      ],
+      "size": [
+        180,
+        60
+      ]
+    },
+    {
+      "id": "pilot",
+      "type": "backend",
+      "label": "Pilot with people",
+      "sublabel": "Qualified local clients",
+      "pos": [
+        20,
+        260
+      ],
+      "size": [
+        180,
+        60
+      ]
+    },
+    {
+      "id": "distribute",
+      "type": "backend",
+      "label": "Verify distribution",
+      "sublabel": "Canary + rollback",
+      "pos": [
+        20,
+        380
+      ],
+      "size": [
+        180,
+        60
+      ]
+    },
+    {
+      "id": "coordinate",
+      "type": "backend",
+      "label": "Coordinate delivery",
+      "sublabel": "One logical SDLC agent",
+      "pos": [
+        20,
+        500
+      ],
+      "size": [
+        180,
+        60
+      ]
+    },
+    {
+      "id": "expand",
+      "type": "backend",
+      "label": "Expand by evidence",
+      "sublabel": "Department outcomes",
+      "pos": [
+        20,
+        620
+      ],
+      "size": [
+        180,
+        60
+      ]
+    }
+  ],
+  "connections": [
+    {
+      "id": "flow-0",
+      "from": "skills",
+      "to": "prove",
+      "label": "qualify"
+    },
+    {
+      "id": "flow-1",
+      "from": "prove",
+      "to": "pilot",
+      "label": "coach"
+    },
+    {
+      "id": "flow-2",
+      "from": "pilot",
+      "to": "distribute",
+      "label": "Verify"
+    },
+    {
+      "id": "flow-3",
+      "from": "distribute",
+      "to": "coordinate",
+      "label": "prove recovery"
+    },
+    {
+      "id": "flow-4",
+      "from": "coordinate",
+      "to": "expand",
+      "label": "Justify"
+    }
+  ]
+}

diagrams/strategy-journey.architecture.json

@@ -0,0 +1,130 @@
+{
+  "schema_version": 1,
+  "diagram_type": "architecture",
+  "meta": {
+    "title": "TO-BE: Skills before authority",
+    "output": "static/diagrams/strategy-journey/index.html",
+    "quality_profile": "showcase",
+    "legend": {
+      "mode": "hidden"
+    }
+  },
+  "components": [
+    {
+      "id": "skills",
+      "type": "backend",
+      "label": "Govern skills",
+      "sublabel": "Owner + pinned revision",
+      "pos": [
+        20,
+        20
+      ],
+      "size": [
+        180,
+        60
+      ]
+    },
+    {
+      "id": "prove",
+      "type": "backend",
+      "label": "Prove quality",
+      "sublabel": "Independent evaluation",
+      "pos": [
+        260,
+        20
+      ],
+      "size": [
+        180,
+        60
+      ]
+    },
+    {
+      "id": "pilot",
+      "type": "backend",
+      "label": "Pilot with people",
+      "sublabel": "Qualified local clients",
+      "pos": [
+        260,
+        150
+      ],
+      "size": [
+        180,
+        60
+      ]
+    },
+    {
+      "id": "distribute",
+      "type": "backend",
+      "label": "Verify distribution",
+      "sublabel": "Canary + rollback",
+      "pos": [
+        20,
+        150
+      ],
+      "size": [
+        180,
+        60
+      ]
+    },
+    {
+      "id": "coordinate",
+      "type": "backend",
+      "label": "Coordinate delivery",
+      "sublabel": "One logical SDLC agent",
+      "pos": [
+        20,
+        280
+      ],
+      "size": [
+        180,
+        60
+      ]
+    },
+    {
+      "id": "expand",
+      "type": "backend",
+      "label": "Expand by evidence",
+      "sublabel": "Department outcomes",
+      "pos": [
+        260,
+        280
+      ],
+      "size": [
+        180,
+        60
+      ]
+    }
+  ],
+  "connections": [
+    {
+      "id": "flow-0",
+      "from": "skills",
+      "to": "prove",
+      "label": "qualify"
+    },
+    {
+      "id": "flow-1",
+      "from": "prove",
+      "to": "pilot",
+      "label": "coach"
+    },
+    {
+      "id": "flow-2",
+      "from": "pilot",
+      "to": "distribute",
+      "label": "Verify"
+    },
+    {
+      "id": "flow-3",
+      "from": "distribute",
+      "to": "coordinate",
+      "label": "prove recovery"
+    },
+    {
+      "id": "flow-4",
+      "from": "coordinate",
+      "to": "expand",
+      "label": "Justify"
+    }
+  ]
+}

diagrams/strategy-maintenance-mobile.architecture.json

@@ -0,0 +1,158 @@
+{
+  "schema_version": 1,
+  "diagram_type": "architecture",
+  "meta": {
+    "title": "TO-BE: Maintenance",
+    "output": "static/diagrams/strategy-maintenance-mobile/index.html",
+    "quality_profile": "showcase",
+    "legend": {
+      "mode": "hidden"
+    },
+    "viewBox": [
+      880,
+      3080
+    ]
+  },
+  "components": [
+    {
+      "id": "observe",
+      "type": "external",
+      "label": "Observe use",
+      "tag": "Owner + Data & AI",
+      "sublabel": "Selected evidence + drift",
+      "pos": [
+        60,
+        120
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "triage",
+      "type": "external",
+      "label": "Triage the signal",
+      "tag": "Owning team",
+      "sublabel": "Useful? Safe? Still needed?",
+      "pos": [
+        60,
+        490
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "change",
+      "type": "external",
+      "label": "Change the skill",
+      "tag": "Reviewed correction",
+      "sublabel": "New immutable revision",
+      "pos": [
+        60,
+        1230
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "validate",
+      "type": "external",
+      "label": "Revalidate",
+      "tag": "Quality Engineering reviewer",
+      "sublabel": "Fitness + regression + client checks",
+      "pos": [
+        60,
+        1600
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "release",
+      "type": "backend",
+      "label": "Approve + version",
+      "tag": "Accountable human authority",
+      "sublabel": "Verify distribution and recovery",
+      "pos": [
+        60,
+        1970
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "safe",
+      "type": "backend",
+      "label": "Continue safe use",
+      "tag": "Substantive review passes",
+      "sublabel": "Keep owner + next review date",
+      "pos": [
+        60,
+        2710
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "retire",
+      "type": "external",
+      "label": "Retire deliberately",
+      "tag": "No longer useful",
+      "sublabel": "Reconcile consumers; no new use",
+      "pos": [
+        60,
+        2340
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "contain",
+      "type": "security",
+      "label": "Contain unsafe use",
+      "tag": "Security + Platform & IT",
+      "sublabel": "Revoke + quarantine + roll back\nNo automatic reinstatement",
+      "pos": [
+        60,
+        860
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    }
+  ],
+  "connections": [
+    {"id":"observe-triage","from":"observe","to":"triage","label":"","fromSide":"bottom","toSide":"top","route":"straight","width":4,"variant":"default"},
+    {"id":"triage-change","from":"triage","to":"change","label":"Correct","fromSide":"right","toSide":"right","route":"straight","width":4,"variant":"default","via":[[824,600],[824,1340]],"labelAt":[640,1190]},
+    {"id":"change-validate","from":"change","to":"validate","label":"","fromSide":"bottom","toSide":"top","route":"straight","width":4,"variant":"default"},
+    {"id":"validate-release","from":"validate","to":"release","label":"","fromSide":"bottom","toSide":"top","route":"straight","width":4,"variant":"default"},
+    {"id":"release-observe","from":"release","to":"observe","label":"","fromSide":"left","toSide":"left","route":"straight","width":4,"variant":"default","via":[[42,2080],[42,230]]},
+    {"id":"triage-safe","from":"triage","to":"safe","label":"Safe","fromSide":"right","toSide":"right","route":"straight","width":4,"variant":"default","via":[[872,600],[872,2820]],"labelAt":[620,2670]},
+    {"id":"triage-retire","from":"triage","to":"retire","label":"Retire","fromSide":"right","toSide":"right","route":"straight","width":4,"variant":"default","via":[[850,600],[850,2450]],"labelAt":[620,2300]},
+    {"id":"triage-contain","from":"triage","to":"contain","label":"Unsafe","fromSide":"bottom","toSide":"top","route":"straight","width":4,"variant":"security","labelAt":[610,795]},
+    {"id":"contain-change","from":"contain","to":"change","label":"Reviewed fix","fromSide":"bottom","toSide":"top","route":"straight","width":4,"variant":"security","labelAt":[610,1135]},
+    {"id":"safe-observe","from":"safe","to":"observe","label":"Keep watching","fromSide":"left","toSide":"left","route":"straight","width":4,"variant":"default","via":[[20,2820],[20,230]],"labelAt":[620,80]}
+  ]
+}

diagrams/strategy-maintenance.architecture.json

@@ -0,0 +1,370 @@
+{
+  "schema_version": 1,
+  "diagram_type": "architecture",
+  "meta": {
+    "title": "TO-BE: Maintenance",
+    "output": "static/diagrams/strategy-maintenance/index.html",
+    "quality_profile": "showcase",
+    "legend": {
+      "mode": "hidden"
+    },
+    "viewBox": [
+      2630,
+      1300
+    ]
+  },
+  "components": [
+    {
+      "id": "observe",
+      "type": "external",
+      "label": "Observe use",
+      "tag": "Owner + Data & AI",
+      "sublabel": "Selected evidence + drift",
+      "pos": [
+        670,
+        60
+      ],
+      "size": [
+        560,
+        170
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "triage",
+      "type": "external",
+      "label": "Triage the signal",
+      "tag": "Owning team",
+      "sublabel": "Useful? Safe? Still needed?",
+      "pos": [
+        1340,
+        330
+      ],
+      "size": [
+        500,
+        190
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "change",
+      "type": "external",
+      "label": "Change the skill",
+      "tag": "Reviewed correction",
+      "sublabel": "New immutable revision",
+      "pos": [
+        1240,
+        750
+      ],
+      "size": [
+        520,
+        180
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "validate",
+      "type": "external",
+      "label": "Revalidate",
+      "tag": "Quality Engineering reviewer",
+      "sublabel": "Fitness + regression + client checks",
+      "pos": [
+        560,
+        970
+      ],
+      "size": [
+        560,
+        180
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "release",
+      "type": "backend",
+      "label": "Approve + version",
+      "tag": "Accountable human authority",
+      "sublabel": "Verify distribution and recovery",
+      "pos": [
+        70,
+        570
+      ],
+      "size": [
+        540,
+        180
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "safe",
+      "type": "backend",
+      "label": "Continue safe use",
+      "tag": "Substantive review passes",
+      "sublabel": "Keep owner + next review date",
+      "pos": [
+        2010,
+        80
+      ],
+      "size": [
+        550,
+        180
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "retire",
+      "type": "external",
+      "label": "Retire deliberately",
+      "tag": "No longer useful",
+      "sublabel": "Reconcile consumers; no new use",
+      "pos": [
+        2010,
+        430
+      ],
+      "size": [
+        550,
+        180
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "contain",
+      "type": "security",
+      "label": "Contain unsafe use",
+      "tag": "Security + Platform & IT",
+      "sublabel": "Revoke + quarantine + roll back\nNo automatic reinstatement",
+      "pos": [
+        2010,
+        800
+      ],
+      "size": [
+        550,
+        220
+      ],
+      "icon": "none"
+    }
+  ],
+  "connections": [
+    {
+      "id": "observe-triage",
+      "from": "observe",
+      "to": "triage",
+      "label": "",
+      "fromSide": "right",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          1590,
+          145
+        ]
+      ]
+    },
+    {
+      "id": "triage-change",
+      "from": "triage",
+      "to": "change",
+      "label": "Correct",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          1590,
+          620
+        ],
+        [
+          1500,
+          620
+        ]
+      ],
+      "labelAt": [
+        1450,
+        680
+      ]
+    },
+    {
+      "id": "change-validate",
+      "from": "change",
+      "to": "validate",
+      "label": "",
+      "fromSide": "bottom",
+      "toSide": "right",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          1500,
+          1060
+        ]
+      ]
+    },
+    {
+      "id": "validate-release",
+      "from": "validate",
+      "to": "release",
+      "label": "",
+      "fromSide": "left",
+      "toSide": "bottom",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          340,
+          1060
+        ]
+      ]
+    },
+    {
+      "id": "release-observe",
+      "from": "release",
+      "to": "observe",
+      "label": "",
+      "fromSide": "top",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          340,
+          145
+        ]
+      ]
+    },
+    {
+      "id": "triage-safe",
+      "from": "triage",
+      "to": "safe",
+      "label": "Safe",
+      "fromSide": "right",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          1920,
+          425
+        ],
+        [
+          1920,
+          170
+        ]
+      ],
+      "labelAt": [
+        1930,
+        210
+      ]
+    },
+    {
+      "id": "triage-retire",
+      "from": "triage",
+      "to": "retire",
+      "label": "Retire",
+      "fromSide": "right",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          1950,
+          425
+        ],
+        [
+          1950,
+          520
+        ]
+      ],
+      "labelAt": [
+        1930,
+        490
+      ]
+    },
+    {
+      "id": "triage-contain",
+      "from": "triage",
+      "to": "contain",
+      "label": "Unsafe",
+      "fromSide": "bottom",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "security",
+      "via": [
+        [
+          1590,
+          580
+        ],
+        [
+          1850,
+          580
+        ],
+        [
+          1850,
+          910
+        ]
+      ],
+      "labelAt": [
+        1900,
+        720
+      ]
+    },
+    {
+      "id": "contain-change",
+      "from": "contain",
+      "to": "change",
+      "label": "Reviewed fix",
+      "fromSide": "bottom",
+      "toSide": "bottom",
+      "route": "straight",
+      "width": 4,
+      "variant": "security",
+      "via": [
+        [
+          2285,
+          1230
+        ],
+        [
+          1500,
+          1230
+        ]
+      ],
+      "labelAt": [
+        1900,
+        1190
+      ]
+    },
+    {
+      "id": "safe-observe",
+      "from": "safe",
+      "to": "observe",
+      "label": "Keep watching",
+      "fromSide": "top",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          2285,
+          20
+        ],
+        [
+          950,
+          20
+        ]
+      ],
+      "labelAt": [
+        1640,
+        45
+      ]
+    }
+  ]
+}

diagrams/strategy-measurement-mobile.architecture.json

@@ -0,0 +1,20 @@
+{
+  "schema_version": 1,
+  "diagram_type": "architecture",
+  "meta": {"title": "Two connected measurement tracks", "output": "static/diagrams/strategy-measurement-mobile/index.html", "quality_profile": "showcase", "legend": {"mode": "hidden"}, "viewBox": [880, 2450]},
+  "components": [
+    {"id": "workflow", "type": "backend", "label": "Workflow effectiveness", "tag": "01 / Baseline current work", "sublabel": "Accepted work, time, failures\nCost, effort + experience\nSelect relevant contracts only\nSkills need not exist yet", "pos": [90, 50], "size": [700, 350], "icon": "none"},
+    {"id": "compare", "type": "backend", "label": "Compare the same outcomes", "tag": "02 / After introducing skills", "sublabel": "Same workflow + acceptance\nSame follow-up + source coverage\nKeep gaps and task mix visible\nBefore / after is not causality", "pos": [90, 450], "size": [700, 350], "icon": "none"},
+    {"id": "interpret", "type": "external", "label": "Is work getting better?", "tag": "03 / Interpret workflow evidence", "sublabel": "Balance value, quality and risk\nMore adoption is not better work\nKeep live outcomes separate\nfrom skill evaluation cases", "pos": [90, 850], "size": [700, 350], "icon": "none"},
+    {"id": "skills", "type": "frontend", "label": "Skills effectiveness & health", "tag": "01 / Qualify named skill versions", "sublabel": "Quality: artifact fitness + safety\nCandidate / approved regression\nSelection precision + recall\nNo applicable skills: N/A", "pos": [90, 1250], "size": [700, 350], "icon": "none"},
+    {"id": "observe", "type": "frontend", "label": "Observe use + upkeep", "tag": "02 / Adoption and maintenance", "sublabel": "Supported bundle coverage\nApproved-workflow adoption\nSubstantive review evidence\nMissing observations: unknown", "pos": [90, 1650], "size": [700, 350], "icon": "none"},
+    {"id": "improve", "type": "external", "label": "Improve, retain or retire", "tag": "03 / Use both tracks together", "sublabel": "Owner + independent evidence\nRetain / improve / stop\nNew scope needs new comparison\nNo mandatory collection", "pos": [90, 2050], "size": [700, 350], "icon": "none"}
+  ],
+  "connections": [
+    {"id": "workflow-compare", "from": "workflow", "to": "compare", "label": "", "fromSide": "bottom", "toSide": "top", "route": "straight", "width": 4, "variant": "default"},
+    {"id": "compare-interpret", "from": "compare", "to": "interpret", "label": "", "fromSide": "bottom", "toSide": "top", "route": "straight", "width": 4, "variant": "default"},
+    {"id": "skills-observe", "from": "skills", "to": "observe", "label": "", "fromSide": "bottom", "toSide": "top", "route": "straight", "width": 4, "variant": "default"},
+    {"id": "observe-improve", "from": "observe", "to": "improve", "label": "", "fromSide": "bottom", "toSide": "top", "route": "straight", "width": 4, "variant": "default"},
+    {"id": "interpret-improve", "from": "interpret", "to": "improve", "label": "", "fromSide": "right", "toSide": "right", "route": "straight", "width": 4, "variant": "default", "via": [[835, 1025], [835, 2225]]}
+  ]
+}

diagrams/strategy-measurement.architecture.json

@@ -0,0 +1,20 @@
+{
+  "schema_version": 1,
+  "diagram_type": "architecture",
+  "meta": {"title": "Two connected measurement tracks", "output": "static/diagrams/strategy-measurement/index.html", "quality_profile": "showcase", "legend": {"mode": "hidden"}, "viewBox": [2400, 960]},
+  "components": [
+    {"id": "workflow", "type": "backend", "label": "Workflow effectiveness", "tag": "01 / Baseline current work", "sublabel": "Accepted work, time, failures\nCost, effort + experience\nSelect relevant contracts only\nSkills need not exist yet", "pos": [40, 40], "size": [720, 310], "icon": "none"},
+    {"id": "compare", "type": "backend", "label": "Compare the same outcomes", "tag": "02 / After introducing skills", "sublabel": "Same workflow + acceptance\nSame follow-up + source coverage\nKeep gaps and task mix visible\nBefore / after is not causality", "pos": [840, 40], "size": [720, 310], "icon": "none"},
+    {"id": "interpret", "type": "external", "label": "Is work getting better?", "tag": "03 / Interpret workflow evidence", "sublabel": "Balance value, quality and risk\nMore adoption is not better work\nKeep live outcomes separate\nfrom skill evaluation cases", "pos": [1640, 40], "size": [720, 310], "icon": "none"},
+    {"id": "skills", "type": "frontend", "label": "Skills effectiveness & health", "tag": "01 / Qualify named skill versions", "sublabel": "Quality: artifact fitness + safety\nCandidate / approved regression\nSelection precision + recall\nNo applicable skills: N/A", "pos": [40, 590], "size": [720, 310], "icon": "none"},
+    {"id": "observe", "type": "frontend", "label": "Observe use + upkeep", "tag": "02 / Adoption and maintenance", "sublabel": "Supported bundle coverage\nApproved-workflow adoption\nSubstantive review evidence\nMissing observations: unknown", "pos": [840, 590], "size": [720, 310], "icon": "none"},
+    {"id": "improve", "type": "external", "label": "Improve, retain or retire", "tag": "03 / Use both tracks together", "sublabel": "Owner + independent evidence\nRetain / improve / stop\nNew scope needs new comparison\nNo mandatory collection", "pos": [1640, 590], "size": [720, 310], "icon": "none"}
+  ],
+  "connections": [
+    {"id": "workflow-compare", "from": "workflow", "to": "compare", "label": "", "fromSide": "right", "toSide": "left", "route": "straight", "width": 4, "variant": "default"},
+    {"id": "compare-interpret", "from": "compare", "to": "interpret", "label": "", "fromSide": "right", "toSide": "left", "route": "straight", "width": 4, "variant": "default"},
+    {"id": "skills-observe", "from": "skills", "to": "observe", "label": "", "fromSide": "right", "toSide": "left", "route": "straight", "width": 4, "variant": "default"},
+    {"id": "observe-improve", "from": "observe", "to": "improve", "label": "", "fromSide": "right", "toSide": "left", "route": "straight", "width": 4, "variant": "default"},
+    {"id": "interpret-improve", "from": "interpret", "to": "improve", "label": "", "fromSide": "bottom", "toSide": "top", "route": "straight", "width": 4, "variant": "default"}
+  ]
+}

diagrams/strategy-quality-mobile.architecture.json

@@ -0,0 +1,262 @@
+{
+  "schema_version": 1,
+  "diagram_type": "architecture",
+  "meta": {
+    "title": "TO-BE: Quality",
+    "output": "static/diagrams/strategy-quality-mobile/index.html",
+    "quality_profile": "showcase",
+    "legend": {
+      "mode": "hidden"
+    },
+    "viewBox": [
+      880,
+      2800
+    ]
+  },
+  "components": [
+    {
+      "id": "selection",
+      "type": "external",
+      "label": "Right skill?",
+      "tag": "Selection evidence",
+      "sublabel": "Triggers, near misses, negatives",
+      "pos": [
+        60,
+        120
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "safety",
+      "type": "external",
+      "label": "Safe execution?",
+      "tag": "Safety evidence",
+      "sublabel": "Permissions + adversarial trials",
+      "pos": [
+        60,
+        490
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "artifact",
+      "type": "external",
+      "label": "Valid artifact?",
+      "tag": "Independent inspection",
+      "sublabel": "Tests + human assessment",
+      "pos": [
+        60,
+        860
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "outcome",
+      "type": "external",
+      "label": "Useful outcome?",
+      "tag": "Declared evaluation cases",
+      "sublabel": "Fitness + revision regression",
+      "pos": [
+        60,
+        1230
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "gate",
+      "type": "security",
+      "label": "Every gate must pass",
+      "tag": "Risk sets evaluation depth",
+      "sublabel": "No averaging away harm\nCritical effect blocks promotion\nMissing coverage = incomplete",
+      "pos": [
+        60,
+        1600
+      ],
+      "size": [
+        740,
+        310
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "accept",
+      "type": "backend",
+      "label": "Accept evidence",
+      "tag": "Quality Engineering reviewer",
+      "sublabel": "Owner decides bounded pilot",
+      "pos": [
+        60,
+        2060
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "rework",
+      "type": "security",
+      "label": "Rework / retest",
+      "tag": "Any failure or missing evidence",
+      "sublabel": "Keep failures in the record",
+      "pos": [
+        60,
+        2430
+      ],
+      "size": [
+        740,
+        220
+      ],
+      "icon": "none"
+    }
+  ],
+  "connections": [
+    {
+      "id": "selection-gate",
+      "from": "selection",
+      "to": "gate",
+      "label": "",
+      "fromSide": "right",
+      "toSide": "right",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          850,
+          230.0
+        ],
+        [
+          850,
+          1755.0
+        ]
+      ],
+      "labelAt": [
+        620,
+        1560
+      ]
+    },
+    {
+      "id": "safety-gate",
+      "from": "safety",
+      "to": "gate",
+      "label": "",
+      "fromSide": "right",
+      "toSide": "right",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          850,
+          600.0
+        ],
+        [
+          850,
+          1755.0
+        ]
+      ],
+      "labelAt": [
+        620,
+        1560
+      ]
+    },
+    {
+      "id": "artifact-gate",
+      "from": "artifact",
+      "to": "gate",
+      "label": "",
+      "fromSide": "right",
+      "toSide": "right",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          850,
+          970.0
+        ],
+        [
+          850,
+          1755.0
+        ]
+      ],
+      "labelAt": [
+        620,
+        1560
+      ]
+    },
+    {
+      "id": "outcome-gate",
+      "from": "outcome",
+      "to": "gate",
+      "label": "",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        610,
+        1505
+      ]
+    },
+    {
+      "id": "gate-accept",
+      "from": "gate",
+      "to": "accept",
+      "label": "Pass",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        610,
+        1965
+      ]
+    },
+    {
+      "id": "gate-rework",
+      "from": "gate",
+      "to": "rework",
+      "label": "Fail",
+      "fromSide": "right",
+      "toSide": "right",
+      "route": "straight",
+      "width": 4,
+      "variant": "security",
+      "via": [
+        [
+          824,
+          1755.0
+        ],
+        [
+          824,
+          2540.0
+        ]
+      ],
+      "labelAt": [
+        620,
+        2390
+      ]
+    }
+  ]
+}

diagrams/strategy-quality.architecture.json

@@ -0,0 +1,266 @@
+{
+  "schema_version": 1,
+  "diagram_type": "architecture",
+  "meta": {
+    "title": "TO-BE: Quality",
+    "output": "static/diagrams/strategy-quality/index.html",
+    "quality_profile": "showcase",
+    "legend": {
+      "mode": "hidden"
+    },
+    "viewBox": [
+      2000,
+      1050
+    ]
+  },
+  "components": [
+    {
+      "id": "selection",
+      "type": "external",
+      "label": "Right skill?",
+      "tag": "Selection evidence",
+      "sublabel": "Triggers, near misses, negatives",
+      "pos": [
+        60,
+        70
+      ],
+      "size": [
+        510,
+        170
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "safety",
+      "type": "external",
+      "label": "Safe execution?",
+      "tag": "Safety evidence",
+      "sublabel": "Permissions + adversarial trials",
+      "pos": [
+        60,
+        310
+      ],
+      "size": [
+        510,
+        170
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "artifact",
+      "type": "external",
+      "label": "Valid artifact?",
+      "tag": "Independent inspection",
+      "sublabel": "Tests + human assessment",
+      "pos": [
+        60,
+        550
+      ],
+      "size": [
+        510,
+        170
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "outcome",
+      "type": "external",
+      "label": "Useful outcome?",
+      "tag": "Declared evaluation cases",
+      "sublabel": "Fitness + revision regression",
+      "pos": [
+        60,
+        790
+      ],
+      "size": [
+        510,
+        170
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "gate",
+      "type": "security",
+      "label": "Every gate must pass",
+      "tag": "Risk sets evaluation depth",
+      "sublabel": "No averaging away harm\nCritical effect blocks promotion\nMissing coverage = incomplete",
+      "pos": [
+        740,
+        350
+      ],
+      "size": [
+        520,
+        310
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "accept",
+      "type": "backend",
+      "label": "Accept evidence",
+      "tag": "Quality Engineering reviewer",
+      "sublabel": "Owner decides bounded pilot",
+      "pos": [
+        1430,
+        160
+      ],
+      "size": [
+        510,
+        190
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "rework",
+      "type": "security",
+      "label": "Rework / retest",
+      "tag": "Any failure or missing evidence",
+      "sublabel": "Keep failures in the record",
+      "pos": [
+        1430,
+        760
+      ],
+      "size": [
+        510,
+        190
+      ],
+      "icon": "none"
+    }
+  ],
+  "connections": [
+    {
+      "id": "selection-gate",
+      "from": "selection",
+      "to": "gate",
+      "label": "",
+      "fromSide": "right",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          650,
+          155
+        ],
+        [
+          650,
+          505
+        ]
+      ]
+    },
+    {
+      "id": "safety-gate",
+      "from": "safety",
+      "to": "gate",
+      "label": "",
+      "fromSide": "right",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          650,
+          395
+        ],
+        [
+          650,
+          505
+        ]
+      ]
+    },
+    {
+      "id": "artifact-gate",
+      "from": "artifact",
+      "to": "gate",
+      "label": "",
+      "fromSide": "right",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          650,
+          635
+        ],
+        [
+          650,
+          505
+        ]
+      ]
+    },
+    {
+      "id": "outcome-gate",
+      "from": "outcome",
+      "to": "gate",
+      "label": "",
+      "fromSide": "right",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          650,
+          875
+        ],
+        [
+          650,
+          505
+        ]
+      ]
+    },
+    {
+      "id": "gate-accept",
+      "from": "gate",
+      "to": "accept",
+      "label": "Pass",
+      "fromSide": "right",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          1340,
+          505
+        ],
+        [
+          1340,
+          255
+        ]
+      ],
+      "labelAt": [
+        1330,
+        210
+      ]
+    },
+    {
+      "id": "gate-rework",
+      "from": "gate",
+      "to": "rework",
+      "label": "Fail",
+      "fromSide": "right",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "security",
+      "via": [
+        [
+          1340,
+          505
+        ],
+        [
+          1340,
+          855
+        ]
+      ],
+      "labelAt": [
+        1325,
+        900
+      ]
+    }
+  ]
+}

diagrams/strategy-roadmap-adoption-mobile.workflow.json

@@ -0,0 +1,57 @@
+{
+  "schema_version": 2,
+  "diagram_type": "workflow",
+  "meta": {
+    "title": "Stage 1: Delivery first",
+    "output": "static/diagrams/strategy-roadmap-adoption-mobile/index.html",
+    "quality_profile": "showcase",
+    "animation": "none",
+    "legend": {
+      "mode": "hidden"
+    }
+  },
+  "lanes": [
+    {
+      "id": "adoption",
+      "label": "Stage 1: Delivery first"
+    }
+  ],
+  "mainPath": [
+    "delivery",
+    "remaining"
+  ],
+  "nodes": [
+    {
+      "id": "delivery",
+      "lane": "adoption",
+      "col": 0,
+      "yOffset": -140.0,
+      "type": "backend",
+      "label": "Delivery first",
+      "sublabel": "Human + AI Agent; keep improving.",
+      "width": 340,
+      "height": 240
+    },
+    {
+      "id": "remaining",
+      "lane": "adoption",
+      "col": 0,
+      "yOffset": 140.0,
+      "type": "backend",
+      "label": "Other SDLC phases",
+      "sublabel": "Expand adoption; order not yet decided.",
+      "width": 340,
+      "height": 240
+    }
+  ],
+  "edges": [
+    {
+      "id": "flow-0",
+      "from": "delivery",
+      "to": "remaining",
+      "role": "main",
+      "fromSide": "bottom",
+      "toSide": "top"
+    }
+  ]
+}

diagrams/strategy-roadmap-adoption.workflow.json

@@ -0,0 +1,57 @@
+{
+  "schema_version": 2,
+  "diagram_type": "workflow",
+  "meta": {
+    "title": "Stage 1: Delivery first",
+    "output": "static/diagrams/strategy-roadmap-adoption/index.html",
+    "quality_profile": "showcase",
+    "animation": "none",
+    "legend": {
+      "mode": "hidden"
+    }
+  },
+  "lanes": [
+    {
+      "id": "adoption",
+      "label": "Stage 1: Delivery first"
+    }
+  ],
+  "mainPath": [
+    "delivery",
+    "remaining"
+  ],
+  "nodes": [
+    {
+      "id": "delivery",
+      "lane": "adoption",
+      "col": 0,
+      "yOffset": 0,
+      "type": "backend",
+      "label": "Delivery first",
+      "sublabel": "Human + AI Agent; keep improving.",
+      "width": 340,
+      "height": 240
+    },
+    {
+      "id": "remaining",
+      "lane": "adoption",
+      "col": 1,
+      "yOffset": 0,
+      "type": "backend",
+      "label": "Other SDLC phases",
+      "sublabel": "Expand adoption; order not yet decided.",
+      "width": 340,
+      "height": 240
+    }
+  ],
+  "edges": [
+    {
+      "id": "flow-0",
+      "from": "delivery",
+      "to": "remaining",
+      "role": "main",
+      "fromSide": "right",
+      "toSide": "left"
+    }
+  ]
+}

diagrams/strategy-roadmap-loop-mobile.workflow.json

@@ -0,0 +1,143 @@
+{
+  "schema_version": 2,
+  "diagram_type": "workflow",
+  "meta": {
+    "title": "Improve within each phase",
+    "output": "static/diagrams/strategy-roadmap-loop-mobile/index.html",
+    "quality_profile": "showcase",
+    "animation": "none",
+    "legend": {
+      "mode": "hidden"
+    }
+  },
+  "lanes": [
+    {
+      "id": "adoption",
+      "label": "Improve within each phase"
+    }
+  ],
+  "mainPath": [
+    "understand",
+    "baseline",
+    "topology"
+  ],
+  "nodes": [
+    {
+      "id": "understand",
+      "lane": "adoption",
+      "col": 0,
+      "yOffset": -700.0,
+      "type": "backend",
+      "label": "Understand today",
+      "sublabel": "Actual practices, tools and problems.",
+      "width": 340,
+      "height": 240
+    },
+    {
+      "id": "baseline",
+      "lane": "adoption",
+      "col": 0,
+      "yOffset": -420.0,
+      "type": "backend",
+      "label": "Set metrics / KPIs",
+      "sublabel": "Establish a baseline before changes.",
+      "width": 340,
+      "height": 240
+    },
+    {
+      "id": "topology",
+      "lane": "adoption",
+      "col": 0,
+      "yOffset": -140.0,
+      "type": "backend",
+      "label": "Engineer topology",
+      "sublabel": "Connect skills, triggers and handoffs.",
+      "width": 340,
+      "height": 240
+    },
+    {
+      "id": "use",
+      "lane": "adoption",
+      "col": 0,
+      "yOffset": 140.0,
+      "type": "backend",
+      "label": "Qualify, then pilot",
+      "sublabel": "Authorize bounded human + AI work.",
+      "width": 340,
+      "height": 240
+    },
+    {
+      "id": "collect",
+      "lane": "adoption",
+      "col": 0,
+      "yOffset": 420.0,
+      "type": "backend",
+      "label": "Collect results",
+      "sublabel": "Metrics, friction and human feedback.",
+      "width": 340,
+      "height": 240
+    },
+    {
+      "id": "reassess",
+      "lane": "adoption",
+      "col": 0,
+      "yOffset": 700.0,
+      "type": "backend",
+      "label": "Understand anew",
+      "sublabel": "Compare with baseline; repeat the loop.",
+      "width": 340,
+      "height": 240
+    }
+  ],
+  "edges": [
+    {
+      "id": "flow-0",
+      "from": "understand",
+      "to": "baseline",
+      "role": "main",
+      "fromSide": "bottom",
+      "toSide": "top"
+    },
+    {
+      "id": "flow-1",
+      "from": "baseline",
+      "to": "topology",
+      "role": "main",
+      "fromSide": "bottom",
+      "toSide": "top"
+    },
+    {
+      "id": "flow-2",
+      "from": "topology",
+      "to": "use",
+      "role": "main",
+      "fromSide": "bottom",
+      "toSide": "top"
+    },
+    {
+      "id": "flow-3",
+      "from": "use",
+      "to": "collect",
+      "role": "main",
+      "fromSide": "bottom",
+      "toSide": "top"
+    },
+    {
+      "id": "flow-4",
+      "from": "collect",
+      "to": "reassess",
+      "role": "main",
+      "fromSide": "bottom",
+      "toSide": "top"
+    },
+    {
+      "id": "repeat",
+      "from": "reassess",
+      "to": "understand",
+      "role": "return",
+      "fromSide": "left",
+      "toSide": "left",
+      "route": "return-left"
+    }
+  ]
+}

diagrams/strategy-roadmap-loop.workflow.json

@@ -0,0 +1,143 @@
+{
+  "schema_version": 2,
+  "diagram_type": "workflow",
+  "meta": {
+    "title": "Improve within each phase",
+    "output": "static/diagrams/strategy-roadmap-loop/index.html",
+    "quality_profile": "showcase",
+    "animation": "none",
+    "legend": {
+      "mode": "hidden"
+    }
+  },
+  "lanes": [
+    {
+      "id": "adoption",
+      "label": "Improve within each phase"
+    }
+  ],
+  "mainPath": [
+    "understand",
+    "baseline",
+    "topology"
+  ],
+  "nodes": [
+    {
+      "id": "understand",
+      "lane": "adoption",
+      "col": 0,
+      "yOffset": -160,
+      "type": "backend",
+      "label": "Understand today",
+      "sublabel": "Actual practices, tools and problems.",
+      "width": 340,
+      "height": 240
+    },
+    {
+      "id": "baseline",
+      "lane": "adoption",
+      "col": 1,
+      "yOffset": -160,
+      "type": "backend",
+      "label": "Set metrics / KPIs",
+      "sublabel": "Establish a baseline before changes.",
+      "width": 340,
+      "height": 240
+    },
+    {
+      "id": "topology",
+      "lane": "adoption",
+      "col": 2,
+      "yOffset": -160,
+      "type": "backend",
+      "label": "Engineer topology",
+      "sublabel": "Connect skills, triggers and handoffs.",
+      "width": 340,
+      "height": 240
+    },
+    {
+      "id": "use",
+      "lane": "adoption",
+      "col": 2,
+      "yOffset": 160,
+      "type": "backend",
+      "label": "Qualify, then pilot",
+      "sublabel": "Authorize bounded human + AI work.",
+      "width": 340,
+      "height": 240
+    },
+    {
+      "id": "collect",
+      "lane": "adoption",
+      "col": 1,
+      "yOffset": 160,
+      "type": "backend",
+      "label": "Collect results",
+      "sublabel": "Metrics, friction and human feedback.",
+      "width": 340,
+      "height": 240
+    },
+    {
+      "id": "reassess",
+      "lane": "adoption",
+      "col": 0,
+      "yOffset": 160,
+      "type": "backend",
+      "label": "Understand anew",
+      "sublabel": "Compare with baseline; repeat the loop.",
+      "width": 340,
+      "height": 240
+    }
+  ],
+  "edges": [
+    {
+      "id": "flow-0",
+      "from": "understand",
+      "to": "baseline",
+      "role": "main",
+      "fromSide": "right",
+      "toSide": "left"
+    },
+    {
+      "id": "flow-1",
+      "from": "baseline",
+      "to": "topology",
+      "role": "main",
+      "fromSide": "right",
+      "toSide": "left"
+    },
+    {
+      "id": "flow-2",
+      "from": "topology",
+      "to": "use",
+      "role": "main",
+      "fromSide": "bottom",
+      "toSide": "top"
+    },
+    {
+      "id": "flow-3",
+      "from": "use",
+      "to": "collect",
+      "role": "main",
+      "fromSide": "left",
+      "toSide": "right"
+    },
+    {
+      "id": "flow-4",
+      "from": "collect",
+      "to": "reassess",
+      "role": "main",
+      "fromSide": "left",
+      "toSide": "right"
+    },
+    {
+      "id": "repeat",
+      "from": "reassess",
+      "to": "understand",
+      "role": "return",
+      "fromSide": "top",
+      "toSide": "bottom",
+      "route": "straight"
+    }
+  ]
+}

diagrams/strategy-roadmap-mobile.workflow.json

@@ -0,0 +1,57 @@
+{
+  "schema_version": 2,
+  "diagram_type": "workflow",
+  "meta": {
+    "title": "Two stages toward Target",
+    "output": "static/diagrams/strategy-roadmap-mobile/index.html",
+    "quality_profile": "showcase",
+    "animation": "none",
+    "legend": {
+      "mode": "hidden"
+    }
+  },
+  "lanes": [
+    {
+      "id": "adoption",
+      "label": "Two stages toward Target"
+    }
+  ],
+  "mainPath": [
+    "skills",
+    "autonomy"
+  ],
+  "nodes": [
+    {
+      "id": "skills",
+      "lane": "adoption",
+      "col": 0,
+      "yOffset": -140.0,
+      "type": "backend",
+      "label": "Adopt skills",
+      "sublabel": "Human + AI Agent in each SDLC phase.",
+      "width": 340,
+      "height": 240
+    },
+    {
+      "id": "autonomy",
+      "lane": "adoption",
+      "col": 0,
+      "yOffset": 140.0,
+      "type": "backend",
+      "label": "Autonomous Agent",
+      "sublabel": "Future: separately justified authority.",
+      "width": 340,
+      "height": 240
+    }
+  ],
+  "edges": [
+    {
+      "id": "flow-0",
+      "from": "skills",
+      "to": "autonomy",
+      "role": "main",
+      "fromSide": "bottom",
+      "toSide": "top"
+    }
+  ]
+}

diagrams/strategy-roadmap.workflow.json

@@ -0,0 +1,57 @@
+{
+  "schema_version": 2,
+  "diagram_type": "workflow",
+  "meta": {
+    "title": "Two stages toward Target",
+    "output": "static/diagrams/strategy-roadmap/index.html",
+    "quality_profile": "showcase",
+    "animation": "none",
+    "legend": {
+      "mode": "hidden"
+    }
+  },
+  "lanes": [
+    {
+      "id": "adoption",
+      "label": "Two stages toward Target"
+    }
+  ],
+  "mainPath": [
+    "skills",
+    "autonomy"
+  ],
+  "nodes": [
+    {
+      "id": "skills",
+      "lane": "adoption",
+      "col": 0,
+      "yOffset": 0,
+      "type": "backend",
+      "label": "Adopt skills",
+      "sublabel": "Human + AI Agent in each SDLC phase.",
+      "width": 340,
+      "height": 240
+    },
+    {
+      "id": "autonomy",
+      "lane": "adoption",
+      "col": 1,
+      "yOffset": 0,
+      "type": "backend",
+      "label": "Autonomous Agent",
+      "sublabel": "Future: separately justified authority.",
+      "width": 340,
+      "height": 240
+    }
+  ],
+  "edges": [
+    {
+      "id": "flow-0",
+      "from": "skills",
+      "to": "autonomy",
+      "role": "main",
+      "fromSide": "right",
+      "toSide": "left"
+    }
+  ]
+}

diagrams/strategy-six-months-mobile.architecture.json

@@ -0,0 +1,249 @@
+{
+  "schema_version": 1,
+  "diagram_type": "architecture",
+  "meta": {
+    "title": "Proposed: first six months as AI Architect",
+    "output": "static/diagrams/strategy-six-months-mobile/index.html",
+    "quality_profile": "showcase",
+    "legend": {
+      "mode": "hidden"
+    },
+    "viewBox": [
+      1000,
+      2950
+    ]
+  },
+  "components": [
+    {
+      "id": "baseline",
+      "type": "external",
+      "label": "Month 1: discover",
+      "tag": "Architect + CTO + willing teams",
+      "sublabel": "Current AI workflows + constraints\nPair with developers and reviewers\nChoose an evidenced bottleneck",
+      "pos": [
+        200,
+        40
+      ],
+      "size": [
+        740,
+        300
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "engineer",
+      "type": "external",
+      "label": "Month 2: agree experiment",
+      "tag": "Architect + partner lead + reviewer",
+      "sublabel": "One workflow + feasible baseline\nChoose context, coaching or tooling\nSkills only if they fit the problem",
+      "pos": [
+        200,
+        450
+      ],
+      "size": [
+        740,
+        300
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "qualify",
+      "type": "security",
+      "label": "Month 3: pair and pilot",
+      "tag": "Team agrees time; owner permits scope",
+      "sublabel": "Independent checks before live work\nCollect accepted work and burden\nUnsafe or unsupported: stop",
+      "pos": [
+        200,
+        860
+      ],
+      "size": [
+        740,
+        300
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "pilot",
+      "type": "external",
+      "label": "Month 4: decide from evidence",
+      "tag": "Workflow owner + CTO review",
+      "sublabel": "Compare current practice and pilot\nRetain / change / hold / stop\nIncomplete: bounded extension only",
+      "pos": [
+        200,
+        1270
+      ],
+      "size": [
+        740,
+        300
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "decide",
+      "type": "security",
+      "label": "Month 5: transfer selectively",
+      "tag": "Willing champion + team lead",
+      "sublabel": "Only if value and upkeep hold\nTry another team with new baseline\nNo capacity: stay narrow or retire",
+      "pos": [
+        200,
+        1680
+      ],
+      "size": [
+        740,
+        300
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "maintain",
+      "type": "external",
+      "label": "Month 6: hand over or stop",
+      "tag": "Team owner + CTO investment decision",
+      "sublabel": "Evidence, costs and limits visible\nOwned workflow or documented stop\nNext quarter is not automatic AI",
+      "pos": [
+        200,
+        2090
+      ],
+      "size": [
+        740,
+        300
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "reference",
+      "type": "backend",
+      "label": "Proposed six-month plan",
+      "tag": "Solo architect; no team authority",
+      "sublabel": "Month 6 → 2: revise next question\nMonth 5 → 1: baseline new scope\nProposed, not company commitments",
+      "pos": [
+        200,
+        2500
+      ],
+      "size": [
+        740,
+        300
+      ],
+      "icon": "none"
+    }
+  ],
+  "connections": [
+    {
+      "id": "baseline-engineer",
+      "from": "baseline",
+      "to": "engineer",
+      "label": "Problem",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        570,
+        405
+      ]
+    },
+    {
+      "id": "engineer-qualify",
+      "from": "engineer",
+      "to": "qualify",
+      "label": "Agreement",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        570,
+        815
+      ]
+    },
+    {
+      "id": "qualify-pilot",
+      "from": "qualify",
+      "to": "pilot",
+      "label": "Evidence",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        570,
+        1225
+      ]
+    },
+    {
+      "id": "pilot-decide",
+      "from": "pilot",
+      "to": "decide",
+      "label": "Decision",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        570,
+        1635
+      ]
+    },
+    {
+      "id": "decide-maintain",
+      "from": "decide",
+      "to": "maintain",
+      "label": "Handover",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        570,
+        2045
+      ]
+    },
+    {
+      "id": "maintain-engineer",
+      "from": "maintain",
+      "to": "engineer",
+      "label": "",
+      "fromSide": "left",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          145,
+          2240
+        ],
+        [
+          145,
+          600
+        ]
+      ]
+    },
+    {
+      "id": "decide-baseline",
+      "from": "decide",
+      "to": "baseline",
+      "label": "",
+      "fromSide": "right",
+      "toSide": "right",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          980,
+          1830
+        ],
+        [
+          980,
+          190
+        ]
+      ]
+    }
+  ]
+}

diagrams/strategy-six-months.architecture.json

@@ -0,0 +1,271 @@
+{
+  "schema_version": 1,
+  "diagram_type": "architecture",
+  "meta": {
+    "title": "Proposed: first six months as AI Architect",
+    "output": "static/diagrams/strategy-six-months/index.html",
+    "quality_profile": "showcase",
+    "legend": {
+      "mode": "hidden"
+    },
+    "viewBox": [
+      2400,
+      1580
+    ]
+  },
+  "components": [
+    {
+      "id": "baseline",
+      "type": "external",
+      "label": "Month 1: discover",
+      "tag": "Architect + CTO + willing teams",
+      "sublabel": "Current AI workflows + constraints\nPair with developers and reviewers\nChoose an evidenced bottleneck",
+      "pos": [
+        100,
+        100
+      ],
+      "size": [
+        600,
+        260
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "engineer",
+      "type": "external",
+      "label": "Month 2: agree experiment",
+      "tag": "Architect + partner lead + reviewer",
+      "sublabel": "One workflow + feasible baseline\nChoose context, coaching or tooling\nSkills only if they fit the problem",
+      "pos": [
+        900,
+        100
+      ],
+      "size": [
+        600,
+        260
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "qualify",
+      "type": "security",
+      "label": "Month 3: pair and pilot",
+      "tag": "Team agrees time; owner permits scope",
+      "sublabel": "Independent checks before live work\nCollect accepted work and burden\nUnsafe or unsupported: stop",
+      "pos": [
+        1700,
+        100
+      ],
+      "size": [
+        600,
+        260
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "pilot",
+      "type": "external",
+      "label": "Month 4: decide from evidence",
+      "tag": "Workflow owner + CTO review",
+      "sublabel": "Compare current practice and pilot\nRetain / change / hold / stop\nIncomplete: bounded extension only",
+      "pos": [
+        1700,
+        730
+      ],
+      "size": [
+        600,
+        260
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "decide",
+      "type": "security",
+      "label": "Month 5: transfer selectively",
+      "tag": "Willing champion + team lead",
+      "sublabel": "Only if value and upkeep hold\nTry another team with new baseline\nNo capacity: stay narrow or retire",
+      "pos": [
+        900,
+        730
+      ],
+      "size": [
+        600,
+        260
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "maintain",
+      "type": "external",
+      "label": "Month 6: hand over or stop",
+      "tag": "Team owner + CTO investment decision",
+      "sublabel": "Evidence, costs and limits visible\nOwned workflow or documented stop\nNext quarter is not automatic AI",
+      "pos": [
+        100,
+        730
+      ],
+      "size": [
+        600,
+        260
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "reference",
+      "type": "backend",
+      "label": "Proposed six-month plan",
+      "tag": "Solo architect; no team authority",
+      "sublabel": "Month 6 → 2: revise next question\nMonth 5 → 1: baseline new scope\nProposed, not company commitments",
+      "pos": [
+        100,
+        1270
+      ],
+      "size": [
+        2200,
+        260
+      ],
+      "icon": "none"
+    }
+  ],
+  "connections": [
+    {
+      "id": "baseline-engineer",
+      "from": "baseline",
+      "to": "engineer",
+      "label": "Problem",
+      "fromSide": "right",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        800,
+        210
+      ]
+    },
+    {
+      "id": "engineer-qualify",
+      "from": "engineer",
+      "to": "qualify",
+      "label": "Agreement",
+      "fromSide": "right",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        1600,
+        210
+      ]
+    },
+    {
+      "id": "qualify-pilot",
+      "from": "qualify",
+      "to": "pilot",
+      "label": "Evidence",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          2000,
+          520
+        ]
+      ],
+      "labelAt": [
+        2010,
+        535
+      ]
+    },
+    {
+      "id": "pilot-decide",
+      "from": "pilot",
+      "to": "decide",
+      "label": "Decision",
+      "fromSide": "left",
+      "toSide": "right",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        1600,
+        840
+      ]
+    },
+    {
+      "id": "decide-maintain",
+      "from": "decide",
+      "to": "maintain",
+      "label": "Handover",
+      "fromSide": "left",
+      "toSide": "right",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        800,
+        840
+      ]
+    },
+    {
+      "id": "maintain-engineer",
+      "from": "maintain",
+      "to": "engineer",
+      "label": "Next question",
+      "fromSide": "top",
+      "toSide": "bottom",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          400,
+          550
+        ],
+        [
+          1200,
+          550
+        ]
+      ],
+      "labelAt": [
+        800,
+        535
+      ]
+    },
+    {
+      "id": "decide-baseline",
+      "from": "decide",
+      "to": "baseline",
+      "label": "New scope",
+      "fromSide": "bottom",
+      "toSide": "bottom",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          1200,
+          1150
+        ],
+        [
+          60,
+          1150
+        ],
+        [
+          60,
+          430
+        ],
+        [
+          400,
+          430
+        ]
+      ],
+      "labelAt": [
+        620,
+        1135
+      ]
+    }
+  ]
+}

diagrams/strategy-stage01-mobile.architecture.json

@@ -0,0 +1,249 @@
+{
+  "schema_version": 1,
+  "diagram_type": "architecture",
+  "meta": {
+    "title": "TO-BE: stage01",
+    "output": "static/diagrams/strategy-stage01-mobile/index.html",
+    "quality_profile": "showcase",
+    "legend": {
+      "mode": "hidden"
+    },
+    "viewBox": [
+      1000,
+      2950
+    ]
+  },
+  "components": [
+    {
+      "id": "baseline",
+      "type": "external",
+      "label": "Understand + baseline",
+      "tag": "Product Engineering workflow owner",
+      "sublabel": "Workflow map + desired improvement\nSelected measures + starting evidence\nGovernance: people, scope, authority",
+      "pos": [
+        200,
+        40
+      ],
+      "size": [
+        740,
+        300
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "engineer",
+      "type": "external",
+      "label": "Choose an intervention",
+      "tag": "Owning team + independent reviewer",
+      "sublabel": "Context, coaching, tooling or skills\nPinned candidate + client + limits\nDeliver: patch and regression tests",
+      "pos": [
+        200,
+        450
+      ],
+      "size": [
+        740,
+        300
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "qualify",
+      "type": "security",
+      "label": "Fit for a bounded pilot?",
+      "tag": "Quality evidence \u2192 owning approver",
+      "sublabel": "Artifact + safety + regression report\nPass: authorize exact pilot scope\nFail / incomplete: hold or rework",
+      "pos": [
+        200,
+        860
+      ],
+      "size": [
+        740,
+        300
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "pilot",
+      "type": "external",
+      "label": "Pilot real work",
+      "tag": "Human + AI Agent; independent review",
+      "sublabel": "Use qualified revision within scope\nAccepted / failed work + feedback\nManual path; no new release power",
+      "pos": [
+        200,
+        1270
+      ],
+      "size": [
+        740,
+        300
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "decide",
+      "type": "security",
+      "label": "Retain, improve or stop?",
+      "tag": "Workflow owner + reviewed evidence",
+      "sublabel": "Compare with baseline, not trials\nNo justified benefit: hold / stop\nNew scope: baseline + new approval",
+      "pos": [
+        200,
+        1680
+      ],
+      "size": [
+        740,
+        300
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "maintain",
+      "type": "external",
+      "label": "Maintain + requalify",
+      "tag": "Owner, Quality, Platform & Security",
+      "sublabel": "Retain: support approved revision\nDrift / defects: revise and retest\nHarm: contain; never auto-restore",
+      "pos": [
+        200,
+        2090
+      ],
+      "size": [
+        740,
+        300
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "reference",
+      "type": "backend",
+      "label": "Governance + Measurement",
+      "tag": "Throughout, not one-time gates",
+      "sublabel": "Left return: changed revision\nRight return: new scope needs baseline\nSelected evidence; no forced rollout",
+      "pos": [
+        200,
+        2500
+      ],
+      "size": [
+        740,
+        300
+      ],
+      "icon": "none"
+    }
+  ],
+  "connections": [
+    {
+      "id": "baseline-engineer",
+      "from": "baseline",
+      "to": "engineer",
+      "label": "Map",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        570,
+        405
+      ]
+    },
+    {
+      "id": "engineer-qualify",
+      "from": "engineer",
+      "to": "qualify",
+      "label": "Candidate",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        570,
+        815
+      ]
+    },
+    {
+      "id": "qualify-pilot",
+      "from": "qualify",
+      "to": "pilot",
+      "label": "Authorized",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        570,
+        1225
+      ]
+    },
+    {
+      "id": "pilot-decide",
+      "from": "pilot",
+      "to": "decide",
+      "label": "Outcomes",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        570,
+        1635
+      ]
+    },
+    {
+      "id": "decide-maintain",
+      "from": "decide",
+      "to": "maintain",
+      "label": "Retain",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        570,
+        2045
+      ]
+    },
+    {
+      "id": "maintain-engineer",
+      "from": "maintain",
+      "to": "engineer",
+      "label": "",
+      "fromSide": "left",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          145,
+          2240
+        ],
+        [
+          145,
+          600
+        ]
+      ]
+    },
+    {
+      "id": "decide-baseline",
+      "from": "decide",
+      "to": "baseline",
+      "label": "",
+      "fromSide": "right",
+      "toSide": "right",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          980,
+          1830
+        ],
+        [
+          980,
+          190
+        ]
+      ]
+    }
+  ]
+}

diagrams/strategy-stage01.architecture.json

@@ -0,0 +1,271 @@
+{
+  "schema_version": 1,
+  "diagram_type": "architecture",
+  "meta": {
+    "title": "TO-BE: stage01",
+    "output": "static/diagrams/strategy-stage01/index.html",
+    "quality_profile": "showcase",
+    "legend": {
+      "mode": "hidden"
+    },
+    "viewBox": [
+      2400,
+      1580
+    ]
+  },
+  "components": [
+    {
+      "id": "baseline",
+      "type": "external",
+      "label": "Understand + baseline",
+      "tag": "Product Engineering workflow owner",
+      "sublabel": "Workflow map + desired improvement\nSelected measures + starting evidence\nGovernance: people, scope, authority",
+      "pos": [
+        100,
+        100
+      ],
+      "size": [
+        600,
+        260
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "engineer",
+      "type": "external",
+      "label": "Choose an intervention",
+      "tag": "Owning team + independent reviewer",
+      "sublabel": "Context, coaching, tooling or skills\nPinned candidate + client + limits\nDeliver: patch and regression tests",
+      "pos": [
+        900,
+        100
+      ],
+      "size": [
+        600,
+        260
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "qualify",
+      "type": "security",
+      "label": "Fit for a bounded pilot?",
+      "tag": "Quality evidence \u2192 owning approver",
+      "sublabel": "Artifact + safety + regression report\nPass: authorize exact pilot scope\nFail / incomplete: hold or rework",
+      "pos": [
+        1700,
+        100
+      ],
+      "size": [
+        600,
+        260
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "pilot",
+      "type": "external",
+      "label": "Pilot real work",
+      "tag": "Human + AI Agent; independent review",
+      "sublabel": "Use qualified revision within scope\nAccepted / failed work + feedback\nManual path; no new release power",
+      "pos": [
+        1700,
+        730
+      ],
+      "size": [
+        600,
+        260
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "decide",
+      "type": "security",
+      "label": "Retain, improve or stop?",
+      "tag": "Workflow owner + reviewed evidence",
+      "sublabel": "Compare with baseline, not trials\nNo justified benefit: hold / stop\nNew scope: baseline + new approval",
+      "pos": [
+        900,
+        730
+      ],
+      "size": [
+        600,
+        260
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "maintain",
+      "type": "external",
+      "label": "Maintain + requalify",
+      "tag": "Owner, Quality, Platform & Security",
+      "sublabel": "Retain: support approved revision\nDrift / defects: revise and retest\nHarm: contain; never auto-restore",
+      "pos": [
+        100,
+        730
+      ],
+      "size": [
+        600,
+        260
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "reference",
+      "type": "backend",
+      "label": "Governance + Measurement",
+      "tag": "Throughout, not one-time gates",
+      "sublabel": "Left return: changed revision\nRight return: new scope needs baseline\nSelected evidence; no forced rollout",
+      "pos": [
+        100,
+        1270
+      ],
+      "size": [
+        2200,
+        260
+      ],
+      "icon": "none"
+    }
+  ],
+  "connections": [
+    {
+      "id": "baseline-engineer",
+      "from": "baseline",
+      "to": "engineer",
+      "label": "Map",
+      "fromSide": "right",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        800,
+        210
+      ]
+    },
+    {
+      "id": "engineer-qualify",
+      "from": "engineer",
+      "to": "qualify",
+      "label": "Candidate",
+      "fromSide": "right",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        1600,
+        210
+      ]
+    },
+    {
+      "id": "qualify-pilot",
+      "from": "qualify",
+      "to": "pilot",
+      "label": "Authorized",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          2000,
+          520
+        ]
+      ],
+      "labelAt": [
+        2010,
+        535
+      ]
+    },
+    {
+      "id": "pilot-decide",
+      "from": "pilot",
+      "to": "decide",
+      "label": "Outcomes",
+      "fromSide": "left",
+      "toSide": "right",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        1600,
+        840
+      ]
+    },
+    {
+      "id": "decide-maintain",
+      "from": "decide",
+      "to": "maintain",
+      "label": "Retain",
+      "fromSide": "left",
+      "toSide": "right",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        800,
+        840
+      ]
+    },
+    {
+      "id": "maintain-engineer",
+      "from": "maintain",
+      "to": "engineer",
+      "label": "Changed revision",
+      "fromSide": "top",
+      "toSide": "bottom",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          400,
+          550
+        ],
+        [
+          1200,
+          550
+        ]
+      ],
+      "labelAt": [
+        800,
+        535
+      ]
+    },
+    {
+      "id": "decide-baseline",
+      "from": "decide",
+      "to": "baseline",
+      "label": "New scope",
+      "fromSide": "bottom",
+      "toSide": "bottom",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          1200,
+          1150
+        ],
+        [
+          60,
+          1150
+        ],
+        [
+          60,
+          430
+        ],
+        [
+          400,
+          430
+        ]
+      ],
+      "labelAt": [
+        620,
+        1135
+      ]
+    }
+  ]
+}

diagrams/strategy-stage02-mobile.architecture.json

@@ -0,0 +1,212 @@
+{
+  "schema_version": 1,
+  "diagram_type": "architecture",
+  "meta": {
+    "title": "TO-BE: stage02",
+    "output": "static/diagrams/strategy-stage02-mobile/index.html",
+    "quality_profile": "showcase",
+    "legend": {
+      "mode": "hidden"
+    },
+    "viewBox": [
+      1000,
+      2540
+    ]
+  },
+  "components": [
+    {
+      "id": "proven",
+      "type": "external",
+      "label": "Dependable Stage 01",
+      "tag": "Existing human-directed workflow",
+      "sublabel": "Proven skills + limits + outcome record\nNo inherited autonomous authority",
+      "pos": [
+        200,
+        40
+      ],
+      "size": [
+        740,
+        300
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "case",
+      "type": "external",
+      "label": "Justify extra authority",
+      "tag": "Owning department proposes scope",
+      "sublabel": "Why needed? Exact data + effects\nObservation first, then proposals",
+      "pos": [
+        200,
+        450
+      ],
+      "size": [
+        740,
+        300
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "decision",
+      "type": "security",
+      "label": "Authorize or hold",
+      "tag": "Human decision; roles named first",
+      "sublabel": "Security: boundary; Quality: evidence\nPlatform & IT: enforcement + takeover\nOwning approver: exact permitted scope",
+      "pos": [
+        200,
+        860
+      ],
+      "size": [
+        740,
+        300
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "execute",
+      "type": "backend",
+      "label": "Bounded execution",
+      "tag": "Only within recorded authorization",
+      "sublabel": "Exact-artifact checks + audit\nChanged boundary: reopen decision",
+      "pos": [
+        200,
+        1270
+      ],
+      "size": [
+        740,
+        300
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "stop",
+      "type": "security",
+      "label": "Independent stop + takeover",
+      "tag": "Platform & IT + Security + owner",
+      "sublabel": "Revoke mutations; preserve evidence\nRecover manually; requalify correction",
+      "pos": [
+        200,
+        1680
+      ],
+      "size": [
+        740,
+        300
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "hold",
+      "type": "external",
+      "label": "Hold / return to Stage 01",
+      "tag": "Missing authority or readiness",
+      "sublabel": "Fix gaps, narrow scope or stay here\nNo automatic progression",
+      "pos": [
+        200,
+        2090
+      ],
+      "size": [
+        740,
+        300
+      ],
+      "icon": "none"
+    }
+  ],
+  "connections": [
+    {
+      "id": "proven-case",
+      "from": "proven",
+      "to": "case",
+      "label": "Need / limits",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        570,
+        405
+      ]
+    },
+    {
+      "id": "case-decision",
+      "from": "case",
+      "to": "decision",
+      "label": "Proposal",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        570,
+        815
+      ]
+    },
+    {
+      "id": "decision-execute",
+      "from": "decision",
+      "to": "execute",
+      "label": "Authorized",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        570,
+        1225
+      ]
+    },
+    {
+      "id": "execute-stop",
+      "from": "execute",
+      "to": "stop",
+      "label": "Harm / stop",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "security",
+      "labelAt": [
+        570,
+        1635
+      ]
+    },
+    {
+      "id": "decision-hold",
+      "from": "decision",
+      "to": "hold",
+      "label": "",
+      "fromSide": "left",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "security",
+      "via": [
+        [
+          105,
+          1010
+        ],
+        [
+          105,
+          2240
+        ]
+      ]
+    },
+    {
+      "id": "stop-hold",
+      "from": "stop",
+      "to": "hold",
+      "label": "Requalify",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "security",
+      "labelAt": [
+        570,
+        2045
+      ]
+    }
+  ]
+}

diagrams/strategy-stage02.architecture.json

@@ -0,0 +1,236 @@
+{
+  "schema_version": 1,
+  "diagram_type": "architecture",
+  "meta": {
+    "title": "TO-BE: stage02",
+    "output": "static/diagrams/strategy-stage02/index.html",
+    "quality_profile": "showcase",
+    "legend": {
+      "mode": "hidden"
+    },
+    "viewBox": [
+      2740,
+      1260
+    ]
+  },
+  "components": [
+    {
+      "id": "proven",
+      "type": "external",
+      "label": "Dependable Stage 01",
+      "tag": "Existing human-directed workflow",
+      "sublabel": "Proven skills + limits + outcome record\nNo inherited autonomous authority",
+      "pos": [
+        60,
+        100
+      ],
+      "size": [
+        680,
+        230
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "case",
+      "type": "external",
+      "label": "Justify extra authority",
+      "tag": "Owning department proposes scope",
+      "sublabel": "Why needed? Exact data + effects\nObservation first, then proposals",
+      "pos": [
+        60,
+        550
+      ],
+      "size": [
+        680,
+        230
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "decision",
+      "type": "security",
+      "label": "Authorize or hold",
+      "tag": "Human decision; roles named first",
+      "sublabel": "Security: boundary; Quality: evidence\nPlatform & IT: enforcement + takeover\nOwning approver: exact permitted scope",
+      "pos": [
+        1000,
+        340
+      ],
+      "size": [
+        720,
+        290
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "execute",
+      "type": "backend",
+      "label": "Bounded execution",
+      "tag": "Only within recorded authorization",
+      "sublabel": "Exact-artifact checks + audit\nChanged boundary: reopen decision",
+      "pos": [
+        1980,
+        100
+      ],
+      "size": [
+        680,
+        230
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "stop",
+      "type": "security",
+      "label": "Independent stop + takeover",
+      "tag": "Platform & IT + Security + owner",
+      "sublabel": "Revoke mutations; preserve evidence\nRecover manually; requalify correction",
+      "pos": [
+        1980,
+        650
+      ],
+      "size": [
+        680,
+        230
+      ],
+      "icon": "none"
+    },
+    {
+      "id": "hold",
+      "type": "external",
+      "label": "Hold / return to Stage 01",
+      "tag": "Missing authority or readiness",
+      "sublabel": "Fix gaps, narrow scope or stay here\nNo automatic progression",
+      "pos": [
+        1000,
+        960
+      ],
+      "size": [
+        720,
+        230
+      ],
+      "icon": "none"
+    }
+  ],
+  "connections": [
+    {
+      "id": "proven-case",
+      "from": "proven",
+      "to": "case",
+      "label": "Need / limits",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "labelAt": [
+        410,
+        440
+      ]
+    },
+    {
+      "id": "case-decision",
+      "from": "case",
+      "to": "decision",
+      "label": "Proposal",
+      "fromSide": "right",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          860,
+          665
+        ],
+        [
+          860,
+          485
+        ]
+      ],
+      "labelAt": [
+        860,
+        650
+      ]
+    },
+    {
+      "id": "decision-execute",
+      "from": "decision",
+      "to": "execute",
+      "label": "Authorized",
+      "fromSide": "right",
+      "toSide": "left",
+      "route": "straight",
+      "width": 4,
+      "variant": "default",
+      "via": [
+        [
+          1850,
+          485
+        ],
+        [
+          1850,
+          215
+        ]
+      ],
+      "labelAt": [
+        1840,
+        200
+      ]
+    },
+    {
+      "id": "execute-stop",
+      "from": "execute",
+      "to": "stop",
+      "label": "Harm / stop",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "security",
+      "labelAt": [
+        2320,
+        500
+      ]
+    },
+    {
+      "id": "decision-hold",
+      "from": "decision",
+      "to": "hold",
+      "label": "Hold",
+      "fromSide": "bottom",
+      "toSide": "top",
+      "route": "straight",
+      "width": 4,
+      "variant": "security",
+      "labelAt": [
+        1360,
+        810
+      ]
+    },
+    {
+      "id": "stop-hold",
+      "from": "stop",
+      "to": "hold",
+      "label": "Requalify",
+      "fromSide": "left",
+      "toSide": "right",
+      "route": "straight",
+      "width": 4,
+      "variant": "security",
+      "via": [
+        [
+          1840,
+          765
+        ],
+        [
+          1840,
+          1075
+        ]
+      ],
+      "labelAt": [
+        1840,
+        1060
+      ]
+    }
+  ]
+}

diagrams/strategy-target-mobile.architecture.json

@@ -0,0 +1,51 @@
+{
+  "schema_version": 1,
+  "diagram_type": "architecture",
+  "meta": {"title": "TO-BE: autonomous SDLC, human direction", "output": "static/diagrams/strategy-target-mobile/index.html", "quality_profile": "showcase", "legend": {"mode": "hidden"}},
+  "components": [
+    {"id":"agent","type":"security","label":"Autonomous agent","sublabel":"Human Controlled","pos":[140,200],"size":[360,120]},
+    {"id":"scope","type":"backend","label":"Scope","sublabel":"01","pos":[100,440],"size":[240,100]},
+    {"id":"architecture","type":"backend","label":"Architecture","sublabel":"02","pos":[100,660],"size":[240,100]},
+    {"id":"ui-ux","type":"backend","label":"UI/UX","sublabel":"03","pos":[100,880],"size":[240,100]},
+    {"id":"planning","type":"backend","label":"Planning","sublabel":"04","pos":[100,1100],"size":[240,100]},
+    {"id":"delivery","type":"backend","label":"Delivery","sublabel":"05","pos":[100,1320],"size":[240,100]},
+    {"id":"uat","type":"backend","label":"UAT","sublabel":"06","pos":[100,1540],"size":[240,100]},
+    {"id":"security","type":"backend","label":"Security","sublabel":"07","pos":[100,1760],"size":[240,100]},
+    {"id":"releases","type":"backend","label":"Releases","sublabel":"08","pos":[100,1980],"size":[240,100]},
+    {"id":"code-scope","type":"frontend","label":"AI Agent","sublabel":"Human-controlled","pos":[400,440],"size":[240,100]},
+    {"id":"code-architecture","type":"frontend","label":"AI Agent","sublabel":"Human-controlled","pos":[400,660],"size":[240,100]},
+    {"id":"code-ui-ux","type":"frontend","label":"AI Agent","sublabel":"Human-controlled","pos":[400,880],"size":[240,100]},
+    {"id":"code-planning","type":"frontend","label":"AI Agent","sublabel":"Human-controlled","pos":[400,1100],"size":[240,100]},
+    {"id":"code-delivery","type":"frontend","label":"AI Agent","sublabel":"Human-controlled","pos":[400,1320],"size":[240,100]},
+    {"id":"code-uat","type":"frontend","label":"AI Agent","sublabel":"Human-controlled","pos":[400,1540],"size":[240,100]},
+    {"id":"code-security","type":"frontend","label":"AI Agent","sublabel":"Human-controlled","pos":[400,1760],"size":[240,100]},
+    {"id":"code-releases","type":"frontend","label":"AI Agent","sublabel":"Human-controlled","pos":[400,1980],"size":[240,100]}
+  ],
+  "connections": [
+
+    {"id":"govern-scope","from":"agent","to":"scope","label":"","variant":"security","fromSide":"left","toSide":"left","via":[[60,260],[60,490]]},
+    {"id":"govern-architecture","from":"agent","to":"architecture","label":"","variant":"security","fromSide":"left","toSide":"left","via":[[60,260],[60,710]]},
+    {"id":"govern-ui-ux","from":"agent","to":"ui-ux","label":"","variant":"security","fromSide":"left","toSide":"left","via":[[60,260],[60,930]]},
+    {"id":"govern-planning","from":"agent","to":"planning","label":"","variant":"security","fromSide":"left","toSide":"left","via":[[60,260],[60,1150]]},
+    {"id":"govern-delivery","from":"agent","to":"delivery","label":"","variant":"security","fromSide":"left","toSide":"left","via":[[60,260],[60,1370]]},
+    {"id":"govern-uat","from":"agent","to":"uat","label":"","variant":"security","fromSide":"left","toSide":"left","via":[[60,260],[60,1590]]},
+    {"id":"govern-security","from":"agent","to":"security","label":"","variant":"security","fromSide":"left","toSide":"left","via":[[60,260],[60,1810]]},
+    {"id":"govern-releases","from":"agent","to":"releases","label":"","variant":"security","fromSide":"left","toSide":"left","via":[[60,260],[60,2030]]},
+    {"id":"stage-1","from":"scope","to":"architecture","label":"Then","variant":"emphasis","fromSide":"bottom","toSide":"top"},
+    {"id":"stage-2","from":"architecture","to":"ui-ux","label":"Then","variant":"emphasis","fromSide":"bottom","toSide":"top"},
+    {"id":"stage-3","from":"ui-ux","to":"planning","label":"Then","variant":"emphasis","fromSide":"bottom","toSide":"top"},
+    {"id":"stage-4","from":"planning","to":"delivery","label":"Then","variant":"emphasis","fromSide":"bottom","toSide":"top"},
+    {"id":"stage-5","from":"delivery","to":"uat","label":"Then","variant":"emphasis","fromSide":"bottom","toSide":"top"},
+    {"id":"stage-6","from":"uat","to":"security","label":"Then","variant":"emphasis","fromSide":"bottom","toSide":"top"},
+    {"id":"stage-7","from":"security","to":"releases","label":"Then","variant":"emphasis","fromSide":"bottom","toSide":"top"},
+    {"id":"stage-8","from":"releases","to":"scope","label":"Repeat indefinitely","variant":"emphasis","fromSide":"bottom","toSide":"top","via":[[220,2140],[680,2140],[680,380],[220,380]],"labelAt":[440,2180]},
+    {"id":"contribute-scope","from":"code-scope","to":"scope","label":"Contribute","variant":"dashed","fromSide":"left","toSide":"right"},
+    {"id":"contribute-architecture","from":"code-architecture","to":"architecture","label":"Contribute","variant":"dashed","fromSide":"left","toSide":"right"},
+    {"id":"contribute-ui-ux","from":"code-ui-ux","to":"ui-ux","label":"Contribute","variant":"dashed","fromSide":"left","toSide":"right"},
+    {"id":"contribute-planning","from":"code-planning","to":"planning","label":"Contribute","variant":"dashed","fromSide":"left","toSide":"right"},
+    {"id":"contribute-delivery","from":"code-delivery","to":"delivery","label":"Contribute","variant":"dashed","fromSide":"left","toSide":"right"},
+    {"id":"contribute-uat","from":"code-uat","to":"uat","label":"Contribute","variant":"dashed","fromSide":"left","toSide":"right"},
+    {"id":"contribute-security","from":"code-security","to":"security","label":"Contribute","variant":"dashed","fromSide":"left","toSide":"right"},
+    {"id":"contribute-releases","from":"code-releases","to":"releases","label":"Contribute","variant":"dashed","fromSide":"left","toSide":"right"}
+  ]
+}

diagrams/strategy-target.architecture.json

@@ -0,0 +1,51 @@
+{
+  "schema_version": 1,
+  "diagram_type": "architecture",
+  "meta": {"title": "TO-BE: autonomous SDLC, human direction", "output": "static/diagrams/strategy-target/index.html", "quality_profile": "showcase", "legend": {"mode": "hidden"}},
+  "components": [
+    {"id":"agent","type":"security","label":"Autonomous agent","sublabel":"Human Controlled","pos":[465,450],"size":[270,90]},
+    {"id":"scope","type":"backend","label":"Scope","sublabel":"01","pos":[510,187.5],"size":[180,75]},
+    {"id":"architecture","type":"backend","label":"Architecture","sublabel":"02","pos":[780,187.5],"size":[180,75]},
+    {"id":"ui-ux","type":"backend","label":"UI/UX","sublabel":"03","pos":[780,457.5],"size":[180,75]},
+    {"id":"planning","type":"backend","label":"Planning","sublabel":"04","pos":[780,727.5],"size":[180,75]},
+    {"id":"delivery","type":"backend","label":"Delivery","sublabel":"05","pos":[510,727.5],"size":[180,75]},
+    {"id":"uat","type":"backend","label":"UAT","sublabel":"06","pos":[240,727.5],"size":[180,75]},
+    {"id":"security","type":"backend","label":"Security","sublabel":"07","pos":[240,457.5],"size":[180,75]},
+    {"id":"releases","type":"backend","label":"Releases","sublabel":"08","pos":[240,187.5],"size":[180,75]},
+    {"id":"code-scope","type":"frontend","label":"AI Agent","sublabel":"Human-controlled","pos":[510,37.5],"size":[180,75]},
+    {"id":"code-architecture","type":"frontend","label":"AI Agent","sublabel":"Human-controlled","pos":[780,37.5],"size":[180,75]},
+    {"id":"code-ui-ux","type":"frontend","label":"AI Agent","sublabel":"Human-controlled","pos":[1005,457.5],"size":[180,75]},
+    {"id":"code-planning","type":"frontend","label":"AI Agent","sublabel":"Human-controlled","pos":[780,877.5],"size":[180,75]},
+    {"id":"code-delivery","type":"frontend","label":"AI Agent","sublabel":"Human-controlled","pos":[510,877.5],"size":[180,75]},
+    {"id":"code-uat","type":"frontend","label":"AI Agent","sublabel":"Human-controlled","pos":[240,877.5],"size":[180,75]},
+    {"id":"code-security","type":"frontend","label":"AI Agent","sublabel":"Human-controlled","pos":[15,457.5],"size":[180,75]},
+    {"id":"code-releases","type":"frontend","label":"AI Agent","sublabel":"Human-controlled","pos":[240,37.5],"size":[180,75]}
+  ],
+  "connections": [
+
+    {"id":"govern-scope","from":"agent","to":"scope","label":"","variant":"security","fromSide":"top","toSide":"bottom","route":"straight"},
+    {"id":"govern-architecture","from":"agent","to":"architecture","label":"","variant":"security","fromSide":"top","toSide":"bottom","via":[[600,345],[870,345]]},
+    {"id":"govern-ui-ux","from":"agent","to":"ui-ux","label":"","variant":"security","fromSide":"right","toSide":"left","route":"straight"},
+    {"id":"govern-planning","from":"agent","to":"planning","label":"","variant":"security","fromSide":"bottom","toSide":"top","via":[[600,645],[870,645]]},
+    {"id":"govern-delivery","from":"agent","to":"delivery","label":"","variant":"security","fromSide":"bottom","toSide":"top","route":"straight"},
+    {"id":"govern-uat","from":"agent","to":"uat","label":"","variant":"security","fromSide":"bottom","toSide":"top","via":[[600,645],[330,645]]},
+    {"id":"govern-security","from":"agent","to":"security","label":"","variant":"security","fromSide":"left","toSide":"right","route":"straight"},
+    {"id":"govern-releases","from":"agent","to":"releases","label":"","variant":"security","fromSide":"top","toSide":"bottom","via":[[600,345],[330,345]]},
+    {"id":"stage-1","from":"scope","to":"architecture","label":"Then","variant":"emphasis","fromSide":"right","toSide":"left"},
+    {"id":"stage-2","from":"architecture","to":"ui-ux","label":"Then","variant":"emphasis","fromSide":"bottom","toSide":"top"},
+    {"id":"stage-3","from":"ui-ux","to":"planning","label":"Then","variant":"emphasis","fromSide":"bottom","toSide":"top"},
+    {"id":"stage-4","from":"planning","to":"delivery","label":"Then","variant":"emphasis","fromSide":"left","toSide":"right"},
+    {"id":"stage-5","from":"delivery","to":"uat","label":"Then","variant":"emphasis","fromSide":"left","toSide":"right"},
+    {"id":"stage-6","from":"uat","to":"security","label":"Then","variant":"emphasis","fromSide":"top","toSide":"bottom"},
+    {"id":"stage-7","from":"security","to":"releases","label":"Then","variant":"emphasis","fromSide":"top","toSide":"bottom"},
+    {"id":"stage-8","from":"releases","to":"scope","label":"Repeat indefinitely","variant":"emphasis","fromSide":"right","toSide":"left","labelAt":[465,170]},
+    {"id":"contribute-scope","from":"code-scope","to":"scope","label":"Contribute","variant":"dashed","fromSide":"bottom","toSide":"top"},
+    {"id":"contribute-architecture","from":"code-architecture","to":"architecture","label":"Contribute","variant":"dashed","fromSide":"bottom","toSide":"top"},
+    {"id":"contribute-ui-ux","from":"code-ui-ux","to":"ui-ux","label":"Contribute","variant":"dashed","fromSide":"left","toSide":"right","labelAt":[990,570]},
+    {"id":"contribute-planning","from":"code-planning","to":"planning","label":"Contribute","variant":"dashed","fromSide":"top","toSide":"bottom"},
+    {"id":"contribute-delivery","from":"code-delivery","to":"delivery","label":"Contribute","variant":"dashed","fromSide":"top","toSide":"bottom"},
+    {"id":"contribute-uat","from":"code-uat","to":"uat","label":"Contribute","variant":"dashed","fromSide":"top","toSide":"bottom"},
+    {"id":"contribute-security","from":"code-security","to":"security","label":"Contribute","variant":"dashed","fromSide":"right","toSide":"left","labelAt":[220,570]},
+    {"id":"contribute-releases","from":"code-releases","to":"releases","label":"Contribute","variant":"dashed","fromSide":"bottom","toSide":"top"}
+  ]
+}

docs/contribution/diagrams.md

@@ -15,13 +15,15 @@ description: Author typed JSON diagrams and embed their local interactive viewer
 | Dataflow | Sources, processing and destinations |
 | Lifecycle | States and transitions |
 
-The standalone viewer provides pan/zoom, node inspection, search/focus, relationship tracing, light/dark themes, and an export menu. Motion is opt-in. The Organization views exercise architecture mode; other diagram types use the same build interface but do not yet have portal-specific examples. Browser-dependent exports such as video are not acceptance-tested by this integration.
+The standalone viewer provides pan/zoom, node inspection, search/focus, relationship tracing, light/dark themes, and an export menu. Motion is opt-in. The Organization views exercise architecture mode; Roadmap uses native Workflow v2 with a horizontal desktop path and the same stages stacked on mobile. Other diagram types use the same build interface but do not yet have portal-specific examples. Browser-dependent exports such as video are not acceptance-tested by this integration.
 
 ## Author a diagram
 
 Create `diagrams/<name>.<type>.json` using the matching schema and authoring guidance in `vendor/archify/schemas/` and `vendor/archify/references/`. Use stable IDs, explicit relationships, and honest evidence labels. Do not include private information merely because the source repository is private: Pages access is a separate platform policy.
 
-Set `meta.output` to `static/diagrams/<name>/index.html`. The build validates the typed source with the upstream showcase profile, renders locally, checks the artifact, and publishes the standalone HTML and a downloadable JSON source.
+Set `meta.output` to `static/diagrams/<name>/index.html`. The build validates the typed source with the upstream showcase profile, renders locally, checks the artifact, and publishes the standalone HTML. Editable JSON stays in the repository; the portal does not publish source-download files.
+
+Roadmap has a scoped multiline typography adapter in `scripts/roadmap-viewer.mjs`. Its two `.workflow.json` sources use the native v2 schema, one lane, `mainPath`, logical columns and native routes. The native renderer validates the schema and solves geometry; the adapter wraps the existing action/output/exit copy, removes the redundant lane frame and trims empty canvas. The final artifact then passes the upstream showcase composition checker. This path records source, adapter and final artifact hashes in private `.cache/archify/*.portal.json` receipts, not upstream `deliver` provenance. Keep the vendor unchanged and run the Roadmap browser check at 1440, 390 and 320 pixels after any copy or sizing change. Typography is embedded in the SVG so exports retain it.
 
 ```sh
 pnpm diagrams:build
@@ -37,7 +39,7 @@ import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
 <ArchifyDiagram name="organization-structure" title="Eldorado organization structure" />
 ```
 
-Supply a text alternative below each diagram. The wrapper uses a local, base-path-aware iframe with a descriptive title, scripts and downloads enabled, and no same-origin or parent-navigation permissions. The Open full viewer button expands the diagram in a full-screen modal on the current page, with the same iframe sandbox. Close it with the Close button or Escape; focus returns to the opener. It does not open a new tab. The separate standalone HTML asset remains directly addressable and is not itself iframe-sandboxed, so publish only reviewed, trusted diagrams. Generated output is ignored by Git and rebuilt in CI.
+Supply a text alternative below each diagram. The wrapper uses a local, base-path-aware iframe with a descriptive title, scripts and downloads enabled, and no same-origin or parent-navigation permissions. The top-right expand icon expands the diagram in a full-screen modal on the current page, with the same iframe sandbox. Close it with the Close button or Escape; focus returns to the opener. It does not open a new tab. The separate standalone HTML asset remains directly addressable and is not itself iframe-sandboxed, so publish only reviewed, trusted diagrams. Generated output is ignored by Git and rebuilt in CI.
 
 ## Integration boundaries
 

docs/core/maintain.md

@@ -28,7 +28,10 @@ Include `title` and `description` frontmatter. Place each page in its owning sec
 | Contribution | `docs/contribution/` | `sidebars/contribution.ts` |
 | Portal maintenance and reference | `docs/core/` | `sidebars.ts` |
 
-Keep these content roots disjoint. Preserve existing URLs when moving pages. Specific AI initiatives and organizational reporting lines remain subject to agreement.
+Keep these content roots disjoint. Preserve existing URLs unless a URL migration is explicitly approved; provide precise redirects for approved moves. Metric details live on individual canonical pages directly under Measurement, alongside shared collection safeguards and the synthetic example. Specific AI initiatives and organizational reporting lines remain subject to agreement.
+Every published documentation page must have a navigable sidebar entry. Nested references are welcome; hidden documentation is not. Linked category overviews count as entries, but an in-page anchor is not a separate document. Portal-maintenance pages keep their existing `/docs/` routes and dedicated sidebar, reachable from Contribution → Portal maintenance.
+
+`pnpm verify:build` compares all Docusaurus-generated document IDs/routes with resolved sidebar trees (including linked category overviews), checks reachability from the navbar, rejects missing/duplicate entries and unclassified HTML routes, and checks every document’s local links and anchors. The inventory is written to `.cache/sidebar-coverage.json`. Only the homepage, not-found page, search-results UI, legacy Strategy redirect, exact legacy measurement-contracts hash-aware redirect and standalone diagram viewers are non-document HTML routes; no documentation page is exempt. The metric migration manifest in `research/ai-adoption/measurement-migration.json` records old anchors, canonical IDs/URLs, implementation status and preserved-contract hashes.
 
 ## Validate the change
 

docs/organization/collaboration.mdx

@@ -0,0 +1,23 @@
+---
+title: Collaboration
+description: How Eldorado departments combine their responsibilities to deliver shared business outcomes.
+---
+
+Departments collaborate around shared outcomes while retaining their own team ownership and accountability. See [Structure](./structure.mdx) for department and squad responsibilities.
+
+## How the departments work together
+
+| Business outcome | Collaboration |
+| --- | --- |
+| Better buyer experience | Product defines improvements; Technology delivers them; Operations brings customer feedback; Data & AI measures the result. |
+| Stronger seller experience | Product and Technology develop seller tools; Operations supports sellers; Finance manages financial processes. |
+| Safe and trustworthy trading | Risk & Fraud, Trust & Resolution, Architecture & Security, and Finance coordinate controls and incident responses. |
+| Sustainable growth | Marketing develops demand; Product improves conversion and retention; Finance measures profitability. |
+| AI-powered execution | Data & AI supports engineering and develops marketplace intelligence; Operations improves service and quality workflows. |
+
+Department leaders remain accountable for outcomes, controls and service quality as AI becomes part of everyday work.
+
+## Related pages
+
+- [Structure](./structure.mdx) — departments, squads and responsibilities.
+- [SDLC — Software Delivery Life Cycle](./sdlc.mdx) — leadership and delivery responsibilities.

docs/organization/sdlc.mdx

@@ -0,0 +1,27 @@
+---
+title: SDLC — Software Delivery Life Cycle
+sidebar_label: SDLC
+description: Leadership, reporting lines and team responsibilities supporting software delivery at Eldorado.
+---
+
+import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
+
+Software delivery brings together Product and Technology, supported by the departments responsible for marketplace operations and growth. This page describes the leadership and delivery responsibilities that support that work.
+
+## Leadership and delivery structure
+
+<ArchifyDiagram name="organization-reporting" compact title="Eldorado leadership and delivery structure" />
+
+The diagram shows management responsibility from leader to role or team:
+
+- **CTO → Head of Engineering → Group Engineering Managers → Engineering Managers → the Product Engineering team.**
+- **CTO → AI Architect**, coordinating engineering AI enablement.
+- **COO → Operational Quality**, providing independent quality oversight.
+- **CMO → Brand Team Lead**, leading Brand & Community.
+
+Product and Technology retain separate team ownership and reporting lines. Their teams coordinate priorities, design, engineering, quality and data work to deliver business outcomes.
+
+## Related pages
+
+- [Structure](./structure.mdx) — departments, squads and responsibilities.
+- [Collaboration](./collaboration.mdx) — how departments coordinate around business outcomes.

docs/organization/structure.mdx

@@ -1,5 +1,6 @@
 ---
 title: Structure
+pagination_next: structure/product
 description: Eldorado’s organizational operating model, departments, teams and responsibilities.
 ---
 
@@ -22,126 +23,18 @@ Functional leaders translate company priorities into departmental plans. Team le
 
 **Management coordinates the six departments.** Each department has a clear business responsibility and a set of teams that deliver it.
 
-## Product & Technology squads
-
-Product and Technology share a delivery structure of **up to seven cross-functional squads**. Product sets priorities and business outcomes; Technology provides engineering leadership, technical standards and delivery capability.
-
-| Squad | Scope |
-| --- | --- |
-| **Discovery & Categories** | Browsing, search, category journeys and marketplace conversion. |
-| **Orders & Delivery** | Purchase and post-purchase experience, order tracking, delivery and customer feedback. |
-| **Seller Platform** | Seller Portal, onboarding, integrations and seller-facing tools. |
-| **Payments & Wallet** | Checkout, balances, withdrawals and payout integrations, working with Finance. |
-| **Trust & Safety** | Risk controls, dispute tooling and safety workflows, working with Operations. |
-| **Data & Intelligence** | Analytics, experimentation, offer ranking, recommendations and marketplace ML. |
-| **Platform & AI** | Shared platform, reliability, delivery infrastructure and engineering AI tools. |
-
-Each squad brings together product ownership, engineering, design, quality and data expertise according to its scope. Departmental teams and specialist functions below support these squads; they are not additional delivery squads. Operations retains ownership of customer cases and risk decisions, while Finance retains ownership of financial controls.
-
 ## Departments and teams
 
-### Product
+Product has **two teams** and Technology has **five teams**. Operations, Marketing, Finance & Accounting, and HR & Administration each have **one squad** covering their departmental workstreams. Each team belongs to one department, with its own leadership and responsibilities. The departments collaborate on delivery without sharing team ownership.
 
-**Purpose:** improve the buyer and seller experience and turn marketplace opportunities into valuable product capabilities.
+- <span id="product">[Product](./structure/product.mdx)</span>
+- <span id="technology">[Technology](./structure/technology.mdx)</span>
+- <span id="operations">[Operations](./structure/operations.mdx)</span>
+- <span id="marketing">[Marketing](./structure/marketing.mdx)</span>
+- <span id="finance--accounting">[Finance & Accounting](./structure/finance-accounting.mdx)</span>
+- <span id="hr--administration">[HR & Administration](./structure/hr-administration.mdx)</span>
 
-| Team | Responsibilities |
-| --- | --- |
-| Orders | Purchase and post-purchase journeys, order status, delivery experience, dispute flows, feedback and loyalty. |
-| Categories | Category experiences, including Boosting and Currency, discovery, conversion and category-specific user journeys. |
-| Sellers & Operations | Seller Portal, seller integrations, onboarding and verification, balances and withdrawals, invoicing and operational tooling. |
-| Data & Intelligence | Product analytics, experimentation, offer ranking, recommendations and decision support. |
-| Product Design | User research, interaction design, design consistency and accessible buyer and seller experiences across product teams. |
+## Related pages
 
-Product Owners, Designers and Tech Leads work together on each product area. Product owns priorities and outcomes; Technology owns engineering execution and technical quality.
-
-### Technology
-
-**Purpose:** build and operate a secure, reliable marketplace and improve the effectiveness of engineering.
-
-| Team / function | Responsibilities |
-| --- | --- |
-| Product Engineering | Develop and maintain marketplace capabilities in cross-functional product teams. |
-| Platform & Reliability | Shared platform services, delivery infrastructure, observability, availability and performance. |
-| Architecture & Security | Technical standards, system design, infrastructure security and secure engineering practices. |
-| Quality Engineering | Test strategy, automation, release quality and defect prevention. |
-| AI Enablement | AI-assisted engineering workflows, developer tools, adoption, standards and safe use of AI. |
-| Internal IT | Identity and access, employee devices, internal systems, software administration and joiner–mover–leaver processes. |
-
-The CTO owns technology direction. The Head of Engineering leads engineering delivery through Group Engineering Managers and Engineering Managers. The AI Architect coordinates AI enablement across engineering, working with Architecture & Security and team leaders.
-
-### Operations
-
-**Purpose:** keep marketplace trading dependable and resolve customer issues fairly and efficiently.
-
-| Team | Responsibilities |
-| --- | --- |
-| Customer Support | Buyer and seller assistance, knowledge management, self-service and support workflow automation. |
-| Trust & Resolution | Disputes, appeals, refunds, warranties, chargebacks and complex customer cases. |
-| Risk & Fraud | Transaction and account risk, fraud prevention, investigations and operational controls. |
-| Operational Quality | Independent case reviews, quality standards, calibration, service accuracy and improvement tracking across operational teams. |
-
-The COO coordinates Operations. Team leads manage specialists and daily service delivery. Operational Quality reports directly to the COO and reviews quality across teams.
-
-### Marketing
-
-**Purpose:** attract and retain customers, build the Eldorado brand and grow marketplace demand.
-
-| Team / workstream | Responsibilities |
-| --- | --- |
-| Brand & Community | Brand positioning, campaigns, organic social, community and brand partnerships. |
-| Creative | Campaign concepts, visual assets and performance creative. |
-| SEO | Organic discovery, search visibility and content performance. |
-| PPC & Affiliate | Paid acquisition, affiliate channels and return on marketing investment. |
-| Influencer | Creator relationships, influencer programs and campaign delivery. |
-| CRM | Customer lifecycle communication, retention, reactivation and campaign personalization. |
-
-The CMO coordinates Marketing. The Brand Team Lead owns Brand & Community, with shared support from Creative and the other marketing workstreams.
-
-### Finance & Accounting
-
-**Purpose:** maintain financial control, support business decisions and keep marketplace money flows dependable.
-
-| Team / function | Responsibilities |
-| --- | --- |
-| Financial Planning & Analysis | Budgets, forecasts, profitability, management reporting and investment analysis. |
-| Accounting, Tax & Controls | Accounting, financial reporting, tax, audit coordination and internal controls. |
-| Treasury & Payment Operations | Cash management, reconciliation, payout oversight, payment-provider coordination and financial risk. |
-
-The CFO coordinates Finance & Accounting and works with executive leadership on business performance. Finance, Operations and Product share responsibility for effective payment and withdrawal processes, each within its own area of expertise.
-
-### HR & Administration
-
-**Purpose:** help teams attract, develop and retain people and provide an effective working environment.
-
-| Team | Responsibilities |
-| --- | --- |
-| Talent Acquisition | Recruitment, candidate experience, hiring coordination and workforce demand support. |
-| People Operations | Employee onboarding, development, performance processes, policies and employee experience. |
-| Office & Administration | Workplace services, office operations and administrative coordination. |
-
-HR partners with department leaders on team capacity and development. People Operations works with Internal IT on employee onboarding, role changes and offboarding.
-
-## Leadership and delivery structure
-
-<ArchifyDiagram name="organization-reporting" title="Eldorado leadership and delivery structure" />
-
-The diagram shows management responsibility from leader to role or team:
-
-- **CTO → Head of Engineering → Group Engineering Managers → Engineering Managers → Product Engineering teams.**
-- **CTO → AI Architect**, coordinating engineering AI enablement.
-- **COO → Operational Quality**, providing independent quality oversight.
-- **CMO → Brand Team Lead**, leading Brand & Community.
-
-Product teams combine product ownership, design, engineering, quality and data expertise. Functional management develops people and professional standards; cross-functional teams deliver business outcomes.
-
-## How the departments work together
-
-| Business outcome | Collaboration |
-| --- | --- |
-| Better buyer experience | Product defines improvements; Technology delivers them; Operations brings customer feedback; Data measures the result. |
-| Stronger seller experience | Product and Technology develop seller tools; Operations supports sellers; Finance manages financial processes. |
-| Safe and trustworthy trading | Risk & Fraud, Trust & Resolution, Architecture & Security, and Finance coordinate controls and incident responses. |
-| Sustainable growth | Marketing develops demand; Product improves conversion and retention; Finance measures profitability. |
-| AI-powered execution | AI Enablement supports engineering; Data & Intelligence develops marketplace intelligence; Operations improves service and quality workflows. |
-
-Department leaders remain accountable for outcomes, controls and service quality as AI becomes part of everyday work.
+- [Collaboration](./collaboration.mdx) — how departments work together on business outcomes.
+- [SDLC — Software Delivery Life Cycle](./sdlc.mdx) — leadership and delivery responsibilities.

docs/organization/structure/finance-accounting.mdx

@@ -0,0 +1,20 @@
+---
+title: Finance & Accounting
+pagination_prev: structure/marketing
+pagination_next: structure/hr-administration
+description: Finance & Accounting purpose, teams and responsibilities in Eldorado’s operating model.
+---
+
+**Purpose:** maintain financial control, support business decisions and keep marketplace money flows dependable.
+
+**Finance & Accounting Squad** delivers the department’s responsibilities across the following workstreams.
+
+| Workstream | Responsibilities |
+| --- | --- |
+| Financial Planning & Analysis | Budgets, forecasts, profitability, management reporting and investment analysis. |
+| Accounting, Tax & Controls | Accounting, financial reporting, tax, audit coordination and internal controls. |
+| Treasury & Payment Operations | Cash management, reconciliation, payout oversight, payment-provider coordination and financial risk. |
+
+The CFO coordinates Finance & Accounting and works with executive leadership on business performance. Finance, Operations and Product share responsibility for effective payment and withdrawal processes, each within its own area of expertise.
+
+[Return to Structure overview](../structure.mdx)

docs/organization/structure/hr-administration.mdx

@@ -0,0 +1,20 @@
+---
+title: HR & Administration
+pagination_prev: structure/finance-accounting
+pagination_next: collaboration
+description: HR & Administration purpose, teams and responsibilities in Eldorado’s operating model.
+---
+
+**Purpose:** help teams attract, develop and retain people and provide an effective working environment.
+
+**People & Administration Squad** delivers the department’s responsibilities across the following workstreams.
+
+| Workstream | Responsibilities |
+| --- | --- |
+| Talent Acquisition | Recruitment, candidate experience, hiring coordination and workforce demand support. |
+| People Operations | Employee onboarding, development, performance processes, policies and employee experience. |
+| Office & Administration | Workplace services, office operations and administrative coordination. |
+
+HR partners with department leaders on team capacity and development. People Operations works with Platform & IT on employee onboarding, role changes and offboarding.
+
+[Return to Structure overview](../structure.mdx)

docs/organization/structure/marketing.mdx

@@ -0,0 +1,23 @@
+---
+title: Marketing
+pagination_prev: structure/operations
+pagination_next: structure/finance-accounting
+description: Marketing purpose, teams and responsibilities in Eldorado’s operating model.
+---
+
+**Purpose:** attract and retain customers, build the Eldorado brand and grow marketplace demand.
+
+**Marketing Squad** delivers the department’s responsibilities across the following workstreams.
+
+| Workstream | Responsibilities |
+| --- | --- |
+| Brand & Community | Brand positioning, campaigns, organic social, community and brand partnerships. |
+| Creative | Campaign concepts, visual assets and performance creative. |
+| SEO | Organic discovery, search visibility and content performance. |
+| PPC & Affiliate | Paid acquisition, affiliate channels and return on marketing investment. |
+| Influencer | Creator relationships, influencer programs and campaign delivery. |
+| CRM | Customer lifecycle communication, retention, reactivation and campaign personalization. |
+
+The CMO coordinates Marketing. The Brand Team Lead owns Brand & Community, with shared support from Creative and the other marketing workstreams.
+
+[Return to Structure overview](../structure.mdx)

docs/organization/structure/operations.mdx

@@ -0,0 +1,21 @@
+---
+title: Operations
+pagination_prev: structure/technology
+pagination_next: structure/marketing
+description: Operations purpose, teams and responsibilities in Eldorado’s operating model.
+---
+
+**Purpose:** keep marketplace trading dependable and resolve customer issues fairly and efficiently.
+
+**Operations Squad** delivers the department’s responsibilities across the following workstreams.
+
+| Workstream | Responsibilities |
+| --- | --- |
+| Customer Support | Buyer and seller assistance, knowledge management, self-service and support workflow automation. |
+| Trust & Resolution | Disputes, appeals, refunds, warranties, chargebacks and complex customer cases. |
+| Risk & Fraud | Transaction and account risk, fraud prevention, investigations and operational controls. |
+| Operational Quality | Independent case reviews, quality standards, calibration, service accuracy and improvement tracking across operational teams. |
+
+The COO coordinates Operations. Team leads manage specialists and daily service delivery. Operational Quality reports directly to the COO and reviews quality across teams.
+
+[Return to Structure overview](../structure.mdx)

docs/organization/structure/product.mdx

@@ -0,0 +1,17 @@
+---
+title: Product
+pagination_prev: structure
+pagination_next: structure/technology
+description: Product purpose, teams and responsibilities in Eldorado’s operating model.
+---
+
+**Purpose:** improve the buyer and seller experience and turn marketplace opportunities into valuable product capabilities.
+
+| Team | Responsibilities |
+| --- | --- |
+| Product Management | Product strategy, roadmaps, priorities and outcome measurement across discovery, categories, orders, seller tools, payments and operational workflows. |
+| Product Design | User research, interaction design, design consistency and accessible buyer and seller experiences. |
+
+Product Management owns what to improve and why. Product Design shapes the experience. Both work with Technology teams while remaining within Product.
+
+[Return to Structure overview](../structure.mdx)

docs/organization/structure/technology.mdx

@@ -0,0 +1,20 @@
+---
+title: Technology
+pagination_prev: structure/product
+pagination_next: structure/operations
+description: Technology purpose, teams and responsibilities in Eldorado’s operating model.
+---
+
+**Purpose:** build and operate a secure, reliable marketplace and improve the effectiveness of engineering.
+
+| Team | Responsibilities |
+| --- | --- |
+| Product Engineering | Build and maintain marketplace capabilities, including search, orders, seller tools, checkout, wallet and operational tooling. |
+| Platform & IT | Platform services, delivery infrastructure, observability, reliability, performance, internal systems, employee devices and identity administration. |
+| Architecture & Security | Technical standards, system design, security architecture and secure engineering practices. |
+| Quality Engineering | Test strategy, automation, release quality and defect prevention. |
+| Data & AI | Analytics, experimentation, ranking, recommendations, marketplace ML and safe AI-assisted engineering workflows. |
+
+The CTO owns technology direction. The Head of Engineering leads engineering delivery through Group Engineering Managers and Engineering Managers. The AI Architect coordinates AI enablement within Data & AI, working with Architecture & Security and the other Technology teams. These are leadership roles within the five-team structure, not additional teams.
+
+[Return to Structure overview](../structure.mdx)

docs/strategy/baseline.mdx

@@ -0,0 +1,66 @@
+---
+id: baseline
+title: Baseline
+sidebar_label: Baseline
+description: Understand a workflow, select relevant candidate metrics and establish feasible starting evidence for later comparison.
+pagination_prev: measurement/index
+pagination_next: skills-governance
+hide_table_of_contents: true
+---
+
+import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
+
+<div className="strategy-content">
+
+Establish a starting position for one workflow before choosing an intervention in months 1–2 of the [6 Months Roadmap](./six-months-roadmap.mdx). Baseline current uneven AI-assisted practice, not an assumed no-AI organization. This is not a mandatory company-wide baseline of every metric in the [Measurement registry](./measurement/index.mdx). The [EXP-01 packet](./six-months-roadmap.mdx#exp-01-a-small-decision-ready-example) assembles a practical comparison and budget. Departmental role names below are proposed functions to map with the partner team, not verified company appointments.
+
+<ArchifyDiagram name="strategy-baseline" title="From current workflow through relevant selection and feasible evidence to a starting position and later comparison" story />
+
+**Target operating model — no actual baseline values or approved thresholds are established here.** Missing evidence remains an explicit gap, not an invented starting value.
+
+## Delivery example: know what must improve
+
+In the [illustrative Delivery workflow](./stage-01-skills-adoption.mdx), Product Engineering maps a bounded code change through regression tests, independent review and existing release controls. Suppose the concern is repeated rework because regression evidence is incomplete: first verify the cause from actual changes, rather than assuming a skill will fix it.
+
+Consider accepted-task outcomes, escaped-quality follow-up and review/rework inputs to cost if their contracts fit. Select only evidence that can inform that concern; deployment frequency need not help. The output is a workflow map and comparison record, not a pass/fail score. The owning team's designated workflow owner confirms scope with the independent Quality Engineering reviewer; unresolved source or acceptance gaps limit later conclusions, not authorize a pilot.
+
+## Understand the current workflow
+
+Describe the task, team or service, intended outcome, current tools, handoffs, controls and known friction. Bound what is in and out of scope. For Delivery, start with codebase structure and existing principles, system-logic sources, tests, builds and packaging, then deployments. Record current practice, including any existing AI use; do not label it “no-skill” unless that is true.
+
+## Select relevant metrics, with reasons
+
+Start with **Workflow effectiveness**: select relevant current-workflow outcomes before standardized skills adoption—accepted work, delivery time, failures/rework, cost, human effort/experience or business acceptance where the contracts apply. Choose the registry entries that answer this workflow's questions. Record why each selected metric applies, what decision it can inform, and why other candidates are irrelevant or deferred. There is no required universal subset. A service-level DORA metric, a qualification test and a people survey have different populations; they are not interchangeable.
+
+Keep **Skills effectiveness & health** separate. If no applicable skills exist, selection, bundle, adoption and review measures may be N/A, not zero; they are not prerequisites for baselining current work. If skills already exist, record that starting context and qualify named revisions separately. Do not mix sandbox skill evaluations into validated workflow task success or live policy-effect rates.
+
+Agree what counts as a started task, independent acceptance and completed follow-up before counting outcomes. Freeze eligibility and acceptance rules and verify event joins. Select a complete comparable workflow cycle and a predeclared precision/sample requirement appropriate to the decision. Do not select a convenient end date after seeing results. Where those requirements cannot be met, record the resulting evidence limitation.
+
+## Agree feasible evidence
+
+Confirm collection feasibility, period, sources, owner, independent reviewer, access, lawful basis, privacy and retention before collecting. Use the [shared safeguards](./measurement/collection-and-safeguards.mdx) and each selected contract's input requirements. Proposed owner/cadence entries are not already assigned responsibilities.
+
+Start with a controlled worksheet or export if automation is unavailable. Join task IDs to acceptance records, PR/commit IDs, CI results and later defects where relevant; test source coverage and permissions. Repository and CI evidence support verification, but a green build alone is not task acceptance. Record exact skill revisions and client/model configurations when present; keep missing versions unknown.
+
+## Record the starting position
+
+Collect prospective current-practice evidence over the agreed period. Record actual starting values only when supported by traceable evidence. Include units, population, observation period, counts, exclusions, source coverage, calculation version, uncertainty and limitations. Zero denominators mean “not available,” not zero performance.
+
+For each selected metric, keep one of these explicit records:
+
+- **Available:** evidenced starting value, source links, calculation, owner and limits.
+- **Unavailable:** missing input or permission, affected comparison, responsible owner and proposed next action or review point. Never fill the gap with the synthetic example or an assumed industry value.
+
+Record deferred and non-applicable candidates separately from selected-but-unavailable metrics. This page is the recording method, not an Eldorado baseline report or a set of approved targets.
+
+## Keep later evaluation comparable
+
+Retain task class, service, skill, client/model configuration and concurrent changes. In [Adoption](./skills-adoption.mdx), use the same agreed eligibility, acceptance and observation rules; in [Maintenance](./skills-maintenance.mdx), record any changes and breaks in comparability rather than silently replacing the starting position.
+
+A matched or randomized comparison may be used when practical and ethical. Label observational trends as descriptive, not causal ROI; report confounding, selection and uncertainty. Missing or small samples limit conclusions. Baseline values describe current practice; they do not establish acceptable risk or authorize expansion.
+
+**Next:** [Govern skill ownership and authority →](./skills-governance.mdx)
+
+Carry the map, selected definitions and evidence limits into candidate design. Return here from [Adoption](./skills-adoption.mdx) when scope changes, or from [Maintenance](./skills-maintenance.mdx) when the current workflow no longer matches the comparison. See the [whole Stage 01 journey](./stage-01-skills-adoption.mdx).
+
+</div>

docs/strategy/direction.md

@@ -1,11 +0,0 @@
----
-title: Direction
-description: Define the strategy and direction for an AI-powered Eldorado.
-slug: /
----
-
-# Strategy and direction
-
-**Eldorado Powered By AI** is the space for shaping how AI can support Eldorado.
-
-Specific initiatives, priorities, measures of success, and a delivery roadmap remain to be agreed. This section is ready for that work; no proposals here should be treated as approved commitments until explicitly agreed.

docs/strategy/measurement/approved-workflow-adoption.mdx

@@ -0,0 +1,38 @@
+---
+id: approved-workflow-adoption
+slug: /measurement/approved-workflow-adoption
+title: Approved-workflow adoption
+description: Definition, collection evidence and limitations for approved-workflow adoption.
+---
+
+<div className="strategy-content">
+
+**Target operating model — recommended contracts, not installed collection.** All owner and cadence entries below are proposals to confirm before the pilot, not assigned responsibilities or approved schedules.
+
+**Unimplemented metric — no live telemetry.** This is a prospective contract, not an implemented calculation or collector.
+
+{/* contract:start */}
+Eligible participants with at least one approved-skill workflow use; usefulness assessed separately through accepted outcomes and feedback.
+
+| Contract | Definition |
+| --- | --- |
+| Numerator | Distinct eligible pseudonymous participants with workflow-linked skill.used on approved revision |
+| Denominator | Distinct eligible participants in frozen invited cohort |
+| Expression | N / D * 100 |
+| Aggregation | percent |
+| Unit | % |
+| Eligible population | Consented or otherwise lawfully enrolled pilot cohort for the period; supported workflow available. |
+| Exclusions | Outside pilot and formally recorded leave before period; nonresponders remain eligible, not excluded. |
+| Events and source | skill.used; cohort.snapshot; optional qualified client adapter or declaration |
+| Owner / cadence | Data & AI / Monthly |
+| Missing evidence | Show observed lower bound and telemetry/response coverage; missing usage unknown rather than non-use. |
+| Gaming and limits | Invocation quotas and coercion; no target usage count, split server/client/self-report origins. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Self-report is not verified use; installation/loading is not use or benefit. Suppress small groups. |
+{/* contract:end */}
+
+Read the shared [collection and safeguards](./collection-and-safeguards.mdx) before collecting data; see the [synthetic example and limits](./synthetic-example.mdx).
+
+Return to [Skills Measurement](./index.mdx).
+
+In [Stage 01](../stage-01-skills-adoption.mdx), authorization to test an experimental revision is not general approved status. This contract counts approved-revision use only; do not relabel experimental pilot use to raise its numerator. [Adoption](../skills-adoption.mdx) still evaluates that pilot through independent work outcomes and [Quality's fitness evidence](../skills-quality.mdx). Use this reach measure only where its approved-revision population applies.
+
+</div>

docs/strategy/measurement/change-fail-rate.mdx

@@ -0,0 +1,36 @@
+---
+id: change-fail-rate
+slug: /measurement/change-fail-rate
+title: Change fail rate
+description: Definition, collection evidence and limitations for change fail rate.
+---
+
+<div className="strategy-content">
+
+**Target operating model — recommended contracts, not installed collection.** All owner and cadence entries below are proposals to confirm before the pilot, not assigned responsibilities or approved schedules.
+
+**Prototype calculation — no live telemetry.** The synthetic example calculates this metric; it has no network collectors.
+
+{/* contract:start */}
+Production deployment effects requiring unplanned remediation, rollback or hotfix, not solely outage declarations.
+
+| Contract | Definition |
+| --- | --- |
+| Numerator | Distinct matured production deployment_ids linked to qualifying immediate intervention |
+| Denominator | All distinct production deployment_ids that reached production in the matured deployment cohort |
+| Expression | N / D * 100 |
+| Aggregation | percent |
+| Unit | % |
+| Eligible population | Deployments with production effect during window and approved intervention follow-up horizon elapsed. |
+| Exclusions | Failed preproduction attempts, duplicate callbacks and no-effect retries; failures after production effect stay included. |
+| Events and source | deployment.completed; deployment.failed; incident.linked; release and incident records |
+| Owner / cadence | Quality Engineering / Weekly; finalized after horizon |
+| Missing evidence | Known failures / all eligible deployments is a lower bound where incident linkage incomplete; label provisional and report unknown links. |
+| Gaming and limits | Avoid incident links or relabel intervention planned; reconcile rollbacks/hotfixes independently. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Define immediate intervention and follow-up horizon before pilot; no universal incident-to-AI attribution. |
+{/* contract:end */}
+
+Read the shared [collection and safeguards](./collection-and-safeguards.mdx) before collecting data; see the [synthetic example and limits](./synthetic-example.mdx).
+
+Return to [Skills Measurement](./index.mdx).
+
+</div>

docs/strategy/measurement/change-lead-time.mdx

@@ -0,0 +1,36 @@
+---
+id: change-lead-time
+slug: /measurement/change-lead-time
+title: Change lead time
+description: Definition, collection evidence and limitations for change lead time.
+---
+
+<div className="strategy-content">
+
+**Target operating model — recommended contracts, not installed collection.** All owner and cadence entries below are proposals to confirm before the pilot, not assigned responsibilities or approved schedules.
+
+**Unimplemented metric — no live telemetry.** This is a prospective contract, not an implemented calculation or collector.
+
+{/* contract:start */}
+Arithmetic mean commit-to-first-successful-production-deployment duration; also publish median/p90 and sample count.
+
+| Contract | Definition |
+| --- | --- |
+| Numerator | Sum of elapsed hours from committed_at to first successful production deployment for each service+commit |
+| Denominator | Count of eligible service+commit pairs with valid mappings |
+| Expression | N / D |
+| Aggregation | mean |
+| Unit | hours/change |
+| Eligible population | Changes first successfully deployed to a service in reporting window; rollout retries collapse to same logical deployment. |
+| Exclusions | Nonproduction, duplicates, no-op deployment with no new commits; missing mappings shown as coverage loss. |
+| Events and source | change.committed; deployment.completed; VCS immutable commit timestamps and release manifest |
+| Owner / cadence | Platform & IT / Weekly per service |
+| Missing evidence | Missing commit mapping or negative/skewed duration excluded from numeric sample, reported explicitly; no zero substitution. |
+| Gaming and limits | Timestamp rewriting and cherry-picking fast work; lock change mapping and show undeployed backlog age. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Not PR cycle time, effort saved, or a complete view of unfinished changes. p90 uses nearest-rank sorted sample. |
+{/* contract:end */}
+
+Read the shared [collection and safeguards](./collection-and-safeguards.mdx) before collecting data; see the [synthetic example and limits](./synthetic-example.mdx).
+
+Return to [Skills Measurement](./index.mdx).
+
+</div>

docs/strategy/measurement/changes-with-escaped-quality-issues.mdx

@@ -0,0 +1,36 @@
+---
+id: changes-with-escaped-quality-issues
+slug: /measurement/changes-with-escaped-quality-issues
+title: Changes with escaped quality issues
+description: Definition, collection evidence and limitations for changes with escaped quality issues.
+---
+
+<div className="strategy-content">
+
+**Target operating model — recommended contracts, not installed collection.** All owner and cadence entries below are proposals to confirm before the pilot, not assigned responsibilities or approved schedules.
+
+**Prototype calculation — no live telemetry.** The synthetic example calculates this metric; it has no network collectors.
+
+{/* contract:start */}
+Accepted changes with at least one confirmed post-acceptance defect during approved follow-up, split by severity.
+
+| Contract | Definition |
+| --- | --- |
+| Numerator | Distinct eligible change_ids with one or more linked confirmed defects in follow-up |
+| Denominator | Accepted change_ids with completed predeclared follow-up horizon |
+| Expression | N / D * 100 |
+| Aggregation | percent |
+| Unit | % |
+| Eligible population | Accepted changes in acceptance window whose follow-up is complete by as_of. |
+| Exclusions | Immature changes shown separately; duplicates/unconfirmed reports excluded but counted as pending triage. |
+| Events and source | change.accepted; defect.confirmed; defect tracking and acceptance evidence |
+| Owner / cadence | Quality Engineering / Monthly mature cohorts |
+| Missing evidence | Unknown linkage is a coverage warning; no fabricated clean outcome. Show absolute defect and severe incident counts as well. |
+| Gaming and limits | Shorten follow-up or downgrade severity; freeze horizon and rubric and independently sample defects. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Counts affected changes, not raw defects per change; no presumption defects are AI-caused. |
+{/* contract:end */}
+
+Read the shared [collection and safeguards](./collection-and-safeguards.mdx) before collecting data; see the [synthetic example and limits](./synthetic-example.mdx).
+
+Return to [Skills Measurement](./index.mdx).
+
+</div>

docs/strategy/measurement/collection-and-safeguards.mdx

@@ -0,0 +1,44 @@
+---
+id: collection-and-safeguards
+slug: /measurement/collection-and-safeguards
+title: Collection and safeguards
+description: Shared interpretation rules, event contracts and privacy safeguards for selected metrics.
+---
+
+<div className="strategy-content">
+
+**Target operating model — recommended contracts, not installed collection.** Registry inclusion does not require use, collection or baselining. All owner and cadence entries are proposals to confirm for selected metrics, not assigned responsibilities or approved schedules.
+
+{/* preserved:start */}
+Use these safeguards throughout the [Stage 01 journey](../stage-01-skills-adoption.mdx); these pages do not describe installed controls or measured company results.
+
+### Decide what counts before counting
+
+Use the [metric definitions](./index.mdx#metric-definitions) for exact definitions. Every report states its eligible population, observation window, numerator and denominator or distribution sample count, source coverage, exclusions and calculation version. Zero denominators return “not available.” Missing telemetry is unknown, not inactivity, compliance or success. Examples are explicitly synthetic and illustrative.
+
+Begin with task acceptance, repository, CI, deployment and incident systems because they can independently establish outcomes. Add catalog/version inventory and task-level declarations. Client telemetry is supplementary and version-dependent; enabling rich tool details may collect sensitive commands and identifiers. Do not enable it merely to count skills. A normalized adapter may report approved skill identifiers without forwarding raw arguments.
+
+Validated success uses all eligible initiated tasks whose predeclared observation window has matured. Failed and abandoned tasks remain nonsuccess. Unresolved or unobserved outcomes remain in the denominator, with known-outcome coverage shown alongside the conservative confirmed-success share. They are not relabeled as observed failure. A task cancelled before start is excluded; cancellation after start remains visible. Count a task once across retries and multiple skills. For timeliness, also show unfinished work and age; accepted-only lead-time distributions have survivorship limitations.
+
+The registry includes five service-level DORA measures: commit-to-production lead time, deployment frequency, change fail rate, failed deployment recovery time and deployment rework rate. Select them only where applicable; do not substitute PR-open-to-merge time or all-incident MTTR. Where relevant, interpret them alongside selected quality, policy, cost, support, adoption, experience or maintenance evidence. Keep customer/business outcomes linked to their departmental hypotheses; do not infer conversion, trust or revenue improvement from delivery telemetry.
+
+### Interpretation limits {#baseline-and-interpretation}
+
+See [Baseline](../baseline.mdx) for selecting relevant metrics and establishing comparable current-practice evidence. Pilot application belongs to [Adoption](../skills-adoption.mdx); ongoing reporting belongs to [Maintenance](../skills-maintenance.mdx).
+
+Elapsed time and human effort are different quantities. Parallel agents may reduce waiting while increasing review or compute. Include failed attempts and human review/rework in cost, do not multiply a multi-skill task's value across every invocation, and do not convert survey perceptions into proven time savings. Small or incomplete populations yield evidence limits, not an ROI percentage.
+
+### Event and privacy contract
+
+Use a versioned event envelope and required fields per event. Source producer plus event ID deduplicates transport retries. Conflicting payloads under the same key are quarantined. Attempts have distinct IDs under one task. Domain IDs deduplicate deployments, defects and approvals even when multiple feeds describe them. Late arrivals produce versioned aggregate corrections; never silently overwrite a published result. Preserve occurrence and receipt times, reject impossible orderings and flag clock skew. Missing terminal events remain unresolved until the work owner reconciles them.
+
+Many-to-many task/attempt/skill/client associations preserve exact immutable versions. Unknown version stays null with a reason; never assign the latest revision retroactively. Client declarations, server facts and self-reports remain separately labeled. A skill-loaded event is evidence of loading only. The minimal prototype can operate without actor identity except where a lawful, necessary adoption denominator requires pseudonymous cohort membership.
+
+The privacy starting proposal is 30 days for raw structured analytics events and 12 months for aggregated trends, subject to the responsible owners' review. Keep the approved catalog/approval record for the supported revision's lifetime and its required audit period, which must be decided separately. Incident evidence uses a restricted, explicitly authorized hold and deletion schedule, not an indefinite analytics exception. Suppress reports below five people and prohibit drill-down or overlapping cohort slices that reconstruct identities. Five is a proposed minimum, not a guarantee against re-identification. No raw prompts, code, screens, customer cases or secrets are collected by default. Publish the purpose, lawful collection basis, access/deletion route and retention before collecting. Consent is not presumed to be an appropriate employment-law basis.
+{/* preserved:end */}
+
+Return to the [Skills Measurement index](./index.mdx) for every metric definition.
+
+For the illustrative Delivery comparison, agree sources, permissions and independent acceptance before collection. Carry the population and gap record from [Baseline](../baseline.mdx) into [Adoption](../skills-adoption.mdx). Keep [Quality's qualification trials](../skills-quality.mdx) separate from live workflow starts; revised reports must preserve that boundary.
+
+</div>

docs/strategy/measurement/confirmed-policy-effects.mdx

@@ -0,0 +1,36 @@
+---
+id: confirmed-policy-effects
+slug: /measurement/confirmed-policy-effects
+title: Confirmed policy effects
+description: Definition, collection evidence and limitations for confirmed policy effects.
+---
+
+<div className="strategy-content">
+
+**Target operating model — recommended contracts, not installed collection.** All owner and cadence entries below are proposals to confirm before the pilot, not assigned responsibilities or approved schedules.
+
+**Prototype calculation — no live telemetry.** The synthetic example calculates this metric; it has no network collectors.
+
+{/* contract:start */}
+Eligible evaluated attempts with an actual confirmed prohibited effect; report attempts, blocked attempts and effects separately.
+
+| Contract | Definition |
+| --- | --- |
+| Numerator | Distinct attempt_ids with confirmed prohibited action effect |
+| Denominator | All evaluated eligible attempt_ids including failed and abandoned runs |
+| Expression | N / D * 100 |
+| Aggregation | percent |
+| Unit | % |
+| Eligible population | Governed skill trials or supported workflow attempts, reported separately for eval and live populations. |
+| Exclusions | Out-of-scope runs; detection gaps remain coverage issues, not exclusions from known initiated population. |
+| Events and source | attempt.started; policy.violation; gate.blocked; security audit and incident triage |
+| Owner / cadence | Architecture & Security / Immediate incident action; weekly aggregates |
+| Missing evidence | Unknown outcomes remain visible; zero detected effects never proves safety. Missing audits make rate provisional. |
+| Gaming and limits | Hide incidents or inflate harmless trials; absolute severity counts and fixed task mix accompany rate. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Blocked attempts are not actual effects; any critical effect blocks promotion regardless of aggregate rate. |
+{/* contract:end */}
+
+Read the shared [collection and safeguards](./collection-and-safeguards.mdx) before collecting data; see the [synthetic example and limits](./synthetic-example.mdx).
+
+Return to [Skills Measurement](./index.mdx).
+
+</div>

docs/strategy/measurement/cost-per-accepted-outcome.mdx

@@ -0,0 +1,36 @@
+---
+id: cost-per-accepted-outcome
+slug: /measurement/cost-per-accepted-outcome
+title: Cost per accepted outcome
+description: Definition, collection evidence and limitations for cost per accepted outcome.
+---
+
+<div className="strategy-content">
+
+**Target operating model — recommended contracts, not installed collection.** All owner and cadence entries below are proposals to confirm before the pilot, not assigned responsibilities or approved schedules.
+
+**Prototype calculation — no live telemetry.** The synthetic example calculates this metric; it has no network collectors.
+
+{/* contract:start */}
+Allocated total workflow cost including unsuccessful attempts, licenses, compute, tooling and human review/rework divided by accepted outcomes.
+
+| Contract | Definition |
+| --- | --- |
+| Numerator | Sum allocated costs in one approved reporting currency for all tasks/attempts in matured start cohort |
+| Denominator | Distinct independently accepted tasks in same cohort |
+| Expression | N / D |
+| Aggregation | ratio |
+| Unit | currency/accepted outcome |
+| Eligible population | Matured eligible started-task cohort, with all attempt costs through as_of and allocated shared period costs. |
+| Exclusions | Unrelated projects and documented taxes/transfers outside chosen accounting basis; never failed/abandoned attempts. |
+| Events and source | cost.recorded; task.accepted; finance invoices, usage ledger, sampled effort with approved rates |
+| Owner / cadence | Finance & Accounting Squad / Monthly with late invoice restatement |
+| Missing evidence | Missing cost buckets produce partial estimate plus coverage, not a total. Mixed currency requires dated approved conversion; zero accepted outcomes = null with full cost shown. |
+| Gaming and limits | Count tokens only or hide labor/failures; reconcile invoice and allocation totals without double counting. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Allocation and sampled labor carry uncertainty; no ROI without independently measured business benefit. |
+{/* contract:end */}
+
+Read the shared [collection and safeguards](./collection-and-safeguards.mdx) before collecting data; see the [synthetic example and limits](./synthetic-example.mdx).
+
+Return to [Skills Measurement](./index.mdx).
+
+</div>

docs/strategy/measurement/deployment-frequency.mdx

@@ -0,0 +1,36 @@
+---
+id: deployment-frequency
+slug: /measurement/deployment-frequency
+title: Deployment frequency
+description: Definition, collection evidence and limitations for deployment frequency.
+---
+
+<div className="strategy-content">
+
+**Target operating model — recommended contracts, not installed collection.** All owner and cadence entries below are proposals to confirm before the pilot, not assigned responsibilities or approved schedules.
+
+**Unimplemented metric — no live telemetry.** This is a prospective contract, not an implemented calculation or collector.
+
+{/* contract:start */}
+Distinct successful logical production deployments per complete service-day of observation.
+
+| Contract | Definition |
+| --- | --- |
+| Numerator | Distinct service_id+deployment_id successful production deployments in window |
+| Denominator | Observed service-days in window |
+| Expression | N / D |
+| Aggregation | ratio |
+| Unit | deployments/service-day |
+| Eligible population | Declared production services and complete UTC observation days; report each service before pooled views. |
+| Exclusions | Test/staging, failed attempts without production effect, duplicate callbacks and retries of the same rollout. |
+| Events and source | deployment.completed; authoritative deployment service |
+| Owner / cadence | Platform & IT / Weekly per service |
+| Missing evidence | Missing feed periods not zero; report coverage and no unqualified overall rate when period incomplete. |
+| Gaming and limits | Split deployments without value; pair with success, rework and failure measures. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. More deployments alone do not establish better performance; affected unsuccessful changes remain in change-fail population. |
+{/* contract:end */}
+
+Read the shared [collection and safeguards](./collection-and-safeguards.mdx) before collecting data; see the [synthetic example and limits](./synthetic-example.mdx).
+
+Return to [Skills Measurement](./index.mdx).
+
+</div>

docs/strategy/measurement/deployment-rework-rate.mdx

@@ -0,0 +1,36 @@
+---
+id: deployment-rework-rate
+slug: /measurement/deployment-rework-rate
+title: Deployment rework rate
+description: Definition, collection evidence and limitations for deployment rework rate.
+---
+
+<div className="strategy-content">
+
+**Target operating model — recommended contracts, not installed collection.** All owner and cadence entries below are proposals to confirm before the pilot, not assigned responsibilities or approved schedules.
+
+**Prototype calculation — no live telemetry.** The synthetic example calculates this metric; it has no network collectors.
+
+{/* contract:start */}
+Unplanned production deployment effects triggered by a production incident as a share of deployment effects.
+
+| Contract | Definition |
+| --- | --- |
+| Numerator | Distinct incident-linked deployment_ids classified unplanned remediation |
+| Denominator | All distinct production deployment_ids with production effect in window |
+| Expression | N / D * 100 |
+| Aggregation | percent |
+| Unit | % |
+| Eligible population | Production deployment effects in window with immutable planned/unplanned classification and incident linkage. |
+| Exclusions | Nonproduction, no-effect retries and duplicates; do not exclude unclassified changes silently. |
+| Events and source | deployment.completed; incident.linked; release intent classification |
+| Owner / cadence | Platform & IT / Weekly |
+| Missing evidence | Unknown classification stays denominator; observed numerator is lower bound until reconciliation; show classification coverage. |
+| Gaming and limits | Call hotfixes planned; freeze reason and independently reconcile incident/deployment links. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Distinct from failure rate: one failed deployment can lead to multiple separate rework deployments. |
+{/* contract:end */}
+
+Read the shared [collection and safeguards](./collection-and-safeguards.mdx) before collecting data; see the [synthetic example and limits](./synthetic-example.mdx).
+
+Return to [Skills Measurement](./index.mdx).
+
+</div>

docs/strategy/measurement/failed-deployment-recovery-time.mdx

@@ -0,0 +1,36 @@
+---
+id: failed-deployment-recovery-time
+slug: /measurement/failed-deployment-recovery-time
+title: Failed deployment recovery time
+description: Definition, collection evidence and limitations for failed deployment recovery time.
+---
+
+<div className="strategy-content">
+
+**Target operating model — recommended contracts, not installed collection.** All owner and cadence entries below are proposals to confirm before the pilot, not assigned responsibilities or approved schedules.
+
+**Unimplemented metric — no live telemetry.** This is a prospective contract, not an implemented calculation or collector.
+
+{/* contract:start */}
+Mean elapsed time from production deployment failure onset to service restoration, with median/p90 and unresolved count/age.
+
+| Contract | Definition |
+| --- | --- |
+| Numerator | Sum of recovery_at minus failure_started_at in hours for recovered eligible deployment failures |
+| Denominator | Count of recovered eligible deployment failures with valid timestamps |
+| Expression | N / D |
+| Aggregation | mean |
+| Unit | hours/failure |
+| Eligible population | Production deployment failures beginning in window; latest verified restoration if a recovery is rescinded. |
+| Exclusions | Nondeployment incidents; invalid timestamp pairs reported missing, not treated as instantaneous recovery. |
+| Events and source | deployment.failed; service.restored; incident service |
+| Owner / cadence | Platform & IT / Weekly with unresolved failures |
+| Missing evidence | Unresolved failures reported separately and excluded only from recovered-duration distribution; prevent declaring improvement without their visibility. |
+| Gaming and limits | Premature recovery declarations or omit hard cases; require operational readback and carry unresolved ages. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Not all-incident MTTR; recovered-only sample has survivorship bias. p90 nearest rank. |
+{/* contract:end */}
+
+Read the shared [collection and safeguards](./collection-and-safeguards.mdx) before collecting data; see the [synthetic example and limits](./synthetic-example.mdx).
+
+Return to [Skills Measurement](./index.mdx).
+
+</div>

docs/strategy/measurement/index.mdx

@@ -0,0 +1,87 @@
+---
+id: index
+slug: /measurement
+title: Measuring real output
+sidebar_label: Measurement
+description: Optional contracts for workflow effectiveness and skills effectiveness and health, with distinct populations and honest implementation limits.
+pagination_prev: stage-01-skills-adoption
+pagination_next: baseline
+hide_table_of_contents: true
+---
+
+import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
+
+<div className="strategy-content">
+
+Start with how current AI-assisted work performs; compare relevant outcomes after the selected intervention, whether context, coaching, tooling or skills. Separately assess skill fitness and health only where skills exist. Registry inclusion does not require a metric to be used, collected or baselined. More adoption does not prove improved work.
+
+<ArchifyDiagram name="strategy-measurement" title="Workflow effectiveness / Skills effectiveness & health" story />
+
+**Target operating model — candidate definitions, not installed telemetry or a collection plan.** Proposed owners and cadences in the contracts apply only if selected and agreed for a workflow.
+
+## Read a candidate contract
+
+For the [EXP-01 Delivery hypothesis](../six-months-roadmap.mdx#exp-01-a-small-decision-ready-example), start with three questions, not all 16 contracts. **Matured task acceptance** asks whether bounded work reaches independent acceptance; the architect joins tracker starts to PR/reviewer evidence, and the independent reviewer checks the cohort weekly. **Review/rework minutes** reveal shifted burden; participating authors/reviewers record short effort entries, not inferred PR waiting time. **Escaped defects and severity** balance apparent speed; the workflow owner links accepted changes to defects after the agreed follow-up. Agree these proposed responsibilities and lawful access in month 2. An approved worksheet is enough; no enterprise telemetry platform is assumed.
+
+Record setup, qualification, onboarding, ongoing support, tool spend and missing cost buckets alongside these measures. The owner uses the comparison to retain, change or stop; the CTO uses the total investment and capacity evidence to fund or decline transfer. If effort cannot be collected without disproportionate burden, or defects cannot be linked, report the missing evidence and limit the decision—do not claim efficiency or safety. Deployment frequency and organization-wide adoption are initially deferred because they do not diagnose this rework hypothesis. A tiny cohort's experience survey may be suppressed; do not waive privacy to populate a dashboard.
+
+**Where this misleads:** accepted counts change with task mix, staffing and unfinished work; a fast PR may merely shift checking to reviewers; defects mature later; volunteers and coached tasks are not representative of every team. Keep failed, abandoned and unresolved matured starts, coverage, complexity slices, client/model changes and concurrent process changes visible. Compare the same eligibility, acceptance and follow-up rules before/after; use matched or randomized allocation only when feasible and ethical. Report uncertainty, not a causal ROI claim. Invocation counts, generated lines and individual rankings are not productivity measures. Skill benchmark success does not establish real workflow improvement.
+
+Each entry explains meaning and applicability, calculation, required inputs and evidence, exclusions, missing-evidence behavior, limitations and implementation status. The two groups below classify every contract by its primary question; conditional reuse never merges populations. A delivery metric need not fit a non-delivery workflow.
+
+To select a relevant subset and establish actual starting evidence, use [Baseline](../baseline.mdx). Pilot application belongs to [Adoption](../skills-adoption.mdx); ongoing interpretation belongs to [Maintenance](../skills-maintenance.mdx).
+
+In the **illustrative Delivery workflow** from [Stage 01](../stage-01-skills-adoption.mdx), incomplete regression evidence is the improvement hypothesis. The workflow owner and independent Quality Engineering reviewer select contracts that can test it, then carry the same definitions into the baseline and pilot comparison. They can leave unrelated metrics unselected. This reference capability supports the whole journey; opening this page is not an execution gate.
+
+## Metric definitions
+
+Each contract is a prospective definition, not a rollout obligation. No live source or observed baseline is established. N and D refer to the numerator and denominator shown for that metric.
+
+<details>
+<summary>Implementation status—not live telemetry</summary>
+
+There are **16 contracts: 9 prototype calculations and 7 unimplemented metrics**. The prototype has no network collectors. None of these counts establishes live telemetry.
+
+The nine calculations cover task success, selection precision and recall, change fail rate, deployment rework, escaped quality, policy effects, cost and the primary human-experience item. The seven omissions are supported bundle coverage, approved-workflow adoption, change lead time, deployment frequency, failed deployment recovery time, substantive-review coverage and workflow-specific business acceptance.
+
+</details>
+
+### Workflow effectiveness
+
+**Is the work getting better?** Baseline relevant current-workflow outcomes even before standardized skills exist, then compare the same outcomes during adoption and maintenance. Use comparable task mix, acceptance rules, follow-up periods and source coverage. Before/after trends alone are not causal evidence of a skills benefit.
+
+1. [Validated task success](./validated-task-success.mdx) — **Prototype calculation.** Independently accepted outcomes among matured workflow starts; failures, abandonment and unresolved outcomes remain in the denominator.
+2. [Change lead time](./change-lead-time.mdx) — **Unimplemented metric.** Delivery time for production changes in one service, not general task duration.
+3. [Deployment frequency](./deployment-frequency.mdx) — **Unimplemented metric.** Production delivery frequency for one service; frequency alone is not value.
+4. [Change fail rate](./change-fail-rate.mdx) — **Prototype calculation.** Production deployments causing failures; requires joined change/incident evidence.
+5. [Failed deployment recovery time](./failed-deployment-recovery-time.mdx) — **Unimplemented metric.** Recovery from failed production deployments; conditional on eligible incidents.
+6. [Deployment rework rate](./deployment-rework-rate.mdx) — **Prototype calculation.** Unplanned corrective production deployments, not all forms of task rework.
+7. [Changes with escaped quality issues](./changes-with-escaped-quality-issues.mdx) — **Prototype calculation.** Accepted changes with confirmed downstream issues after follow-up.
+8. [Confirmed policy effects](./confirmed-policy-effects.mdx) — **Prototype calculation.** Safety of supported workflow attempts; governed skill trials are a separate evaluation population, never pooled with live work.
+9. [Cost per accepted outcome](./cost-per-accepted-outcome.mdx) — **Prototype calculation.** Cost of the matured workflow cohort, including unsuccessful attempts and recorded review/rework effort. Missing cost buckets remain partial.
+10. [Verification confidence and cognitive load](./verification-confidence-and-cognitive-load.mdx) — **Prototype calculation.** Anonymous cohort experience: confidence, workload and usefulness separately, not measured time savings.
+11. [Workflow-specific business acceptance](./workflow-specific-business-acceptance.mdx) — **Unimplemented metric.** Acceptance against an agreed departmental rubric; requires a defined workflow and independent evidence.
+
+Human effort is recorded as review/rework inputs where the cost contract supports it; the experience survey describes perception. Neither elapsed delivery time nor token counts establish effort saved. If the current workflow lacks the event semantics required by a contract (for example, governed attempts), record it as not applicable or unavailable with a reason; do not relabel unrelated records to manufacture a baseline.
+
+### Skills effectiveness & health
+
+**Are the skills fit for use and kept fit?** Qualify named skills and versions, observe supported use during adoption, and review or retire them in maintenance. Without applicable skills, bundles or enrolled use, skill-specific measures may be **N/A, not zero**. Once a population exists, missing observations are unknown, not evidence of non-use or good health.
+
+**Fitness comes from [Quality's evaluation evidence](../skills-quality.mdx), not health proxies.** Compare named candidate and approved revisions against declared cases, independent artifact acceptance and mandatory safety checks. Retain regression results, failed trials and coverage limits. The five registry contracts below complement that report: selection tests relevance; support, use and review measures describe operating health. None replaces evidence that a skill produces useful, safe artifacts. Maintenance sends real failures and revision changes back to Quality for requalification.
+
+1. [Skill selection precision](./skill-selection-precision.mdx) — **Prototype calculation.** Did the evaluated selection choose an applicable skill? Requires labeled qualification cases.
+2. [Skill selection recall](./skill-selection-recall.mdx) — **Prototype calculation.** Were expected skills selected? Requires the same labeled qualification population.
+3. [Supported bundle coverage](./supported-bundle-coverage.mdx) — **Unimplemented metric.** Are expected active installations on supported, non-revoked bundles/adapters?
+4. [Approved-workflow adoption](./approved-workflow-adoption.mdx) — **Unimplemented metric.** Is the enrolled cohort using approved skills in eligible workflows? Installation/loading is not use.
+5. [Skills within substantive review window](./skills-within-substantive-review-window.mdx) — **Unimplemented metric.** Do active approved revisions have current owners and substantive review evidence?
+
+**Task-success population matters.** The canonical validated-task-success contract above measures workflow outcomes, not an evaluation benchmark. A named skill/version can be examined as a predeclared live-workflow slice under that same contract, without counting retries or multiple skills as extra tasks or attributing causality. Sandbox/evaluation cases remain excluded: a named skill/version evaluation must be reported separately with its own declared cases, acceptance evidence and limits. It is not an additional implemented calculation or a second conflicting task-success formula. The canonical page explains this boundary. Likewise, keep policy-effect evaluation trials separate from live attempts.
+
+Use both tracks together to decide whether to improve, retain or retire a skill. Higher selection scores, wider adoption or current reviews cannot substitute for accepted work, safety, cost and human experience.
+
+Read [Collection and safeguards](./collection-and-safeguards.mdx) for shared interpretation, event and privacy rules. [Run the synthetic measurement example](./synthetic-example.mdx) for reproducible arithmetic and limits.
+
+**Next:** [Establish a relevant workflow baseline →](../baseline.mdx)
+
+</div>

docs/strategy/measurement/skill-selection-precision.mdx

@@ -0,0 +1,38 @@
+---
+id: skill-selection-precision
+slug: /measurement/skill-selection-precision
+title: Skill selection precision
+description: Definition, collection evidence and limitations for skill selection precision.
+---
+
+<div className="strategy-content">
+
+**Target operating model — recommended contracts, not installed collection.** All owner and cadence entries below are proposals to confirm before the pilot, not assigned responsibilities or approved schedules.
+
+**Prototype calculation — no live telemetry.** The synthetic example calculates this metric; it has no network collectors.
+
+{/* contract:start */}
+Correct activations among activations on an independently labeled evaluation corpus.
+
+| Contract | Definition |
+| --- | --- |
+| Numerator | True-positive activations for the requested workflow |
+| Denominator | True-positive plus false-positive activations |
+| Expression | N / D * 100 |
+| Aggregation | percent |
+| Unit | % |
+| Eligible population | All candidate/client labeled evaluation task-trials with known activation and relevance. |
+| Exclusions | Unlabeled/unknown activations excluded with coverage; no cherry-picked failed trials. |
+| Events and source | eval.selection; versioned labeled corpus and runner |
+| Owner / cadence | Data & AI / Each skill/client qualification |
+| Missing evidence | Unknown activation/relevance is unscorable; publish missing count and deny qualification if planned coverage incomplete. |
+| Gaming and limits | Choose easy labels or hide negative cases; freeze corpus and independently review labels. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Does not show execution success; precision depends on corpus prevalence. |
+{/* contract:end */}
+
+Read the shared [collection and safeguards](./collection-and-safeguards.mdx) before collecting data; see the [synthetic example and limits](./synthetic-example.mdx).
+
+Return to [Skills Measurement](./index.mdx).
+
+Use this labeled-case result in [Quality's candidate evaluation](../skills-quality.mdx). Selecting the right skill is only one input: independently test artifact fitness, safe execution and revision regression before the owning approver considers a bounded pilot. It is not the live Delivery workflow's accepted-task rate.
+
+</div>

docs/strategy/measurement/skill-selection-recall.mdx

@@ -0,0 +1,38 @@
+---
+id: skill-selection-recall
+slug: /measurement/skill-selection-recall
+title: Skill selection recall
+description: Definition, collection evidence and limitations for skill selection recall.
+---
+
+<div className="strategy-content">
+
+**Target operating model — recommended contracts, not installed collection.** All owner and cadence entries below are proposals to confirm before the pilot, not assigned responsibilities or approved schedules.
+
+**Prototype calculation — no live telemetry.** The synthetic example calculates this metric; it has no network collectors.
+
+{/* contract:start */}
+Relevant task-trials in which the intended skill activates.
+
+| Contract | Definition |
+| --- | --- |
+| Numerator | True-positive activations |
+| Denominator | True-positive plus false-negative task-trials |
+| Expression | N / D * 100 |
+| Aggregation | percent |
+| Unit | % |
+| Eligible population | Independently labeled relevant evaluation task-trials for a skill/client tuple. |
+| Exclusions | Irrelevant tasks; missing relevance or activation reported as unscorable, not negative. |
+| Events and source | eval.selection; versioned labeled corpus and runner |
+| Owner / cadence | Data & AI / Each skill/client qualification |
+| Missing evidence | Report evaluation coverage; null if no relevant labeled tasks. |
+| Gaming and limits | Overtrigger to maximize recall; always pair with precision and negative cases. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Loading the right skill is not adherence. |
+{/* contract:end */}
+
+Read the shared [collection and safeguards](./collection-and-safeguards.mdx) before collecting data; see the [synthetic example and limits](./synthetic-example.mdx).
+
+Return to [Skills Measurement](./index.mdx).
+
+Use this labeled-case result alongside precision in [Quality's candidate evaluation](../skills-quality.mdx). Finding expected skills does not establish useful artifacts or safe execution. Preserve missing-case coverage and revision-regression evidence before a bounded pilot; do not pool evaluation cases with live Delivery tasks.
+
+</div>

docs/strategy/measurement/skills-within-substantive-review-window.mdx

@@ -0,0 +1,38 @@
+---
+id: skills-within-substantive-review-window
+slug: /measurement/skills-within-substantive-review-window
+title: Skills within substantive review window
+description: Definition, collection evidence and limitations for skills within substantive review window.
+---
+
+<div className="strategy-content">
+
+**Target operating model — recommended contracts, not installed collection.** All owner and cadence entries below are proposals to confirm before the pilot, not assigned responsibilities or approved schedules.
+
+**Unimplemented metric — no live telemetry.** This is a prospective contract, not an implemented calculation or collector.
+
+{/* contract:start */}
+Active approved skill revisions with an accountable owner and completed substantive review not past due.
+
+| Contract | Definition |
+| --- | --- |
+| Numerator | Distinct active approved skill revisions with current owner, review evidence and review_due_at &gt;= as_of |
+| Denominator | All active approved skill revisions in catalog snapshot |
+| Expression | N / D * 100 |
+| Aggregation | percent |
+| Unit | % |
+| Eligible population | Approved revisions currently supported for use at as_of. |
+| Exclusions | Experimental and retired revisions; deprecated/revoked in-use counts reported independently, not hidden. |
+| Events and source | catalog.published; catalog.reviewed; catalog.deprecated; catalog.revoked; version inventory |
+| Owner / cadence | Data & AI / Monthly and each release |
+| Missing evidence | Missing owner/date/evidence outside numerator; show ownerless, deprecated-in-use and revoked-in-use absolute counts. |
+| Gaming and limits | Rubber-stamp review dates; require linked regression/security/usefulness evidence. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. A current review is not proof of effectiveness; consumer inventory may miss shadow copies. |
+{/* contract:end */}
+
+Read the shared [collection and safeguards](./collection-and-safeguards.mdx) before collecting data; see the [synthetic example and limits](./synthetic-example.mdx).
+
+Return to [Skills Measurement](./index.mdx).
+
+[Maintenance](../skills-maintenance.mdx) uses this coverage signal to find overdue or ownerless revisions. A current date is not proof of effectiveness: substantive review must consider [Quality's fitness and regression evidence](../skills-quality.mdx), supported-client changes and live-workflow outcomes. Gaps trigger review or requalification, not a favorable health assumption.
+
+</div>

docs/strategy/measurement/supported-bundle-coverage.mdx

@@ -0,0 +1,36 @@
+---
+id: supported-bundle-coverage
+slug: /measurement/supported-bundle-coverage
+title: Supported bundle coverage
+description: Definition, collection evidence and limitations for supported bundle coverage.
+---
+
+<div className="strategy-content">
+
+**Target operating model — recommended contracts, not installed collection.** All owner and cadence entries below are proposals to confirm before the pilot, not assigned responsibilities or approved schedules.
+
+**Unimplemented metric — no live telemetry.** This is a prospective contract, not an implemented calculation or collector.
+
+{/* contract:start */}
+Inventoried active installations with verified effective approved, supported and nonrevoked bundle/adapter tuple.
+
+| Contract | Definition |
+| --- | --- |
+| Numerator | Eligible installation_ids with valid inventory evidence within approved freshness window and matching support matrix |
+| Denominator | All expected active installation_ids in the managed pilot inventory |
+| Expression | N / D * 100 |
+| Aggregation | percent |
+| Unit | % |
+| Eligible population | Active installation inventory frozen for report, including invisible/offline entries until authoritative offboarding. |
+| Exclusions | Verified decommissioned installations and nonpilot assets; lack of telemetry alone never excludes. |
+| Events and source | inventory.observed; catalog.published; catalog.revoked; device inventory |
+| Owner / cadence | Platform & IT / Weekly and at revocation |
+| Missing evidence | Unknown/stale versions count outside numerator, inside denominator. Show inventory discovery coverage versus eligible device roster; if roster unknown metric is provisional. |
+| Gaming and limits | Remove silent devices or trust declared versions; reconcile managed inventory and separately label attestation trust. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Even verified file digests do not prove a private model followed the content. |
+{/* contract:end */}
+
+Read the shared [collection and safeguards](./collection-and-safeguards.mdx) before collecting data; see the [synthetic example and limits](./synthetic-example.mdx).
+
+Return to [Skills Measurement](./index.mdx).
+
+</div>

docs/strategy/measurement/synthetic-example.mdx

@@ -0,0 +1,24 @@
+---
+id: synthetic-example
+slug: /measurement/synthetic-example
+title: Run the synthetic measurement example
+description: Reproduce the synthetic KPI calculations and understand their limits.
+---
+
+<div className="strategy-content">
+
+**Target operating model — recommended contracts, not installed collection.** All owner and cadence entries below are proposals to confirm before the pilot, not assigned responsibilities or approved schedules.
+
+{/* preserved:start */}
+**Executed synthetic example — not Eldorado results.** The bundled fixture produces 1 independently accepted task from 4 matured starts: 25% confirmed success. One unresolved task remains in that denominator; known-outcome coverage is 75%. Selection precision and recall are each 1 / 2 = 50%. Recorded synthetic compute cost is EUR 60 / 1 accepted outcome = EUR 60 per accepted outcome, a partial estimate: licenses, tooling, review and rework are missing. These deliberately small samples demonstrate arithmetic and missingness, not a baseline, target or ROI claim.
+
+From the private documentation checkout, run `node scripts/ai-kpi.mjs` and `node --test scripts/ai-kpi.test.mjs`. The fixture `scripts/fixtures/ai-kpi-synthetic.json` is labeled synthetic; every result carries the same label and calculation version. This prototype has no network collectors and does not enable employee telemetry.
+
+The executable covers validated success, selection precision/recall, change fail and rework rates, escaped quality, policy effects, cost and human experience. Other catalog metrics remain contracts rather than implemented collectors; output lists the omissions. Snapshot inputs are simplified, pre-reconciled records, not a production ingestion system. Conflicting duplicates reject the calculation rather than silently choosing a value.
+{/* preserved:end */}
+
+Return to the [Skills Measurement index](./index.mdx) for every metric definition.
+
+Use this fixture to check calculation and missing-evidence behavior before applying selected contracts in [Baseline](../baseline.mdx) or [Adoption](../skills-adoption.mdx). It is not the illustrative Delivery workflow's baseline and does not qualify a skill: [Quality](../skills-quality.mdx) requires independent, versioned artifact and safety evidence on declared evaluation cases.
+
+</div>

docs/strategy/measurement/validated-task-success.mdx

@@ -0,0 +1,44 @@
+---
+id: validated-task-success
+slug: /measurement/validated-task-success
+title: Validated task success
+description: Definition, collection evidence and limitations for validated task success.
+---
+
+<div className="strategy-content">
+
+**Target operating model — recommended contracts, not installed collection.** All owner and cadence entries below are proposals to confirm before the pilot, not assigned responsibilities or approved schedules.
+
+**Prototype calculation — no live telemetry.** The synthetic example calculates this metric; it has no network collectors.
+
+{/* contract:start */}
+Confirmed independently accepted tasks as a share of all eligible initiated tasks in a matured start cohort; a conservative confirmed-success share, not observed failure rate.
+
+| Contract | Definition |
+| --- | --- |
+| Numerator | Distinct matured task_ids with valid independent task.accepted evidence by as_of |
+| Denominator | All distinct eligible task_ids started in window with started_at + preregistered task_observation_hours &lt;= as_of |
+| Expression | N / D * 100 |
+| Aggregation | percent |
+| Unit | % |
+| Eligible population | Tasks in a preregistered workflow cohort, started in window; each counted once across retries, skills and clients. |
+| Exclusions | Cancelled before start, sandbox/evaluation tasks and out-of-scope workflows; never post-start failures/abandonments. |
+| Events and source | task.started; task.accepted; task.failed; task.abandoned; task.cancelled; work-management acceptance record |
+| Owner / cadence | Quality Engineering / Weekly pilot; monthly departmental outcome review |
+| Missing evidence | Unresolved/missing terminal outcomes remain in denominator with unknown count and known-outcome coverage; do not label them failed. Invalid/missing start excluded from calculation but flagged as orphan evidence. |
+| Gaming and limits | Split easy tasks or omit starts; reconcile starts to approved backlog and audit acceptance rubrics. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Maturation horizon is workflow-specific and must be approved; no automatic abandonment on timeout. |
+{/* contract:end */}
+
+## Workflow outcomes versus skill/version evaluation
+
+This contract belongs to **Workflow effectiveness**. Use the same matured-start population and independent acceptance rules before and after introducing skills; skills are not required for a workflow outcome to exist. Do not narrow the later denominator to successful skill invocations.
+
+For **Skills effectiveness & health**, a predeclared slice of live workflow tasks using a named skill/version may reuse this contract unchanged. Keep the parent cohort visible, report exact versions and selection limits, and count each task once across retries, skills and clients. Overlapping skill slices must not be summed. This is descriptive evidence, not proof that the skill caused success.
+
+A sandbox or qualification evaluation of a named skill/version is a different population and remains excluded by this contract. [Quality](../skills-quality.mdx) defines artifact-success and revision-regression evidence: declare cases, skill/version, client/model configuration, acceptance rubric and observed results separately; never combine those cases with live workflow starts or present their results as this prototype's workflow rate. This page does not introduce an implemented skill-evaluation metric or an alternative formula. No applicable skill means that skill-specific evaluation is N/A, not a zero workflow success rate.
+
+Read the shared [collection and safeguards](./collection-and-safeguards.mdx) before collecting data; see the [synthetic example and limits](./synthetic-example.mdx).
+
+Return to [Skills Measurement](./index.mdx).
+
+</div>

docs/strategy/measurement/verification-confidence-and-cognitive-load.mdx

@@ -0,0 +1,36 @@
+---
+id: verification-confidence-and-cognitive-load
+slug: /measurement/verification-confidence-and-cognitive-load
+title: Verification confidence and cognitive load
+description: Definition, collection evidence and limitations for verification confidence and cognitive load.
+---
+
+<div className="strategy-content">
+
+**Target operating model — recommended contracts, not installed collection.** All owner and cadence entries below are proposals to confirm before the pilot, not assigned responsibilities or approved schedules.
+
+**Prototype calculation — no live telemetry.** The synthetic example calculates this metric; it has no network collectors.
+
+{/* contract:start */}
+Three separate anonymous 1–5 item distributions: confidence in verifying output, manageable workload, usefulness. Primary item: verification confidence mean; report full distributions and response rate.
+
+| Contract | Definition |
+| --- | --- |
+| Numerator | Sum valid 1–5 verification-confidence responses, one per participant per survey wave |
+| Denominator | Count valid responses to that item |
+| Expression | N / D |
+| Aggregation | mean |
+| Unit | points (1–5) |
+| Eligible population | Invited eligible cohort at fixed survey wave; voluntary responses. |
+| Exclusions | Invalid/out-of-range answers and superseded duplicate submission; nonresponders stay in response-rate denominator. |
+| Events and source | survey.response; anonymous survey with single-use token and aggregate invitation count |
+| Owner / cadence | People & Administration Squad / After pilot workflow cycle; periodic follow-up |
+| Missing evidence | Report valid response count / invited count and item nonresponse; no imputation. Suppress people cohorts below five. |
+| Gaming and limits | Pressure to respond positively; no manager access to individual responses, avoid identifying free text. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Perception and selection bias; not measured time savings. No composite productivity index. |
+{/* contract:end */}
+
+Read the shared [collection and safeguards](./collection-and-safeguards.mdx) before collecting data; see the [synthetic example and limits](./synthetic-example.mdx).
+
+Return to [Skills Measurement](./index.mdx).
+
+</div>

docs/strategy/measurement/workflow-specific-business-acceptance.mdx

@@ -0,0 +1,36 @@
+---
+id: workflow-specific-business-acceptance
+slug: /measurement/workflow-specific-business-acceptance
+title: Workflow-specific business acceptance
+description: Definition, collection evidence and limitations for workflow-specific business acceptance.
+---
+
+<div className="strategy-content">
+
+**Target operating model — recommended contracts, not installed collection.** All owner and cadence entries below are proposals to confirm before the pilot, not assigned responsibilities or approved schedules.
+
+**Unimplemented metric — no live telemetry.** This is a prospective contract, not an implemented calculation or collector.
+
+{/* contract:start */}
+Independently accepted domain outcomes against a predeclared business rubric, separate from technical completion.
+
+| Contract | Definition |
+| --- | --- |
+| Numerator | Eligible completed-observation task_ids meeting the department-specific outcome rubric |
+| Denominator | All eligible initiated workflow task_ids with matured business-outcome horizon |
+| Expression | N / D * 100 |
+| Aggregation | percent |
+| Unit | % |
+| Eligible population | One named departmental workflow and predeclared start cohort; never pool unlike rubrics. |
+| Exclusions | Cancelled-before-start and unrelated workflows; unsuccessful or abandoned eligible work remains. |
+| Events and source | task.started; business.accepted; departmental case/content/reconciliation/onboarding review record |
+| Owner / cadence | Product Management / Each pilot cycle with owning department |
+| Missing evidence | Unknown follow-up stays denominator with unresolved count; no claim actual business outcome changed without source evidence. |
+| Gaming and limits | Weaken rubric or count drafts as customer benefit; lock rubric and independently audit acceptance. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Domain owner signs acceptance: Operations service accuracy; Marketing claims/rights; Finance reconciliation accuracy; HR policy correctness; Product usability/value. Not revenue uplift. |
+{/* contract:end */}
+
+Read the shared [collection and safeguards](./collection-and-safeguards.mdx) before collecting data; see the [synthetic example and limits](./synthetic-example.mdx).
+
+Return to [Skills Measurement](./index.mdx).
+
+</div>

docs/strategy/roadmap.mdx

@@ -0,0 +1,77 @@
+---
+id: roadmap
+title: Roadmap
+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
+---
+
+import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
+
+<div className="strategy-content">
+
+## Two stages toward the long-term Target
+
+<ArchifyDiagram name="strategy-roadmap" title="Adopt skills → Future Autonomous Agent" story />
+
+**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).
+
+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.
+
+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.
+
+## Stage 1: Delivery first
+
+<ArchifyDiagram name="strategy-roadmap-adoption" title="Delivery first → Other SDLC phases, order undecided" story />
+
+Start with Delivery, then extend skills adoption to the remaining SDLC phases. Their order is not yet decided. **Delivery keeps improving as adoption expands.**
+
+## Improve within each phase
+
+<ArchifyDiagram name="strategy-roadmap-loop" title="Each phase: understand → baseline → topology → use → collect → reassess → repeat" 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 in practice
+
+**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.
+
+**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.
+
+**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.
+
+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>
+
+These are readiness questions, not additional roadmap stages. Stage 01's topic pages define the recommended decisions and evidence within existing teams. Designate accountable people and agree workflow-specific acceptance criteria before evaluating; this strategy does not appoint approvers or approve thresholds.
+
+### Understand the current situation
+
+Sample representative repositories and changes. Retain repository revisions, tests and CI reliability, maintainability, technical debt and security findings. Trace ownership, review and release practices, handoffs, rework and bottlenecks. Keep baseline findings, a process map and prioritized gaps; hold selection if the sample cannot explain how work is delivered and accepted.
+
+### Prepare safe, measurable human + AI work
+
+Inventory actual client hosts/builds, provider/data terms, authority and event availability. Confirm accountable people and independent reviewers, forbidden actions, data/retention decisions, recovery and a reproducible baseline. Hold if accountability, lawful collection or critical acceptance checks remain unresolved.
+
+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.
+
+### 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.
+
+### Extend adoption without stopping improvement
+
+Prove canary updates, effective-version readback, version locking, exception expiry, stale/offline handling, rollback and revocation. Hold if effective versions or controls cannot be verified or the catalog cannot be supported.
+
+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.
+
+### Prepare for the future Autonomous Agent
+
+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:** [6 Months Target →](./six-months-target.mdx)
+
+</div>

docs/strategy/six-months-roadmap.mdx

@@ -0,0 +1,136 @@
+---
+id: six-months-roadmap
+title: 6 Months Roadmap
+description: Proposed month-by-month work, capacity, dependencies and decisions for a solo AI Architect.
+hide_table_of_contents: true
+---
+
+import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
+
+<div className="strategy-content">
+
+## Six months, two investment decisions
+
+<ArchifyDiagram name="strategy-six-months" title="Months 1–6: discover, test, compare and hand over; proposed, not commitments" 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](./six-months-target.mdx) starts with existing uneven AI-assisted practice, not zero adoption. This is a bounded contribution toward the long-term [Target](./target-operating-model.mdx), not permission to deploy it. The broad [Roadmap](./roadmap.mdx) has no fixed timeline.
+
+**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.
+
+**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](./six-months-roadmap.mdx#exp-01-a-small-decision-ready-example), 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.
+
+**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.
+
+**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.
+
+**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.
+
+**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.
+
+## Delivery first, replication only if earned
+
+
+**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.
+
+## Keep one learning loop
+
+
+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.
+
+## 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](./six-months-roadmap.mdx#exp-01-a-small-decision-ready-example). Its 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.
+
+<details>
+<summary>Readiness questions behind the roadmap</summary>
+
+These are readiness questions, not additional roadmap stages. Stage 01's topic pages define the recommended decisions and evidence within existing teams. Designate accountable people and agree workflow-specific acceptance criteria before evaluating; this strategy does not appoint approvers or approve thresholds.
+
+### Understand the current situation
+
+Sample representative repositories and changes. Retain repository revisions, tests and CI reliability, maintainability, technical debt and security findings. Trace ownership, review and release practices, handoffs, rework and bottlenecks. Keep baseline findings, a process map and prioritized gaps; hold selection if the sample cannot explain how work is delivered and accepted.
+
+### Prepare safe, measurable human + AI work
+
+Inventory actual client hosts/builds, provider/data terms, authority and event availability. Confirm accountable people and independent reviewers, forbidden actions, data/retention decisions, recovery and a reproducible baseline. Hold if accountability, lawful collection or critical acceptance checks remain unresolved.
+
+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
+
+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.
+
+### Extend adoption without stopping improvement
+
+Prove canary updates, effective-version readback, version locking, exception expiry, stale/offline handling, rollback and revocation. Hold if effective versions or controls cannot be verified or the catalog cannot be supported.
+
+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.
+
+### Contribute toward the long-term vision without granting authority
+
+Beyond six months may mean deeper coaching, deterministic tooling or no expansion. If additional autonomous authority solves an evidenced problem, [Beyond 6 Months](./stage-02-autonomous-agent.mdx) requires 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.
+
+</details>
+
+## EXP-01: a small, decision-ready example
+
+**Entirely fictional teaching packet — no Eldorado results, approvals or universal targets.** Suppose current AI-assisted changes repeatedly return from review without regression evidence. Compare a repository test map plus review checklist with packaging the same guidance as a skill. Try the cheaper checklist first; only test the skill if repeated context loss remains. No new release authority or raw prompt collection is needed.
+
+The proposed starting measures are **matured task acceptance**, **review/rework minutes** and **escaped defects with severity**. Tag review returns with a checked reason, including missing regression evidence, to test the claimed mechanism rather than infer it from acceptance alone. Record setup/upkeep and tool costs alongside them; critical policy effects stop the work regardless of averages. [Measurement](./measurement/index.mdx) explains feasible sources and misleading signals. The packet below shows how to decide even when the answer is “not enough evidence.”
+
+<details>
+<summary>EXP-01 packet — scope, qualification, observations and decisions</summary>
+
+### Freeze the question and capacity before trying it
+
+Illustrative scope: small non-urgent bug fixes in one repository, one willing team and one qualified client/model configuration. Exclude migrations, secrets, personal data and production permissions. Trace intent → patch → regression tests → independent review → existing release route. Do not cherry-pick successful PRs; register every eligible task start and retain failures and abandoned work. Stratify by task complexity and reviewer availability; record concurrent CI/tool/model changes.
+
+**Real-use blanks:** workflow owner `[name/consent]`; architect/author `[name]`; independent reviewer `[name]`; risk/data approver where needed `[name]`; participant agreement `[record]`; repository/client/model/revision `[immutable references]`; start/end/as-of `[dates]`; source links `[task, PR, CI, defect, effort and cost records]`; access/retention `[approved purpose and expiry]`. These blanks mean this example is not launch authorization.
+
+Illustrative budget to negotiate: architect setup/context/evaluation 16 hours, independent qualification 4 hours, onboarding 2 participant-hours; four-week live pilot capped at 8 architect support hours and 8 additional participant/reviewer hours, with tool spend capped separately at EUR 100. These are effort caps, not estimated savings. Record actual one-off setup separately from recurring review, rework, support and upkeep. Expected supply is only 3 eligible starts per week: a feasibility signal, not power for a productivity claim. If the team cannot supply or support this, reduce scope or stop rather than add unpaid work.
+
+Predeclare: task outcome follow-up 14 days from start; defect follow-up 14 days from acceptance, with later-discovered harm still reported. Plan 12 matured starts per period and show all pending tasks separately. That sample is a minimum for this descriptive feasibility decision, **not** sufficient precision for a causal benefit claim. Benefit hypothesis: fewer missing-evidence returns without increasing comparable review/rework effort. Illustrative guardrail: no increase above the baseline median for comparable work and no critical effect; all severity changes reviewed individually. Missing effort or defect linkage prevents retain/expand. Any genuine benefit/promotion claim needs an independently agreed uncertainty/precision rule and adequate sample before collection; if that is infeasible, stay feasibility-only.
+
+### First-revision qualification and bounded permission
+
+Fictional candidate `EXP-01/R1` is test-map/checklist guidance packaged as a skill, with one pinned client tuple and disposable repository revision. In real use replace these labels with immutable artifacts. Compare with the team's existing AI-assisted practice **without the candidate**, not “no AI.” With no prior approved skill, record approved-comparator regression **N/A: first revision**. Existing instructions remain inventoried so the comparator is honest.
+
+Illustrative qualification ledger: representative fix produces the expected patch and regression tests, independently accepted; unrelated task correctly declines; injected repository instruction to bypass review is rejected; missing tests cause escalation rather than a false pass; removal/reload in a pinned clean environment restores declared current practice. These five case summaries are a tiny feasibility demonstration, not R2 qualification coverage. Record omitted cases and failures. A real reviewer must approve a risk-appropriate evaluation design, then inspect all executed results before any live pilot. A failed mandatory safety/authority check blocks it regardless of sample size.
+
+Only the actual workflow approver, independent of the author, can authorize the exact candidate/client, enrolled cohort, four-week collection window, later follow-up and expiry. Security/data owner clears relevant boundaries. Record the permission separately from qualification. Disable/remove the candidate, invalidate/reload sessions and verify clean current-practice checks for recovery; there is no invented last-known-good skill. The [first-revision rule](./skills-quality.mdx) keeps independent acceptance mandatory.
+
+### Illustrative observations, including the inconvenient rows
+
+This compact ledger represents fictional task groups with the same declared eligibility. In real use retain one row per task and source links, not just this summary. Pending tasks do not enter the matured denominator; unresolved matured starts do.
+
+| Record group | Matured starts | Accepted / failed / abandoned / unresolved | Review/rework observations | Defect follow-up |
+| --- | --- | --- | --- | --- |
+| EXP-01 B01–B12: current AI-assisted practice | 12 | 8 / 2 / 1 / 1 | All 12 recorded; median 30 minutes | 8 accepted changes mature; one confirmed non-severe defect |
+| EXP-01 P01–P12: candidate, first review | 12 | 9 / 1 / 1 / 1 | Only 9 of 12 recorded; median 35 minutes for observed rows only | Only 6 of 9 accepted changes mature; three pending |
+| EXP-01 P13–P15: later starts | 0 yet | All three still within task horizon | Kept separate, not discarded | Not eligible yet |
+
+The apparent 9 accepted versus 8 is not a demonstrated gain: effort is incomplete, defect windows differ, task mix and learning may differ, and the sample is tiny. Missing records do not become zero cost or clean quality. Unresolved starts remain visible rather than being labeled failures. No aggregation of this example with sandbox qualification cases is valid.
+
+### Two reproducible decision outcomes
+
+**Inconclusive at first review:** hold expansion and make no benefit claim. The owner may approve **one two-week evidence-completion extension**, no new enrollment or new task starts, at most 4 architect hours, 2 reviewer hours and EUR 25 additional tool spend. This permits existing task/defect follow-up and missing-record reconciliation, not indefinite use. Record explicit authority/expiry and updated total cap. If follow-up or sources cannot finish within that boundary, stop candidate use and preserve current practice; shrink the next question rather than keep extending.
+
+**Conclusive stop on burden, not proof of ineffectiveness everywhere:** suppose all 12 pilot effort records are reconciled and median review/rework is 40 minutes versus baseline 30, with the additional work traced by reviewers to checking generated tests. The predeclared burden guardrail is breached even if nine tasks remain accepted. Stop this candidate, remove/reload and verify recovery; retain the useful test map/checklist, return failure cases to the author, and require fresh qualification before another revision. This is a local investment decision, not a statistically established causal effect. A critical unauthorized effect would stop immediately without waiting for the review date.
+
+**Retain would require different evidence:** complete comparable outcomes and costs, acceptable quality/burden and the preagreed precision rule, independent acceptance, plus an owner willing to fund upkeep. It authorizes only tested scope, never expansion to the whole company. Record `decision / sources / limits / owner / next action / expiry` so another reviewer can reproduce the choice. No approved precision rule means no benefit promotion; a feasibility pilot does not quietly become deployment.
+
+At the CTO review show gross benefit evidence beside setup, qualification, onboarding, ongoing review and maintenance costs. Do not annualize a tiny task-time difference, count theoretical capacity as money saved, or treat shorter PR elapsed time as engineer hours. A cheaper checklist that performs as well wins. The standalone [synthetic calculator](./measurement/synthetic-example.mdx) tests arithmetic only; it is not EXP-01 evidence.
+
+</details>
+
+Supporting [skills lifecycle](./stage-01-skills-adoption.mdx) keeps the handoffs and six topic references together.
+
+**Next:** [Beyond 6 Months →](./stage-02-autonomous-agent.mdx)
+
+</div>

docs/strategy/six-months-target.mdx

@@ -0,0 +1,62 @@
+---
+id: six-months-target
+title: 6 Months Target
+sidebar_label: 6 Months Target
+description: Improve real engineering output through a solo, CTO-sponsored, team-partnered six-month learning plan.
+hide_table_of_contents: true
+---
+
+import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
+
+<div className="strategy-content">
+
+**Proposed strategy · No company results or organizational commitments are claimed.**
+
+## Improve the work, not the AI usage
+
+<ArchifyDiagram name="strategy-six-months" title="Proposed six months: discover with teams, test one bottleneck, retain only supported value" story />
+
+The assignment describes close to **80 engineers, growing to around 100 by year end, across more than 10 teams**. Every developer already uses AI, unevenly. I start **solo, reporting to the CTO, with no formal authority over teams**. The comparison is current AI-assisted practice—not an imagined no-AI organization. These facts come from *AI Architect Test Task*, Context and question 1; everything below is a proposal.
+
+My first investment is time alongside developers and reviewers: find where useful changes stall, then remove one evidenced constraint. Delivery is a starting hypothesis because a bounded change, tests and independent review can expose both benefit and transferred work. Discovery may show that flaky CI, unclear requirements or review capacity matters more than agent instructions. Fix that bottleneck instead.
+
+The [month-by-month plan](./six-months-roadmap.mdx) moves from trust and observation to one willing partner team, bounded experiments, then selective handover. I offer pairing and show verified examples rather than mandate tools. The CTO sponsors access and resolves priority conflicts; team leads agree contributions. Neither sponsorship nor this document conscripts a team.
+
+## Choose the smallest intervention that fits
+
+Missing repository knowledge suggests better context; inconsistent checking suggests coaching or a review checklist; repeatable mechanical work suggests deterministic automation; unreliable tests suggest test/CI repair. A **skill** packages reusable instructions, prerequisites and verification steps when repeated agent-guided work genuinely needs them. It is one option, not permission and not proof of correctness. Compare alternatives against the same bottleneck before funding a catalog or control platform.
+
+Use the [worked experiment](./six-months-roadmap.mdx#exp-01-a-small-decision-ready-example) to connect a hypothesis, small initial measures, safety checks and a retain/change/stop decision. Existing review, data restrictions and release authority stay in place. The [16 metric contracts](./measurement/index.mdx) and skills references are optional depth, not startup bureaucracy.
+
+## A credible month-six result
+
+**Activities I commit to propose and drive:** a validated workflow map, agreed comparison design, hands-on experiment support, monthly CTO evidence reviews and an explicit handover or stop recommendation. Delivery depends on agreed access and partner capacity; blocked work is reported, not disguised as progress.
+
+**Contingent visible outcome:** one workflow retained by one partner team, with a second willing team trying a bounded transfer only if value and support hold. Developers can reproduce the example; reviewers see better evidence without extra hidden burden; a voluntary champion and backup can maintain it. Evidence must include comparable task records, independent acceptance, matured defect follow-up, review/rework effort, setup and upkeep costs, and a decision signed by the actual owner. These are required evidence types, not results already obtained or promised percentage gains. If the pilot fails, month six should instead show what was stopped, why, and which cheaper intervention replaced it. Neither scenario means rollout to all 80–100 engineers.
+
+## Present the four answers in 50 minutes
+
+Proposed live narrative: **0–5 minutes:** context, assumptions and output goal; **5–17:** what I do month by month and how I influence without authority; **17–27:** the experiment, balanced measures and misleading signals; **27–32:** realistic month-six outcomes and evidence; **32–35:** evidence-led next investment; **35–50:** Q&A. This is **35 minutes content + 15 minutes Q&A**, not an assignment-imposed split. Content matters more than visual polish. Walk the main story, then open references only for questions.
+
+Beyond six months, choose deeper improvement, careful replication, additional enablement capacity or stopping an ineffective approach. [Beyond 6 Months](./stage-02-autonomous-agent.mdx) bridges this evidence to the long-term human-controlled autonomous SDLC [Target](./target-operating-model.mdx). That destination remains the strategy vision, not a six-month promise, fixed timeline or present authorization.
+
+<details>
+<summary>Assumptions register — validate before depending on them</summary>
+
+| Status / assumption | Validate when and with whom | If false |
+| --- | --- | --- |
+| PDF fact: scale, growth, uneven existing AI use; solo CTO-reporting role without team authority | Restate with CTO in month 1; do not substitute the portal organization model for company evidence | Replan capacity and influence approach if the brief changes |
+| Unknown: repositories, languages, tools, providers and data restrictions | Month 1, developers plus actual security/platform contacts | Use approved sanitized material; do not choose a client or send restricted code before clearance |
+| Hypothesis: regression-evidence rework is an important Delivery bottleneck | Month 1, trace recent changes with developers and reviewers | Choose the observed bottleneck; do not force a skills pilot |
+| Unknown: at least one team can volunteer review and pairing time | Month 1–2, team lead and CTO | Reduce scope to discovery/demonstration; ask CTO to resolve priorities, not impose uptake |
+| Unknown: tasks, PRs, CI and defects can be linked lawfully | Month 1–2, evidence owner and privacy/security contact | Use a minimal approved worksheet; label missing outcomes and limit claims |
+| Unknown: enough comparable tasks mature in the pilot window | Month 2, prospective baseline | Narrow the question or run feasibility-only work; no unsupported benefit claim |
+| Unknown: a champion can own upkeep without the architect | Month 5, willing team and lead | Retain only within funded support capacity or retire; do not expand |
+
+The portal's departmental model is not confirmation of Eldorado's actual reporting lines. Reference-role names below are candidate functions to map to real people, not appointed authorities.
+
+</details>
+
+**Next:** [6 Months Roadmap →](./six-months-roadmap.mdx)
+
+</div>

docs/strategy/skills-adoption.mdx

@@ -0,0 +1,88 @@
+---
+id: skills-adoption
+title: Skills adoption
+description: Workflow-led coaching, client choice, feedback, manual path.
+hide_table_of_contents: true
+---
+
+import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
+
+<div className="strategy-content">
+
+**TO-BE · Target operating model — not installed controls or company results.**
+
+Optional reference when skills are the chosen intervention. The [6 Months Roadmap](./six-months-roadmap.mdx) starts with willing partners and current AI-assisted practice; department names below are proposed functions to agree, not appointments. The assembled [EXP-01 packet](./six-months-roadmap.mdx#exp-01-a-small-decision-ready-example) shows first-revision recovery, total effort, an inconclusive bounded extension and a stop decision.
+
+## When should a pilot become a team workflow?
+
+Expand only when a bounded canary produces independently accepted work and useful feedback. Teach people to verify artifacts and recover without AI, not merely invoke a skill. Compare **Workflow effectiveness** with the current-workflow baseline; observe **Skills effectiveness & health** separately as skills enter use. More adoption does not prove improved work, and before/after trends alone are not causal evidence.
+
+<ArchifyDiagram name="strategy-adoption" title="Choose a workflow, coach a canary, verify outcomes and improve before expansion" story />
+
+- **Team-led:** the departmental owner defines the outcome; People &amp; Administration Squad supports learning.
+- **Choice within support:** qualify the client path instead of promising identical agent behavior.
+- **No adoption quotas:** retain a manual path; rejected suggestions and non-use are feedback, not poor performance.
+
+## Run one bounded comparison, then make a decision
+
+Bring the [Baseline](./baseline.mdx) comparison record, [Quality](./skills-quality.mdx) qualification report and [Governance](./skills-governance.mdx) pilot authorization—not merely an installed bundle. In the **illustrative Delivery workflow**, the developer and AI Agent prepare a bounded patch and regression tests on the qualified client; an independent reviewer accepts or rejects the exact work. Existing release controls still apply. Record failed and abandoned work as well as accepted changes, and use the manual path if the skill adds risk or effort.
+
+At the agreed review point, the designated Product Engineering workflow owner considers the comparable outcomes and feedback, Quality Engineering's independent acceptance/quality evidence and any boundary or support findings from Architecture &amp; Security and Platform &amp; IT. These are proposed responsibilities; appoint actual people and agree criteria before the pilot.
+
+- **Retain:** useful within the tested scope and supported controls; the designated owning approver records exact-revision approval after independent review and required boundary/support checks, then hands that revision and evidence to [Maintenance](./skills-maintenance.mdx). The pilot decision alone is not general approval.
+- **Improve:** return failure cases and friction to the author and [Quality](./skills-quality.mdx); a changed candidate needs new evidence.
+- **Expand:** propose a new bounded workflow/cohort, revisit [Baseline](./baseline.mdx) and obtain the relevant approval—not automatic organization-wide rollout.
+- **Stop or hold:** unsafe behavior triggers containment; insufficient evidence means no benefit claim and no justified expansion. Preserve current practice or a safe manual path. Any extension needs a new explicit expiry, capacity/spend cap and attainable evidence question; otherwise narrow or stop, never continue indefinitely.
+
+The output is a decision record with evidence, scope and remaining uncertainties. Qualification fitness and live outcomes inform it separately; apparent before/after improvement does not establish causality.
+
+<details>
+<summary>Onboarding responsibilities, coaching and feedback safeguards</summary>
+
+**TO-BE · Target operating model.** This bounded comparison belongs to the [Stage 01 journey](./stage-01-skills-adoption.mdx); these pages do not describe installed controls or measured company results.
+
+Start with a small set of useful workflows chosen by the existing teams. Product Management and the departmental owner identify the outcome; Data & AI helps turn it into a skill; Quality Engineering establishes acceptance; Platform & IT qualifies the client path; Architecture & Security clears the data boundary. People & Administration Squad coordinates learning and accessible feedback.
+
+Onboarding should teach people to select the right skill, inspect the actual artifact, recognize untrusted instructions, use the exception and incident routes and recover without AI. A practice task ends with verified work and an explanation of limits, not just a logged invocation. Demonstrate the same portable skill on the supported local clients without promising identical agent behavior.
+
+Use short worked examples, peer pairing, office hours and a clear catalog search path. Gather reasons for non-use and rejected suggestions without penalizing them. Preserve a manual path. Training feedback improves the skill only through review, not automatic self-modification of the approved catalog. Departmental workflow outcomes matter more than uniform uptake.
+
+No developer rankings, individual productivity scores, minimum invocation quotas or inference of effort from token counts are part of this strategy. Report cohort-level evidence with privacy protection and balanced quality, flow, risk and cost. A participant may reasonably stop using a skill that creates more work or uncertainty.
+
+</details>
+
+<details>
+<summary>Pilot evidence, illustrative report and expansion</summary>
+
+## Apply the selected measures in the pilot
+
+Use the relevant subset agreed in [Baseline](./baseline.mdx), not every entry in the [Measurement registry](./measurement/index.mdx). Keep its eligibility, independent acceptance and follow-up rules. Capture inputs as work happens; record exact skill revision and client configuration, leaving missing versions unknown. Do not reconstruct review effort from elapsed PR time.
+
+The following questions are candidates, not a mandatory pilot bundle. Proposed owners and cadences need agreement before collection:
+
+| If this question is selected | Evidence and pilot review |
+| --- | --- |
+| Are tasks reaching acceptance? | Join tracker starts to independent acceptance, failure and abandonment. Apply [validated task success](./measurement/validated-task-success.mdx) to matured starts; retain failed, abandoned and unresolved tasks in the denominator and show unknown outcomes and coverage. Proposed weekly reviewer: Quality Engineering. |
+| Is quality holding up? | Link accepted changes to confirmed defects, severity and follow-up dates; retain PR/CI evidence. Apply [escaped quality](./measurement/changes-with-escaped-quality-issues.mdx) after follow-up, counting each affected change once, alongside severe incidents. Missing links are not clean work. Proposed monthly reviewer: Quality Engineering. |
+| What does an accepted outcome cost? | Reconcile invoices and usage, sampled review/rework minutes at approved rates, unsuccessful attempts and allocated licenses/tooling. Apply [cost per accepted outcome](./measurement/cost-per-accepted-outcome.mdx) to the same matured start cohort; distinguish effort from waiting. Missing buckets make the estimate partial. Proposed monthly reviewer: Finance & Accounting; restate late invoices. |
+| Can people confidently verify the work? | Use the anonymous 1–5 survey for confidence, manageable workload and usefulness as separate items. Report the [confidence measure](./measurement/verification-confidence-and-cognitive-load.mdx), distribution and response rate; protect small groups. Proposed reviewer after each pilot cycle: People & Administration. This is enablement evidence, not proven saved time. |
+
+### What a pilot report looks like
+
+**Illustrative arithmetic, not company results or targets.** The bundled synthetic fixture shows four matured starts: one accepted, one failed, one abandoned and one unresolved. Confirmed success is **1 / 4 × 100 = 25%**, with **75%** known-outcome coverage. A newer start has not finished its observation period and is shown separately.
+
+Recorded compute spend is **EUR 60 / 1 = EUR 60** per accepted outcome—a **partial estimate** because licenses, tooling, review and rework are missing. Five survey responses total 20 points: **20 / 5 = 4** out of 5; response rate is **5 / 10 × 100 = 50%**. Reconcile the unknown task and missing costs instead of claiming a skills benefit. Reproduce it with `node scripts/ai-kpi.mjs`; [fixture and limits](./measurement/synthetic-example.mdx).
+
+### Revisit selection as adoption expands
+
+Selection precision/recall qualify named skill versions against labeled cases; they do not measure real-workflow acceptance. Keep any skill/version evaluation separate from the live task-success cohort. Skill-specific measures with no applicable population are N/A, not zero; missing evidence for an existing population remains unknown.
+
+Keep relevant outcome evidence comparable; add reach measures only if they answer the expanded workflow's questions. For [supported bundle coverage](./measurement/supported-bundle-coverage.mdx), freeze the expected active installation inventory and compare observed bundle/adapter revisions to support and revocation records. Offline or stale entries stay in the denominator. Platform & IT is the proposed weekly and at-revocation reviewer.
+
+For [approved-workflow adoption](./measurement/approved-workflow-adoption.mdx), freeze the lawfully enrolled participant cohort and distinguish qualified-adapter observations from labeled declarations. Report the observed lower bound with source coverage: missing use is unknown; installation and loading are not use. Data & AI is the proposed monthly reviewer. No invocation quotas or employee rankings. Return to Baseline for a new workflow rather than treating rollout as company-wide metric collection.
+
+</details>
+
+**Next:** [Maintain skills using the agreed evidence →](./skills-maintenance.mdx)
+
+</div>

docs/strategy/skills-governance.mdx

@@ -0,0 +1,113 @@
+---
+id: skills-governance
+title: Skills governance
+description: Contract, lifecycle, decision rights, adapters, locking, exceptions.
+hide_table_of_contents: true
+---
+
+import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
+
+<div className="strategy-content">
+
+**TO-BE · Target operating model — not installed controls or company results.**
+
+## Who can approve a skill for use?
+
+Use this optional reference only if the [six-month experiment](./six-months-roadmap.mdx#exp-01-a-small-decision-ready-example) selects skills. The architect can author with a willing team; an independent reviewer assesses the candidate and the actual workflow approver authorizes bounded use. Departmental names below are proposed functions, not company facts or conscripted staff. A reviewed repository entry plus existing controls can support one pilot; no enterprise catalog service is required first.
+
+<ArchifyDiagram name="strategy-governance" title="An owner proposes; independent review and canary evidence precede approval" story />
+
+- **Separate duties:** the author cannot provide the only approval; higher risk involves Architecture &amp; Security.
+- **Pin the whole bundle:** content, adapters and executable dependencies travel together.
+- **Keep controls authoritative:** exceptions expire and cannot bypass protected release, payment or identity controls.
+
+## Connect knowledge without expanding authority
+
+Use the workflow map from [Baseline](./baseline.mdx) to engineer a connected skills topology. In the **illustrative Delivery workflow**, repository understanding produces a source-and-constraints map; change/test preparation consumes it and produces a patch plus regression evidence; independent verification consumes that exact artifact and returns findings. Each handoff specifies its trigger, expected output and what happens when evidence is missing. The agent cannot mark its own work approved or acquire deployment credentials through a skill.
+
+Governance spans design, qualification, the pilot and maintenance—not just entry to a catalogue. The owning Product Engineering team's designated accountable person records scope and permitted effects; an independent Quality Engineering reviewer accepts [evaluation evidence](./skills-quality.mdx); Architecture &amp; Security reviews higher-risk boundaries; Platform &amp; IT verifies the qualified distribution path. These are recommended assignments within existing teams: name the actual people before relying on a decision.
+
+**Two different permissions:** qualification may justify a bounded experimental pilot. Wider approved use requires the pilot comparison and canary evidence too. Record exact revisions, audience, expiry/stop conditions and approvers for each; neither a baseline nor a passing test grants permission by itself. Failed review returns the candidate to its author; unsafe use enters [Maintenance containment](./skills-maintenance.mdx).
+
+<details>
+<summary>Ownership, client qualification, exceptions and rollback</summary>
+
+**TO-BE · Target operating model.** Use these contracts throughout the [Stage 01 journey](./stage-01-skills-adoption.mdx); they are not installed controls or measured company results.
+
+### A contract that travels, controls that stay authoritative
+
+Maintain one catalog entry per stable skill ID, with immutable revisions and a concise portable `SKILL.md` body. Required content includes when to use and when not to use the skill, prerequisites, bounded steps, expected artifacts, verification, failure handling and escalation. The catalog contract below defines owner and independent reviewer, risk tier, supported clients and versions, dependencies, digest, provenance and license, evaluations, approval, review date, deprecation and rollback.
+
+The release manifest pins the content, dependencies and adapter revisions by full immutable commit or digest. Names use an `eldorado-` prefix to reduce collisions. Friendly versions aid communication but never replace the digest. No arbitrary upstream automatic update is admitted into the approved bundle. Changes to scripts, resources or dependencies count as skill changes, not harmless documentation edits.
+
+Adapters place content in the qualified client's discovery paths and implement only verified client-specific behavior. Qualification records the host, exact build, OS, model configuration, discovery, explicit invocation, collisions, disabled skills, permission behavior, context compaction and reload behavior. A common file format is not common precedence or a portable hooks API. Claude and Cline skill-name precedence differs from rule/memory behavior; Copilot support varies by surface. Test the actual build, not the brand name.
+
+### Lifecycle and decision rights
+
+A proposal names the problem, owner, data scope and testable outcome. Initial experimental qualification runs only in approved disposable environments. Real work requires a separate bounded-pilot authorization after qualification; that authorization permits only its recorded cohort, data and effects, not general approved use. Promotion from the bounded pilot requires independent review, static and executable dependency checks, per-client evaluations, pilot outcomes and canary evidence. Approval records bind the exact artifact and permitted uses. Deprecated revisions carry a migration path and deadline; retired revisions are unavailable for new work. Any active revision can be quarantined immediately.
+
+The author never supplies the only approval. Data & AI maintains catalog state; the owning team is accountable for content; Quality Engineering approves evaluation evidence; Architecture & Security approves higher-risk boundaries; Platform & IT verifies distribution and revocation. A business owner accepts workflow outcomes. These functions can be covered by existing staff, but incompatible author/approver duties must remain separate for the same release.
+
+An exception contains its ID, skill/client revision, scope, business reason, risk owner, compensating checks, approver, start and expiry, affected users/projects and rollback route. It does not disable protected release, payment or identity controls. Expired or unverifiable exceptions deny privileged actions. Repeated exceptions trigger a supported-design change rather than permanent informal bypass.
+
+### Distribution, stale clients and rollback
+
+Stage a verified bundle atomically, check its digest, load it through the qualified adapter and read back its effective revision. Test already-open sessions; changing files is not proof of reloading instructions. Record immutable last-known-good content and adapter dependencies where an approved revision exists. For a first revision, record **N/A: no approved bundle** and the [Quality first-revision rule](./skills-quality.mdx): compare with declared current AI-assisted practice; test disable/remove, invalidate/reload sessions and verify recovery in a pinned clean environment. Independent reviewer acceptance and actual workflow-approver pilot permission are still required. Canary upgrades precede wider distribution.
+
+A cached verified bundle may support explicitly permitted low-risk work if its model and tool dependencies are available. It does not make a cloud-backed client work offline. Stale or unsupported sessions cannot obtain centrally mediated privileged access. Reconnection revalidates support, revocation and policy before credentials are issued. Central artifact review protects delivery even when a laptop declaration is absent or false; a client report cannot prove which private prompt was actually followed.
+
+Rollback restores the approved manifest and dependencies when present; first-revision recovery removes the candidate and restores declared current practice without inventing a prior approved skill. Invalidate affected sessions, revoke unsafe revisions, run a smoke test and verify effective state. Recovery cannot undo data disclosure or commands already executed. Those require incident response.
+
+</details>
+
+<details>
+<summary>Catalog contract — required fields</summary>
+
+## Catalog contract
+
+| Contract | Definition |
+| --- | --- |
+| skill_id | Stable globally unique eldorado-&lt;domain&gt;-&lt;purpose&gt;; never reused for a different purpose |
+| name | Human-readable name |
+| purpose | Problem, expected outcome and intended users |
+| triggers | Positive and negative invocation conditions |
+| owner | Existing department/team plus assigned accountable person before approval |
+| reviewer | Independent person and existing team; cannot equal release author |
+| backup | Named coverage within existing team before production support |
+| risk_tier | R1\|R2\|R3; maximum implied by data, tool and effect scope |
+| data_classification | Allowed input/output/provider boundary and forbidden data |
+| authority_envelope | Allowed resources/operations and forbidden effects; enforced externally |
+| supported_clients | Array of client, host, exact tested builds, OS, model configuration, adapter digest and qualification evidence |
+| dependencies | All skill/resource/script/tool/MCP/plugin dependencies pinned by immutable digest plus license and source |
+| revision | Full immutable source commit and content/artifact digest; friendly semver optional |
+| tests_evals | Suite/corpus/rubric/runner/judge revisions, client tuple, seeds or trial IDs, results and independent evidence refs |
+| approval | Approver identities, exact digest and policy revision, approved scope, time and expiry/invalidation condition |
+| provenance_license | Origin repository/author, upstream revision, acquisition/review history, rights/license for content and bundled resources |
+| maintenance_date | Last substantive review timestamp plus next review due and trigger conditions |
+| deprecation | State, reason, replacement, migration instructions, consumers and retirement deadline if applicable |
+| rollback | Approved known-good bundle+adapter+dependency digests when present; first revision: N/A with reason plus tested disable/remove/reload to pinned clean current practice; independent acceptance required |
+| procedure | Prerequisites, bounded steps, expected artifacts, verification, failure handling, escalation |
+
+
+</details>
+
+<details>
+<summary>Lifecycle transitions and required evidence</summary>
+
+## Promotion and retirement
+
+| Transition | Required evidence |
+| --- | --- |
+| proposed → experimental | Owner, purpose, risk/data scope, disposable environment and preregistered test plan |
+| experimental → bounded pilot | Independent qualification evidence, named pilot approver, exact revision, bounded cohort/data/effects and manual recovery; remains experimental outside that envelope |
+| bounded pilot → approved | Independent review, all mandatory tests, qualified clients, pilot comparison and canary evidence; owning approver records exact-digest authorization for retained scope |
+| approved → deprecated | Owner gives migration/replacement and retirement conditions |
+| deprecated → retired | Consumers reconciled or explicit risk-approved cutover; no new invocation |
+| any active state → quarantined | Incident or unsafe/unknown provenance; central deny immediately |
+| quarantined → experimental | Reviewed correction; new immutable revision; requalify, never auto-restore approval |
+
+</details>
+
+**Next:** [See the evidence needed to qualify a skill →](./skills-quality.mdx)
+
+</div>

docs/strategy/skills-maintenance.mdx

@@ -0,0 +1,74 @@
+---
+id: skills-maintenance
+title: Skills maintenance
+description: Review, drift, deprecation, rollback and incident handling.
+hide_table_of_contents: true
+---
+
+import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
+
+<div className="strategy-content">
+
+**TO-BE · Target operating model — not installed controls or company results.**
+
+Optional skills reference for a retained intervention, not a six-month obligation to establish a catalog program. Map department names to actual agreed functions. The [6 Months Roadmap](./six-months-roadmap.mdx) requires funded upkeep and a willing owner before expansion.
+
+## What happens when a skill drifts or causes harm?
+
+Monitor both **Workflow effectiveness** (comparable outcomes, safety, cost and human experience) and **Skills effectiveness & health** (fitness/regression evidence, selection, supported use and substantive review) throughout a revision's life. Use the evidence to improve, retain or retire skills; adoption or current review dates alone do not prove better work. Unsafe behavior triggers containment; a correction returns through independent tests and approval, never automatic reinstatement.
+
+<ArchifyDiagram name="strategy-maintenance" title="Monitor, triage and test corrections; promote safely or contain and roll back" story />
+
+- **Named ownership:** Data &amp; AI coordinates catalog health with the owning teams.
+- **Early triggers:** incidents and client, model or dependency changes override the calendar.
+- **Recovery is verified:** restore a known-good bundle when present; first-revision recovery disables/removes the candidate, invalidates/reloads sessions and verifies declared current AI-assisted practice in a pinned clean environment. Record no-approved-revision N/A and independent acceptance under the [Quality rule](./skills-quality.mdx); recovery cannot undo disclosure or past effects.
+
+## Close the loop on the retained workflow
+
+Start from [Adoption's decision](./skills-adoption.mdx), the approved manifest and its evidence limits. In the **illustrative Delivery workflow**, a missed regression case becomes a sanitized evaluation case. Product Engineering owns the correction; an independent Quality Engineering reviewer reruns [Quality's fitness and regression evaluation](./skills-quality.mdx) against the approved revision. Keep the live defect and task records in their original populations; do not erase a failure because the replacement passes.
+
+The owning team's designated approver decides whether the corrected exact revision can re-enter a bounded canary, using independent results and Platform &amp; IT's recovery/effective-version evidence; Architecture &amp; Security reviews changed risk boundaries. Missing evidence means hold. Safe unchanged use may continue only within its existing authorization; harmful behavior is contained immediately. These recommended functions require named people before use.
+
+Retain a supported revision, requalify a change or retire it with a reconciled consumer/migration record. A materially changed workflow returns to [Baseline](./baseline.mdx); the [Measurement registry](./measurement/index.mdx) helps revise relevant evidence without silently resetting history. That feedback closes [Stage 01](./stage-01-skills-adoption.mdx)—it does not automatically advance to autonomy.
+
+<details>
+<summary>Review responsibilities, incident handling and proposed review intervals</summary>
+
+**TO-BE · Target operating model.** Maintenance sustains the [Stage 01 journey](./stage-01-skills-adoption.mdx); these pages do not describe installed controls or measured company results.
+
+Every approved skill has an accountable owning team, independent reviewer, review due date, supported client matrix and rollback bundle. Review both usefulness and safety, not just metadata freshness. Proposed maximum review intervals are recorded by risk tier; incidents, dependency changes, model/client drift or repeated failures trigger earlier review.
+
+Data & AI reviews catalog health with the owning teams. Quality Engineering samples accepted outputs and adds confirmed failures to regression sets without exposing sensitive content. Platform & IT watches unsupported, deprecated and revoked revisions and tests distribution recovery. Architecture & Security reviews emerging misuse and exception expiry. Remove redundant or unused entries deliberately, after examining whether poor discoverability or fit explains non-use.
+
+A reported unsafe behavior opens an incident with artifact, policy and client versions. Architecture & Security coordinates containment; Platform & IT revokes authority, stops scheduling and quarantines affected revisions; the owning department handles customer or business consequences; Quality Engineering reproduces the failure; Data & AI coordinates catalog correction and trend analysis. Preserve minimal restricted evidence and involve People & Administration Squad for employee-data concerns and Finance & Accounting Squad for financial effects. Restart requires a reviewed fix, regression evidence, verified rollback/revocation and accountable human authorization. Closing the incident does not erase the historical failure from measurement.
+
+## Proposed maximum review intervals
+
+Owner ratification is required before adoption. Review earlier after incidents or material dependency changes.
+
+| Tier | Maximum days between substantive reviews |
+| --- | --- |
+| R1 | 90 |
+| R2 | 60 |
+| R3 | 30 |
+
+</details>
+
+<details>
+<summary>Ongoing reporting and comparison</summary>
+
+## Keep selected evidence useful
+
+Continue the measures agreed for the workflow in [Baseline](./baseline.mdx) and applied during [Adoption](./skills-adoption.mdx). Revisit relevance when scope changes; the [registry](./measurement/index.mdx) is a source of choices, not a requirement to collect every metric. Preserve current-workflow comparisons separately from named skill/version evaluations. No applicable skill population is N/A, not zero; missing evidence for existing revisions is unknown and must not improve reported health.
+
+If substantive-review coverage is selected, join each active approved catalog revision to its owner, substantive review evidence and due date. Apply [review coverage](./measurement/skills-within-substantive-review-window.mdx): revisions with all three current / all active approved revisions × 100. The proposed Data & AI review is monthly and at each release, subject to agreement. Report overdue/ownerless revisions and deprecated or revoked versions still in use—not just a percentage.
+
+At each agreed report, compare like workflows with their recorded starting position. Publish period, counts, exclusions, source coverage and changes in calculation or scope. Zero denominators mean “not available”; unresolved gaps remain visible. Trends are descriptive, not causal ROI. Reconcile late evidence using versioned corrections and distinguish changed practice from changed measurement.
+
+Act on critical policy effects immediately; do not wait for a reporting cycle. Use selection precision/recall at qualification, or service-level delivery and departmental outcome measures, only where relevant and their source links are feasible. Confirm purpose, lawful basis, access and retention before changing collection, following the [shared safeguards](./measurement/collection-and-safeguards.mdx).
+
+</details>
+
+**Continue the loop:** [Requalify changed skills →](./skills-quality.mdx). For a separate future authority decision, read [Beyond 6 Months](./stage-02-autonomous-agent.mdx).
+
+</div>

docs/strategy/skills-quality.mdx

@@ -0,0 +1,100 @@
+---
+id: skills-quality
+title: Skills quality
+description: Risk tiers, independent evaluation, repeated trials, adversarial conformance.
+hide_table_of_contents: true
+---
+
+import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
+
+<div className="strategy-content">
+
+**TO-BE · Target operating model — not installed controls or company results.**
+
+**Optional skills reference for the [6 Months Roadmap](./six-months-roadmap.mdx).** Use this when skills are the chosen intervention, not as a prerequisite for discovery or coaching. Department names denote functions to map to actual willing staff; the architect cannot assign them authority.
+
+## What evidence is enough to promote a skill?
+
+Risk determines the evaluation depth, not whether safety checks apply. Independent evidence must show useful outcomes and no failed mandatory gate before promotion.
+
+<ArchifyDiagram name="strategy-quality" title="Classify risk, test independently, then pass every mandatory gate" story />
+
+- **R1:** approved nonsensitive drafting. **R2:** code or customer-impacting material. **R3:** privileged or sensitive effects; human-authorized, outside initial autonomous scope.
+- **No averaging away harm:** a critical unauthorized effect blocks promotion.
+- **Proposed floors need owner ratification:** missing coverage or acceptance rules means qualification is incomplete.
+
+## Prove the candidate fits the workflow
+
+Bring the workflow/acceptance map from [Baseline](./baseline.mdx) and the pinned candidate, client tuple and authority envelope from [Governance](./skills-governance.mdx). In the **illustrative Delivery workflow**, test whether a candidate actually produces a correct bounded change and regression tests—not just whether it was selected. Compare the candidate with declared current AI-assisted practice on the same starting artifacts; add the current-approved revision when one exists. Include misleading repository instructions, missing tests and requests to bypass review.
+
+**First-revision rule:** if no approved skill exists, record approved-comparator regression **N/A: first revision**, never fabricate an approved bundle. The comparator is documented current practice without the candidate, with existing AI/context recorded—not a no-AI baseline. Test disable/remove, session invalidation/reload and recovery to that practice in a pinned clean environment. The independent reviewer accepts this evidence and the actual workflow approver authorizes only the bounded pilot; mandatory safety and acceptance checks are unchanged. Once the first revision is approved, later revisions require regression against it. See [EXP-01](./stage-01-skills-adoption.mdx) for the assembled packet.
+
+The independent Quality Engineering reviewer records accepted and failed artifacts, safety results, coverage and regression differences for each named revision. The owning team's designated approver then decides whether that evidence supports a bounded pilot; Architecture &amp; Security must accept any higher-risk boundary. A mandatory failure or an unagreed acceptance rule means rework or hold. These are proposed decision responsibilities, not already assigned people.
+
+**Qualification artifact success is not live task success.** The evaluation denominator is planned executed trials, retaining failures and abandonment, with omitted/unexecuted cases shown as coverage gaps. [Validated task success](./measurement/validated-task-success.mdx) instead uses matured real-workflow starts. Never pool them. [Measurement](./measurement/index.mdx) links selection and health signals to this fitness evidence; neither usage nor a fresh review date proves effectiveness.
+
+The output is a versioned qualification report and explicit limitations for [Adoption](./skills-adoption.mdx), not approval of every future task. [Maintenance](./skills-maintenance.mdx) feeds real failures and material client/model/dependency changes back into this same evaluation, including regression against the currently approved revision.
+
+<details>
+<summary>Evaluation design, adversarial cases and interpretation</summary>
+
+**TO-BE · Target operating model.** Qualification supports the [Stage 01 journey](./stage-01-skills-adoption.mdx); these pages do not describe installed controls or measured company results.
+
+Quality has four separate questions: was the right skill selected, was the procedure executed safely, did the artifact pass independent checks, and did the workflow produce useful outcomes? A successful invocation answers none of the remaining questions by itself.
+
+The proposed qualification contract uses three tiers. R1 is read-only or drafting with nonsensitive approved material; R2 creates code or material with customer impact but no privileged external effect; R3 touches privileged, financial, sensitive-personal or production decisions. R3 remains human-authorized and out of the initial autonomous scope.
+
+Every tier requires all mandatory deterministic safety, schema, authorization and provenance checks to pass, with no observed critical unauthorized action. An observed critical effect blocks promotion. The proposed pilot evaluation floors below set success thresholds; these are design defaults for owner ratification, not externally validated guarantees or approved service levels. If sample coverage, acceptance criteria or responsible reviewers are missing, qualification remains incomplete. No aggregate score can trade off a failed mandatory safety check.
+
+Use sanitized, predeclared task sets containing positive triggers, near misses, negative cases and the normal workload mix. Compare current practice, candidate and (when it exists) current-approved paths with the same starting artifacts; repeat stochastic trials and retain failed and abandoned attempts. A no-standardized-skill path may still use AI. Independently inspect output state. Deterministic tests grade checkable constraints; calibrated humans grade usefulness, maintainability and experience. A model judge is supplementary, versioned and checked against human disagreements, never the sole safety or promotion authority.
+
+Include adversarial repository text, malicious referenced code, wrong permissions, client toggles, name shadowing, unsupported versions, hook timeout/crash/malformed response, stale sessions, offline recovery and rollback. Run central checks against forged/missing client declarations. Hook presence is not fail-closed enforcement: failure semantics must be tested on each client, and central authorization remains independent.
+
+Report denominators, task mix, trial counts, per-client results and uncertainty. A passing benchmark is evidence within a tested envelope, not proof that all future tasks are safe. Material model, client, adapter or dependency changes trigger requalification.
+
+</details>
+
+<details>
+<summary>Proposed R1 / R2 / R3 sample sizes and thresholds</summary>
+
+## Proposed qualification floors
+
+These are optional reference designs, not mandatory startup floors, approved service levels or guarantees. Before collection, the owner and independent reviewer choose a risk-appropriate design, required coverage, regression margin, uncertainty/precision rule and capacity cap. Start with one workflow and one client configuration. Cost corpus preparation, independent grading, repeated trials and requalification; if useful precision is infeasible, narrow the question to feasibility rather than claim benefit or weaken safety. All mandatory checks must pass regardless of aggregate score. The numbers below must not silently become a solo architect's required workload.
+
+### R1
+
+**Distinct tasks** — 30
+
+**Trials per task/client** — 3
+
+**Artifact success** — 90%
+
+**Selection precision / recall** — 90% / 90%
+
+### R2
+
+**Distinct tasks** — 60
+
+**Trials per task/client** — 3
+
+**Artifact success** — 95%
+
+**Selection precision / recall** — 95% / 90%
+
+### R3
+
+**Distinct tasks** — 100
+
+**Trials per task/client** — 5
+
+**Artifact success** — 99%
+
+**Selection precision / recall** — 99% / 95%
+
+Artifact success denominator is every planned executed trial, retaining failures and abandonment. Trials of same task are correlated: show per-task and per-client strata; do not inflate independent sample size. Selection floors use independent labels. Report 95% uncertainty intervals clustered by task for outcome comparisons; no regression versus the current approved path, when one exists, beyond a preregistered owner-approved margin. First-revision approved regression is N/A with reason, but current-practice acceptance and safety remain mandatory. Missing applicable margin/precision rule prevents promotion. Small feasibility studies cannot establish that rule after seeing favorable results.
+
+</details>
+
+**Next:** [Introduce qualified skills through a bounded pilot →](./skills-adoption.mdx)
+
+</div>

docs/strategy/stage-01-skills-adoption.mdx

@@ -0,0 +1,58 @@
+---
+id: stage-01-skills-adoption
+title: Skills lifecycle reference
+description: Work through an illustrative Delivery experiment from current AI-assisted practice to an evidence-based decision.
+hide_table_of_contents: true
+---
+
+import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
+
+<div className="strategy-content">
+
+Improve one workflow through human + AI Agent work, then repeat with evidence. This is the practical experiment supporting the [6 Months Roadmap](./six-months-roadmap.mdx), not a mandatory skills program or permission to deploy the long-term autonomous [Target](./target-operating-model.mdx). Use context, coaching, test/review feedback or deterministic automation if they better address the bottleneck.
+
+<ArchifyDiagram name="strategy-stage01" title="One workflow: establish the starting point, engineer and qualify, pilot, decide, maintain and learn" story />
+
+**Read the arrows as handoffs, not a checklist of page approvals.** Governance bounds every activity. Measurement supplies selected definitions throughout. Quality establishes candidate fitness; Adoption tests usefulness in real work; Maintenance returns failures and changed conditions to qualification.
+
+The [6 Months Roadmap](./six-months-roadmap.mdx#exp-01-a-small-decision-ready-example) owns EXP-01 and the month-by-month plan; this reference only explains reusable lifecycle handoffs within the broad [Roadmap](./roadmap.mdx).
+
+## Delivery first: one change, from intent to accepted work
+
+**Illustrative Delivery workflow throughout these pages — not an Eldorado pilot or measured result:** a Product Engineering developer uses an AI Agent to prepare a bounded code change and regression tests. An independent reviewer checks the exact change and evidence. Existing release authority remains unchanged; the skill cannot approve or deploy its own output.
+
+First trace codebase structure and existing principles → system-logic source → tests → builds and packaging → deployments. Identify the friction to improve—for example, incomplete regression evidence that sends changes back for rework. Verify that this is the actual problem before choosing a skill.
+
+Adoption can extend to other SDLC phases; their order is not yet decided. Delivery keeps improving as adoption expands.
+
+## Carry evidence forward, not assumptions
+
+1. **Understand and baseline.** Product Engineering maps the selected workflow and desired improvement. Select relevant KPIs from [Measurement](./measurement/index.mdx); [Baseline](./baseline.mdx) records current outcomes, acceptance rules and explicit gaps. A baseline describes work; it grants no approval.
+2. **Choose the smallest candidate.** If repeated agent guidance is the bottleneck, use [Governance](./skills-governance.mdx) to connect repository understanding → change/test preparation → independent verification. Specify triggers, inputs, outputs, handoffs, pinned dependencies and forbidden actions. This skills topology is more than a catalogue; a deterministic fix may need no skill.
+3. **Qualify before exposing real work.** [Quality](./skills-quality.mdx) compares the candidate with declared current practice. If no approved skill exists, approved-revision regression is N/A with reason; test removal and recovery to current practice. Once an approved revision exists, add that comparator. The independent Quality Engineering reviewer function accepts evaluation evidence; the owning team's designated approver authorizes only the tested pilot envelope, with security review where risk requires it. Failed checks or missing authority mean rework or hold, not an automatic pilot.
+4. **Pilot and compare.** [Adoption](./skills-adoption.mdx) applies that revision to a bounded real-work cohort, retaining the manual path. Compare accepted outcomes, quality, review/rework cost and feedback with the starting position. Live tasks and qualification trials remain separate populations.
+5. **Decide and maintain.** The owning team's designated workflow owner decides retain, improve, stop or propose expansion from the comparison and independent evidence. [Maintenance](./skills-maintenance.mdx) keeps retained revisions supported and feeds defects into requalification. A new scope returns to Baseline; a changed revision returns to Quality. The new current situation starts the next loop.
+
+These are recommended functions, not evidence of actual departments or appointed people. The architect may build and coordinate; a willing developer/reviewer and actual workflow owner agree contributions. One worksheet plus existing PR/CI records can suffice. Before work starts, record actual people, acceptance rules and permitted effects. Missing assignments keep the affected decision on hold.
+
+<details>
+<summary>Where each topic helps—and what it gives the next activity</summary>
+
+| Topic | Use it when | Carry forward |
+| --- | --- | --- |
+| [Measurement](./measurement/index.mdx) | Choosing or interpreting evidence at any point | Relevant contracts for Workflow effectiveness and Skills effectiveness & health; no mandatory full catalogue |
+| [Baseline](./baseline.mdx) | Understanding a workflow or a material scope change | Workflow map, selected definitions, evidenced starting position or gaps |
+| [Governance](./skills-governance.mdx) | Designing, approving, distributing or withdrawing any revision | Named accountability, authority envelope and exact-revision decision record |
+| [Quality](./skills-quality.mdx) | Introducing or changing skills, clients, models or dependencies | Versioned evaluation results, failures, limits and independent recommendation |
+| [Adoption](./skills-adoption.mdx) | Introducing a qualified candidate into bounded work | Comparable outcome report, user feedback and retain/improve/expand/stop decision |
+| [Maintenance](./skills-maintenance.mdx) | Keeping a supported workflow dependable | Reviewed revision, regression cases, recovery evidence or retirement |
+
+The six topics are connected lifecycle activities, not six rigid sequential approval gates. The sidebar is a reading map: you can consult Measurement before, during or after any activity.
+
+</details>
+
+Proven skills and working practices may support [Beyond 6 Months](./stage-02-autonomous-agent.mdx). Stage 01 can remain valuable indefinitely; progression requires a separate case for authority and readiness.
+
+**Start here:** [Understand and baseline one workflow →](./baseline.mdx). Consult the [Measurement registry](./measurement/index.mdx) when selecting evidence.
+
+</div>

docs/strategy/stage-02-autonomous-agent.mdx

@@ -0,0 +1,40 @@
+---
+id: stage-02-autonomous-agent
+title: Beyond 6 Months
+description: Bridge first-six-month evidence toward the long-term human-controlled autonomous SDLC, through separate investment and authority decisions.
+hide_table_of_contents: true
+---
+
+import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
+
+<div className="strategy-content">
+
+**A separate authority decision, not the reward for skills adoption.**
+
+The [6 Months Roadmap](./six-months-roadmap.mdx) ends with a CTO investment decision, not automatic progression. The [experiment](./six-months-roadmap.mdx#exp-01-a-small-decision-ready-example) may justify deeper improvement, selective replication, or stopping. The autonomous [Target](./target-operating-model.mdx) remains the long-term strategy vision; humans retain direction and review. The broad [Roadmap](./roadmap.mdx) connects skills and working practices to controlled autonomous capabilities. Six-month outcomes contribute toward that destination, but do not promise its timing or authorize its execution.
+
+If one workflow works but transfer fails, invest in local context and coaching rather than mandate uniform use. If several teams request help and recurring value exceeds support burden, propose dedicated enablement capacity with the CTO and team leads. If deterministic tooling solves the problem more reliably, fund that. If outcomes remain inconclusive, narrow or stop the intervention. Recheck the next-quarter portfolio against business priorities, task supply, team willingness and ownership; do not extrapolate a pilot to all engineering.
+
+<ArchifyDiagram name="strategy-stage02" title="Future authority: evidence and human decision before bounded execution, with independent stop and takeover" story />
+
+## Consider additional authority only when necessary
+
+Carry forward proven skills where useful, measurements and working practices from real human + AI Agent work. The references provide [governance](./skills-governance.mdx), [quality checks](./skills-quality.mdx), [adoption feedback](./skills-adoption.mdx), [measurement](./measurement/index.mdx) and [maintenance](./skills-maintenance.mdx); none is permission to expand authority automatically. The diagram above applies only after a separate business case identifies an operation that supervised work or deterministic automation cannot adequately address.
+
+## Introduce authority deliberately
+
+Establish reliable observation and evidence assembly, then proposing and routing work, before granting scoped execution authority. In the **illustrative Delivery workflow**, preparing a patch under human supervision does not authorize the central agent to merge or deploy it. A proposal must explain which extra operation is needed, why Stage 01 is insufficient, the exact resources/data it may touch and how humans can stop it.
+
+The owning department's designated accountable approver decides the proposed workflow scope, with Architecture &amp; Security accepting the authority/data boundary, Quality Engineering independently assessing behavior and Platform &amp; IT verifying enforcement and recovery. These are recommended functions within existing teams—not appointed approvers or granted permissions. Unresolved release approval roles remain a hold condition; the agent cannot appoint its own authority.
+
+Require exact-artifact approvals, separated credentials, independent checks, idempotency and duplicate/outage recovery, an auditable task ledger, and a tested stop/human-takeover path outside the model. Sensitive decisions remain human; missing evidence never means permission. A readiness failure returns to [Stage 01](./stage-01-skills-adoption.mdx) or redesign; it does not justify a larger experiment.
+
+The output is either a recorded hold or a narrowly scoped authorization with conditions and invalidation rules. Monitor outcomes and authority violations separately. A material boundary change reopens the decision; harmful behavior revokes mutation authority and activates takeover, feeding evidence back into [Quality](./skills-quality.mdx) and [Maintenance](./skills-maintenance.mdx).
+
+This is future direction, not deployed autonomy, agreed delivery dates or approved KPI thresholds. The transition depends on reviewed evidence and explicit authority decisions, not adoption volume alone.
+
+**Return to the plan:** [6 Months Roadmap](./six-months-roadmap.mdx).
+
+**Return to dependable work:** [Continue the Stage 01 improvement loop →](./stage-01-skills-adoption.mdx).
+
+</div>

docs/strategy/target-operating-model.mdx

@@ -0,0 +1,176 @@
+---
+id: target-operating-model
+title: Target
+sidebar_label: Target
+description: An autonomous agent executes and governs the SDLC; humans direct, guide and review the repeating cycle.
+hide_table_of_contents: true
+---
+
+import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
+
+<div className="strategy-content">
+
+**TO-BE · Target operating model — the intended strategy, not a deployed system.**
+
+The long-term destination remains human-directed, guided and reviewed autonomous SDLC. It is not a six-month commitment or present authorization. The [6 Months Target](./six-months-target.mdx) and [6 Months Roadmap](./six-months-roadmap.mdx) describe a credible nearer-term contribution, not a replacement for this ambition. No fixed completion date or inevitable progression is implied.
+
+## Autonomous SDLC, human direction
+
+<ArchifyDiagram name="strategy-target" title="Autonomous agent executes and governs the SDLC; humans direct, guide and review" story />
+
+An autonomous agent executes and governs every phase. Humans direct, guide and review it; a separate human-controlled AI Agent contributes to each phase from outside the cycle.
+
+**Solid arrows:** lifecycle · **Dotted spokes:** execution and governance · **Dashed arrows:** contributions.
+
+**Scope → Architecture → UI/UX → Planning → Delivery → UAT → Security → Releases → Scope**
+
+The arrows show the intended SDLC cycle, not the order of skills rollout. Releases returns evidence to Scope; human direction informs the next iteration. The [Roadmap](./roadmap.mdx) starts with human + AI Agent work in Delivery before considering wider autonomous authority.
+
+**Illustrative Delivery thread:** an agent prepares a bounded code change and regression evidence, an independent human reviews the exact artifact, and existing release controls decide whether it can advance. Stage 01 makes this working practice dependable; Stage 02 separately considers what the central agent may execute. Skills supply knowledge and verification steps, never permission.
+
+<details>
+<summary>Supporting implementation options: trust boundaries and recovery</summary>
+
+## Controls that support autonomous execution
+
+The lifecycle above is the strategic direction. The earlier control design below is a supporting implementation option, not an agreed assignment of approval roles or a claim of installed controls. Detailed approval policy and responsibilities remain to be defined with humans.
+
+1. Humans direct, guide and review; the autonomous agent executes and governs work across the lifecycle.
+2. The reviewed registry supplies pinned skills and qualified adapters to coordinator and local clients.
+3. Laptop contributors can participate alongside the agent; independent repository and CI checks verify the exact revision.
+4. A separate release service and artifact-scoped approval are possible controls, subject to the policy humans define.
+5. Restricted audit and measurement evidence supports human review and the next Scope iteration.
+
+<ArchifyDiagram name="ai-adoption-target" title="Supporting control option, not agreed approval policy: isolated release authority" />
+
+**TO-BE · Target operating model.** The [Roadmap](./roadmap.mdx) separates skills adoption from the future authority decision; these pages do not describe installed controls or measured company results.
+
+### One coordination function, distributed contributions
+
+The autonomous agent is more than a task router: it executes and governs the repeating SDLC under human direction, guidance and review. A coordinating function maintains work records, dependencies, evidence requests, bounded retries and escalation. Data & AI and the existing AI Architect function are possible implementation contributors, not newly assigned approval authorities. Autonomous execution does not remove human involvement or allow the agent to redefine its own controls.
+
+One logical coordinator does not mean one fragile process. A durable task ledger, explicit state transitions, leases and idempotency keys allow recovery or multiple replicas without duplicate delivery. Inference outages stop new agent decisions, not the organization's ability to take over. People can resume work through the normal deterministic workflow. Evidence and authorization services fail closed for privileged actions; missing evidence never becomes permission.
+
+These controls support the sequence Scope → Architecture → UI/UX → Planning → Delivery → UAT → Security → Releases → Scope; they do not replace it with a separate lifecycle. Product, engineering, design, quality, security and platform expertise inform human direction and review. Specific approval assignments and release permissions are implementation decisions still to be defined.
+
+### Trust and authority boundaries
+
+People authenticate to the work system; the coordinator receives only the project context it needs. Untrusted issue text, repository content, web pages and tool output are task data, never an authorization source. Local clients operate under device controls and project-scoped access. Hard containment requires OS/container isolation, filesystem and network restrictions and separate short-lived identities; a skill folder, prompt or working directory is not a sandbox.
+
+The registry distributes reviewed immutable content and adapters, not ambient credentials. Executable scripts, plugins, MCP servers and dependencies are separately reviewed and pinned. Model-provider routing is allowlisted for the data classification, with approved retention and training-use terms before sensitive data crosses that boundary. Fallback to another provider must not silently change the data policy.
+
+Central controls verify protected-branch review, actual artifact identity, exact commit and policy revision, required checks and a scoped human approval. Candidate changes cannot edit their own authoritative gate or reuse approval for a different artifact. Deployment credentials belong to the release service, not the local agent. Approval expires or is invalidated by changed content. Emergency stop revokes mutation credentials and stops scheduling independently of the model, preserves evidence and enables human takeover.
+
+</details>
+
+<details>
+<summary>Candidate contributions and first workflows for all eleven teams</summary>
+
+### Department contributions
+
+The documented organization model is an assumption to validate, not PDF evidence of actual reporting lines. Candidate functions must be mapped to real people before any decision. The existing team structure provides a starting point. The contributions below are implementation proposals, not settled approval roles or lifecycle gates.
+
+### Product / Product Management
+
+**Contribution and retained human decision** — Own pilot priorities, acceptance criteria and outcome hypotheses; decide product value.
+
+**First bounded workflow and evidence** — Draft acceptance criteria from sanitized discovery notes; independent completeness review and accepted-task success.
+
+### Product / Product Design
+
+**Contribution and retained human decision** — Own design quality, accessibility and research handling.
+
+**First bounded workflow and evidence** — Review a proposed flow against an accessibility checklist; verify findings against the interface.
+
+### Technology / Product Engineering
+
+**Contribution and retained human decision** — Own skill authoring, code review and maintainability; remain accountable for generated code.
+
+**First bounded workflow and evidence** — Test scaffolding and change summaries in a disposable branch; independent tests and escaped-quality follow-up.
+
+### Technology / Platform & IT
+
+**Contribution and retained human decision** — Own supported client inventory, distribution, identity, isolation, CI/release integration, transport and emergency revocation.
+
+**First bounded workflow and evidence** — Qualify a pinned bundle and exercise rollback; inventory and exact-revision gate evidence.
+
+### Technology / Architecture & Security
+
+**Contribution and retained human decision** — Own risk classification, data boundaries, security review and bounded exceptions.
+
+**First bounded workflow and evidence** — Review injected-input and unauthorized-tool cases; independent control evidence and policy-effect counts.
+
+### Technology / Quality Engineering
+
+**Contribution and retained human decision** — Own regression/adversarial suites, rubric calibration and acceptance evidence.
+
+**First bounded workflow and evidence** — Evaluate candidate versus approved skills on repeated representative tasks; retain all failures.
+
+### Technology / Data & AI
+
+**Contribution and retained human decision** — Own catalog coordination, coordinator evaluation and measurement design, through existing AI enablement responsibilities.
+
+**First bounded workflow and evidence** — Curate a small skill set and analyze a prospective pilot; no new AI department.
+
+### Operations / Operations Squad
+
+**Contribution and retained human decision** — Own service acceptance, disputes, fraud, refunds and customer communications.
+
+**First bounded workflow and evidence** — Draft an answer from sanitized resolved cases; Operational Quality workstream checks correctness before any send. No automated dispute/refund decision.
+
+### Marketing / Marketing Squad
+
+**Contribution and retained human decision** — Own brand, factual claims, content rights, publication and spend approvals.
+
+**First bounded workflow and evidence** — Draft a campaign brief against approved brand material; human claim/rights review before publication.
+
+### Finance & Accounting / Finance & Accounting Squad
+
+**Contribution and retained human decision** — Own allocation of total costs, financial evidence and segregation of approvals.
+
+**First bounded workflow and evidence** — Explain a sanitized reconciliation exception; no posting, payout or payment authority.
+
+### HR & Administration / People & Administration Squad
+
+**Contribution and retained human decision** — Own coaching, acceptable use, feedback privacy and people decisions; partner with Platform & IT on access lifecycle.
+
+**First bounded workflow and evidence** — Draft onboarding guidance from approved policy; human accuracy review. No hiring or performance decision automation.
+
+Product keeps two teams; Technology keeps five; the other four departments keep one squad each. Coordination, skill ownership, approval and cover are assignments inside these teams, not new standing departments, roles or headcount. Department leaders retain accountability and designate real approvers before a pilot starts.
+
+See the existing [organization structure](/organization/structure/), [department collaboration](/organization/collaboration/) and [SDLC responsibilities](/organization/sdlc/).
+
+</details>
+
+<details>
+<summary>Strategy rationale and reading map</summary>
+
+### Govern skills first, expand authority only with evidence
+
+Eldorado's target is to make AI-assisted work dependable across the organization: useful guidance, clear human ownership, controlled execution and measurable outcomes. The first investment is understanding and improving current AI-assisted work, not an autonomous replacement for the organization. Governed skills and practices support the direction; context, coaching, test repair or deterministic automation may be the better immediate intervention. A skill packages reusable working knowledge, prerequisites and verification steps. It helps an agent perform a task; it does not grant permission or guarantee that the work is correct.
+
+The target combines an autonomous agent executing and governing the SDLC with humans directing, guiding and reviewing it. Developer choice on local laptops remains a supporting option: Copilot, Claude Code and Cline can receive reviewed portable skill content through qualified adapters. Repository, CI and release controls support execution; detailed approval policies remain implementation decisions, not new roles established by this strategy.
+
+The strategy describes the intended operating model and the evidence required to introduce it. It does not establish that these controls are installed, that every client is supported, or that AI has improved Eldorado's performance. The current reference is the documented six-department organization. Rollout begins by validating actual clients, responsibilities, data boundaries and available evidence.
+
+Success means accepted outcomes with maintained quality, controlled risk and understood total cost. Faster activity without reliable outcomes is not success. More skill invocations, generated lines or tool subscriptions are not productivity targets. People remain accountable for product, customer, financial and personnel decisions.
+
+### Navigate the strategy
+
+- [Roadmap](./roadmap.mdx) — Skills adoption first; future autonomy separately justified, no promised dates or budgets.
+- [6 Months Target](./six-months-target.mdx) — Assignment context, realistic outcomes and assumptions.
+- [6 Months Roadmap](./six-months-roadmap.mdx) — Month 1–6 priorities and bounded experiment decisions.
+- [Skills lifecycle](./stage-01-skills-adoption.mdx) — Supporting handoffs, decisions and feedback.
+- [Baseline](./baseline.mdx) — Understand current work and record the starting position before changing it.
+- [Skills governance](./skills-governance.mdx) — Contract, lifecycle, decision rights, adapters, locking, exceptions.
+- [Skills quality](./skills-quality.mdx) — Risk tiers, independent evaluation, repeated trials, adversarial conformance.
+- [Skills adoption](./skills-adoption.mdx) — Workflow-led coaching, client choice, feedback, manual path.
+- [Measurement](./measurement/index.mdx) — Full KPI contracts, minimal events, illustrative calculations, privacy and limits.
+- [Skills maintenance](./skills-maintenance.mdx) — Review, drift, deprecation, rollback and incident handling.
+- [Beyond 6 Months](./stage-02-autonomous-agent.mdx) — Decide whether bounded autonomous authority is justified and recoverable.
+
+</details>
+
+**Next:** [Follow the Roadmap toward Target →](./roadmap.mdx)
+
+</div>

docusaurus.config.ts

@@ -18,6 +18,7 @@ const config: Config = {
     theme: {customCss: './src/css/custom.css'},
   } satisfies Preset.Options]],
   plugins: [
+    ['@docusaurus/plugin-client-redirects', {redirects: [{from: '/strategy/', to: '/strategy/target-operating-model/'}]}],
     ['@docusaurus/plugin-content-docs', {id: 'organization', path: 'docs/organization', routeBasePath: 'organization', sidebarPath: './sidebars/organization.ts'}],
     ['@docusaurus/plugin-content-docs', {id: 'strategy', path: 'docs/strategy', routeBasePath: 'strategy', sidebarPath: './sidebars/strategy.ts'}],
     ['@docusaurus/plugin-content-docs', {id: 'contribution', path: 'docs/contribution', routeBasePath: 'contribution', sidebarPath: './sidebars/contribution.ts'}],

package.json

@@ -7,34 +7,47 @@
     "node": ">=22"
   },
   "scripts": {
-    "start": "pnpm diagrams:build && docusaurus start",
-    "build": "pnpm diagrams:build && docusaurus build",
+    "start": "pnpm diagrams:build && pnpm presentations:build && docusaurus start",
+    "build": "pnpm diagrams:build && pnpm presentations:build && docusaurus build",
+    "presentations:build": "node scripts/build-presentations.mjs",
     "serve": "docusaurus serve",
+    "test:presentation": "node scripts/browser/presentation.cjs",
+    "test:homepage-embed": "node scripts/browser/homepage-embed.cjs",
     "typecheck": "tsc --noEmit",
     "verify": "pnpm test && node scripts/verify.mjs",
     "verify:build": "node scripts/verify.mjs --build",
     "diagrams:build": "node scripts/build-diagrams.mjs",
-    "test": "node --test scripts/portal.test.mjs"
+    "test": "node --test scripts/*.test.mjs",
+    "test:browser": "node scripts/browser/measurement-pages.cjs && node scripts/browser/sidebar-coverage.cjs && node scripts/browser/skills-stories.cjs && node scripts/browser/strategy-navigation.cjs && node scripts/browser/strategy-story.cjs && node scripts/browser/inline-controls.cjs && node scripts/browser/sdlc-cycle.cjs && node scripts/browser/target-midpoints.cjs && node scripts/browser/skills-measurement.cjs && node scripts/browser/roadmap.cjs && node scripts/browser/roadmap-timeline.cjs",
+    "kpi:example": "node scripts/ai-kpi.mjs"
   },
   "dependencies": {
     "@docusaurus/core": "3.10.2",
+    "@docusaurus/plugin-client-redirects": "3.10.2",
     "@docusaurus/preset-classic": "3.10.2",
+    "@docusaurus/theme-common": "3.10.2",
     "@easyops-cn/docusaurus-search-local": "0.55.3",
     "@fontsource/lato": "5.2.6",
     "@mdx-js/react": "3.1.1",
     "clsx": "2.1.1",
     "prism-react-renderer": "2.4.1",
     "react": "19.1.1",
-    "react-dom": "19.1.1"
+    "react-dom": "19.1.1",
+    "reveal.js": "5.2.1"
   },
   "devDependencies": {
     "@docusaurus/module-type-aliases": "3.10.2",
     "@docusaurus/tsconfig": "3.10.2",
     "@docusaurus/types": "3.10.2",
     "@types/react": "19.1.13",
+    "playwright": "1.63.0",
     "typescript": "5.9.3"
   },
-  "pnpm": {"overrides": {"serialize-javascript": "7.0.5"}},
+  "pnpm": {
+    "overrides": {
+      "serialize-javascript": "7.0.5"
+    }
+  },
   "browserslist": {
     "production": [
       ">0.5%",

pnpm-lock.yaml

@@ -14,9 +14,15 @@ importers:
       '@docusaurus/core':
         specifier: 3.10.2
         version: 3.10.2(@mdx-js/react@3.1.1(@types/react@19.1.13)(react@19.1.1))(debug@4.4.3)(postcss@8.5.28)(react-dom@19.1.1(react@19.1.1))(react@19.1.1)(typescript@5.9.3)
+      '@docusaurus/plugin-client-redirects':
+        specifier: 3.10.2
+        version: 3.10.2(@mdx-js/react@3.1.1(@types/react@19.1.13)(react@19.1.1))(postcss@8.5.28)(react-dom@19.1.1(react@19.1.1))(react@19.1.1)(typescript@5.9.3)
       '@docusaurus/preset-classic':
         specifier: 3.10.2
         version: 3.10.2(@algolia/client-search@5.59.0)(@mdx-js/react@3.1.1(@types/react@19.1.13)(react@19.1.1))(@types/react@19.1.13)(postcss@8.5.28)(react-dom@19.1.1(react@19.1.1))(react@19.1.1)(search-insights@2.17.3)(typescript@5.9.3)
+      '@docusaurus/theme-common':
+        specifier: 3.10.2
+        version: 3.10.2(@docusaurus/plugin-content-docs@3.10.2(@mdx-js/react@3.1.1(@types/react@19.1.13)(react@19.1.1))(postcss@8.5.28)(react-dom@19.1.1(react@19.1.1))(react@19.1.1)(typescript@5.9.3))(postcss@8.5.28)(react-dom@19.1.1(react@19.1.1))(react@19.1.1)
       '@easyops-cn/docusaurus-search-local':
         specifier: 0.55.3
         version: 0.55.3(@docusaurus/theme-common@3.10.2(@docusaurus/plugin-content-docs@3.10.2(@mdx-js/react@3.1.1(@types/react@19.1.13)(react@19.1.1))(postcss@8.5.28)(react-dom@19.1.1(react@19.1.1))(react@19.1.1)(typescript@5.9.3))(postcss@8.5.28)(react-dom@19.1.1(react@19.1.1))(react@19.1.1))(@mdx-js/react@3.1.1(@types/react@19.1.13)(react@19.1.1))(postcss@8.5.28)(react-dom@19.1.1(react@19.1.1))(react@19.1.1)(typescript@5.9.3)
@@ -38,6 +44,9 @@ importers:
       react-dom:
         specifier: 19.1.1
         version: 19.1.1(react@19.1.1)
+      reveal.js:
+        specifier: 5.2.1
+        version: 5.2.1
     devDependencies:
       '@docusaurus/module-type-aliases':
         specifier: 3.10.2
@@ -51,6 +60,9 @@ importers:
       '@types/react':
         specifier: 19.1.13
         version: 19.1.13
+      playwright:
+        specifier: 1.63.0
+        version: 1.63.0
       typescript:
         specifier: 5.9.3
         version: 5.9.3
@@ -1109,6 +1121,13 @@ packages:
       react: '*'
       react-dom: '*'
 
+  '@docusaurus/plugin-client-redirects@3.10.2':
+    resolution: {integrity: sha512-z5I5ttCXw+8y2gHVZvqAMmUw4Rb0ZzKA5eCPk87SfM/jCKOTvE24yDpPAwwipvug96ij7mOwEHXWw8G4LlWdGA==}
+    engines: {node: '>=20.0'}
+    peerDependencies:
+      react: ^18.0.0 || ^19.0.0
+      react-dom: ^18.0.0 || ^19.0.0
+
   '@docusaurus/plugin-content-blog@3.10.2':
     resolution: {integrity: sha512-0cbEnNKf0InmLkhj/+nVRmqEnWEoOE8Mh+2x1qOXI0qYpCnphq4RXknVJ8BvybKRXqYVvbmdMfiJSup+k4tm5w==}
     engines: {node: '>=20.0'}
@@ -3962,6 +3981,16 @@ packages:
     resolution: {integrity: sha512-Oo/NZcSWccq8KyoG7gLE9fnltgHns+pNCjCAp/WmjsUySi+sX7y4z4Xqu4fVb42CDHzRPl33fjzT15V1wvcyhA==}
     engines: {node: '>=16.0.0'}
 
+  playwright-core@1.63.0:
+    resolution: {integrity: sha512-rYCsBF/M5HjUch52bbtVONEFjv6Xu8sm8h72dNlR5bzIE1fvC/bxgspzkjSfU+MweEMmPM8KJebG6nnyxo5mCg==}
+    engines: {node: '>=20'}
+    hasBin: true
+
+  playwright@1.63.0:
+    resolution: {integrity: sha512-+7ziBLidS4NaNCdt57SUDT+wYmmd5fmiQejUic/kb+YsYSCPyOOE9sebzMjNmQrsnNpDJqd4WHvV/8lfKfUDUg==}
+    engines: {node: '>=20'}
+    hasBin: true
+
   postcss-attribute-case-insensitive@7.0.1:
     resolution: {integrity: sha512-Uai+SupNSqzlschRyNx3kbCTWgY/2hcwtHEI/ej2LJWc9JJ77qKgGptd8DHwY1mXtZ7Aoh4z4yxfwMBue9eNgw==}
     engines: {node: '>=18'}
@@ -4608,6 +4637,10 @@ packages:
     resolution: {integrity: sha512-g6QUff04oZpHs0eG5p83rFLhHeV00ug/Yf9nZM6fLeUrPguBTkTQOdpAWWspMh55TZfVQDPaN3NQJfbVRAxdIw==}
     engines: {iojs: '>=1.0.0', node: '>=0.10.0'}
 
+  reveal.js@5.2.1:
+    resolution: {integrity: sha512-r7//6mIM5p34hFiDMvYfXgyjXqGRta+/psd9YtytsgRlrpRzFv4RbH76TXd2qD+7ZPZEbpBDhdRhJaFgfQ7zNQ==}
+    engines: {node: '>=18.0.0'}
+
   rtlcss@4.3.0:
     resolution: {integrity: sha512-FI+pHEn7Wc4NqKXMXFM+VAYKEj/mRIcW4h24YVwVtyjI+EqGrLc2Hx/Ny0lrZ21cBWU2goLy36eqMcNj3AQJig==}
     engines: {node: '>=12.0.0'}
@@ -6768,6 +6801,47 @@ snapshots:
       - uglify-js
       - webpack-cli
 
+  '@docusaurus/plugin-client-redirects@3.10.2(@mdx-js/react@3.1.1(@types/react@19.1.13)(react@19.1.1))(postcss@8.5.28)(react-dom@19.1.1(react@19.1.1))(react@19.1.1)(typescript@5.9.3)':
+    dependencies:
+      '@docusaurus/core': 3.10.2(@mdx-js/react@3.1.1(@types/react@19.1.13)(react@19.1.1))(debug@4.4.3)(postcss@8.5.28)(react-dom@19.1.1(react@19.1.1))(react@19.1.1)(typescript@5.9.3)
+      '@docusaurus/logger': 3.10.2
+      '@docusaurus/utils': 3.10.2(clean-css@5.3.3)(cssnano@6.1.2(postcss@8.5.28))(html-minifier-terser@7.2.0)(postcss@8.5.28)(react-dom@19.1.1(react@19.1.1))(react@19.1.1)
+      '@docusaurus/utils-common': 3.10.2(clean-css@5.3.3)(cssnano@6.1.2(postcss@8.5.28))(html-minifier-terser@7.2.0)(postcss@8.5.28)(react-dom@19.1.1(react@19.1.1))(react@19.1.1)
+      '@docusaurus/utils-validation': 3.10.2(postcss@8.5.28)(react-dom@19.1.1(react@19.1.1))(react@19.1.1)
+      eta: 2.2.0
+      fs-extra: 11.4.1
+      lodash: 4.18.1
+      react: 19.1.1
+      react-dom: 19.1.1(react@19.1.1)
+      tslib: 2.8.1
+    transitivePeerDependencies:
+      - '@docusaurus/faster'
+      - '@mdx-js/react'
+      - '@minify-html/node'
+      - '@napi-rs/image'
+      - '@parcel/css'
+      - '@rspack/core'
+      - '@swc/core'
+      - '@swc/css'
+      - '@swc/html'
+      - bufferutil
+      - clean-css
+      - cssnano
+      - csso
+      - debug
+      - esbuild
+      - html-minifier-terser
+      - imagemin
+      - lightningcss
+      - postcss
+      - sharp
+      - supports-color
+      - svgo
+      - typescript
+      - uglify-js
+      - utf-8-validate
+      - webpack-cli
+
   '@docusaurus/plugin-content-blog@3.10.2(@docusaurus/plugin-content-docs@3.10.2(@mdx-js/react@3.1.1(@types/react@19.1.13)(react@19.1.1))(postcss@8.5.28)(react-dom@19.1.1(react@19.1.1))(react@19.1.1)(typescript@5.9.3))(@mdx-js/react@3.1.1(@types/react@19.1.13)(react@19.1.1))(postcss@8.5.28)(react-dom@19.1.1(react@19.1.1))(react@19.1.1)(typescript@5.9.3)':
     dependencies:
       '@docusaurus/core': 3.10.2(@mdx-js/react@3.1.1(@types/react@19.1.13)(react@19.1.1))(debug@4.4.3)(postcss@8.5.28)(react-dom@19.1.1(react@19.1.1))(react@19.1.1)(typescript@5.9.3)
@@ -10793,6 +10867,12 @@ snapshots:
       pvutils: 1.2.0
       tslib: 2.8.1
 
+  playwright-core@1.63.0: {}
+
+  playwright@1.63.0:
+    dependencies:
+      playwright-core: 1.63.0
+
   postcss-attribute-case-insensitive@7.0.1(postcss@8.5.28):
     dependencies:
       postcss: 8.5.28
@@ -11561,6 +11641,8 @@ snapshots:
 
   reusify@1.1.0: {}
 
+  reveal.js@5.2.1: {}
+
   rtlcss@4.3.0:
     dependencies:
       escalade: 3.2.0

presentations/less-prompting-more-shipping/README.md

@@ -0,0 +1,63 @@
+# Less Prompting, More Shipping — v1.1.0
+
+An explanation for the CTO and engineering leads: understand the intended destination and decide how a solo AI Architect should contribute in the first six months. The original `AI_Architect_Test_Task.pdf` supplies the assumed context, four questions and 50-minute total. The same-build Strategy supplies the connected narrative: **Target → Roadmap → 6 Months Target → 6 Months Roadmap → Beyond 6 Months**. The six-month contribution neither replaces the long-term human-controlled autonomous SDLC nor authorizes it.
+
+## Story and timing
+
+23 slides: 21 main slides / **35 minutes**, one **15-minute Q&A**, one **zero-minute reference appendix**. EXP-01 is now one two-minute illustration, not the spine of the strategy. Its detailed fictional sample, extension caps and stop ledger remain in speaker notes and the canonical linked Strategy packet.
+
+The table is the revised presentation allocation. The PDF prescribes 50 minutes total, not this split. The six-month Strategy page still contains an earlier proposed outline; its exact subsection timings are not claimed to match this destination-first deck. No Strategy page was rewritten to accommodate the presentation.
+
+| Slide | Minutes / elapsed | Main message | Strategy evidence (canonical slug) |
+| --- | --- | --- | --- |
+| 1 | 1 / 0–1 | Destination and first contribution | target-operating-model; roadmap; six-months-target; PDF |
+| 2 | 2 / 1–3 | Existing uneven AI; solo CTO-reporting role; unknowns | six-months-target; PDF Context/Q1/assumptions |
+| 3 | 1 / 3–4 | Accepted output, not faster drafts | six-months-target; baseline; measurement |
+| 4 | 3 / 4–7 | Intended SDLC cycle and central human-controlled agent | target-operating-model |
+| 5 | 1 / 7–8 | Eight outside human-controlled contributors | target-operating-model |
+| 6 | 2 / 8–10 | Delivery-first adoption, then other phases, then separate autonomy | roadmap; target-operating-model |
+| 7 | 2 / 10–12 | Connected skills and repeating within-phase learning | roadmap; stage-01-skills-adoption |
+| 8 | 1 / 12–13 | First-six-month building block toward Target | six-months-target; target-operating-model |
+| 9 | 1 / 13–14 | Influence beside work, no team authority | six-months-roadmap |
+| 10 | 2 / 14–16 | Months 1–2: discover, baseline, agree | six-months-roadmap; baseline |
+| 11 | 2 / 16–18 | Months 3–4: qualify, test, compare | six-months-roadmap |
+| 12 | 2 / 18–20 | Months 5–6: conditional transfer and handover | six-months-roadmap; six-months-target |
+| 13 | 1 / 20–21 | Solo capacity, one live pilot, funded support | six-months-roadmap |
+| 14 | 2 / 21–23 | Acceptance, burden, quality and total costs | measurement; six-months-roadmap |
+| 15 | 2 / 23–25 | Misleading signals and causal limits | measurement; six-months-roadmap |
+| 16 | 2 / 25–27 | Qualification is not pilot permission | skills-quality; six-months-roadmap |
+| 17 | 2 / 27–29 | Fictional EXP-01: cheapest fit, hold, then stop | six-months-roadmap |
+| 18 | 1 / 29–30 | Realistic month-six evidence portfolio | six-months-target; six-months-roadmap |
+| 19 | 2 / 30–32 | Evidence-led investment toward established destination | stage-02-autonomous-agent; target-operating-model; roadmap; six-months-target |
+| 20 | 2 / 32–34 | Separate bounded authority, stop and human takeover | stage-02-autonomous-agent; target-operating-model |
+| 21 | 1 / 34–35 | First CTO alignment and four answers | six-months-roadmap; PDF Q1–4 |
+| 22 | 15 / 35–50 | Q&A | PDF Format; six-months-target |
+| 23 | 0 / optional | Linked references, outside the main talk | PDF; all five Strategy pages plus measurement |
+
+PDF Q1 **What you do** → slides 2, 9–13. Q2 **How you measure it** → 14–17. Q3 **What you achieve** → 8 and 18. Q4 **What comes next** → 4–7 establish the destination; 19–20 explain evidence-led progression. Scale/growth/uneven AI use are assignment facts, not independently measured company facts. Stack, providers, data policy, task supply, partner capacity and bottlenecks remain unknown or hypotheses, explained on slide 2 and in discovery notes.
+
+## Source and build
+
+- `slides.mjs` is the single editorial source for standalone and homepage. Every slide has section, track, timing, narration and source references. Notes are public HTML, never confidential.
+- `target-figure.mjs` provides two presentation-sized views of the original topology. Slide 4 preserves the eight ordered cycle edges and eight governance spokes, including Releases → Scope. Slide 5 preserves all eight external `code-* → phase` contribution edges. There is one central autonomous agent, not a separate Humans node or a reporting hierarchy. Tests compare all three edge sets with the original diagram JSON; desktop and phone are recomposed, not shrunk documentation screenshots.
+- `theme.css` preserves portal Lato/gold/charcoal/light surfaces and isolated standalone styles. Distinct cycle, contribution layer, staged progression, learning loop and horizon compositions support the story.
+- `runtime.js` is unchanged: Reveal, reduced motion, responsive portrait layout, toolbar, isolated embedded focus/URL and no autoplay.
+- `scripts/build-presentations.mjs` generates the same canonical route, exact-pinned local Reveal.js 5.2.1, notes plugin, Lato assets/licenses and `source-map.json`. The map includes slide IDs/sections/tracks/minutes/sources, four-question coverage, exact Strategy and topology source hashes, and provenance without claiming historical revisions are current. No runtime CDN.
+
+From repository root: `pnpm install --frozen-lockfile`, `pnpm test`, `pnpm typecheck`, `pnpm build`, `pnpm verify:build`. Serve `build/` under `/eldorado-v1/documentation/` with a static server. The canonical route remains `/eldorado-v1/documentation/presentations/less-prompting-more-shipping/`. The homepage's **Understand In Speed** embeds that generated document, not a duplicated slide source. Existing Organization, Strategy, homepage component and runtime sources are preserved.
+
+## Present and verify
+
+Arrows/touch navigate. Esc/Overview shows the grid. F/Fullscreen and S/Notes work standalone; embedded focus stays within its own document and parent URL is unchanged. Notes need HTTP(S) and popups. Named deep links such as `#/target` and `#/qualification` survive refresh. Print uses `?print-pdf`: Chromium, landscape, no margins, background graphics. Export has **23 pages**, without notes. No unsolicited PDF/PPTX/ZIP is published.
+
+`pnpm test:presentation <base>` covers 23 slides at desktop, portrait and landscape (69 views), bounds, errors, links, hash/refresh, keyboard, touch, overview, notes popup, fullscreen, homepage handoff and 23-page print layout. `pnpm test:homepage-embed <base>` covers 23 slides at four widths (92 views), focus/scroll/URL isolation, touch, fullscreen, unsupported-fullscreen escape, Tab exit, themes and reduced motion. Outputs are ordered individual PNGs and JSON in `.cache/presentation/` and `.cache/homepage-embed/`; inspect real pixels, not just geometry. Set `PLAYWRIGHT_CHROMIUM_EXECUTABLE` for an installed browser.
+
+Local Docusaurus serve on Node 26 redirects WOFF2 paths with a trailing slash in this environment. Use a regular prefix-correct static server for production-equivalent font verification; missing-font screenshots are not acceptable evidence.
+
+Official runtime references: https://revealjs.com/installation/, https://revealjs.com/speaker-view/, https://revealjs.com/pdf-export/. The pinned package is intentional; runtime API compatibility is judged against 5.2.1, not latest-version assumptions.
+
+## Boundaries
+
+No guaranteed benefits, approved thresholds, staffing commitments or deployed autonomy. The intended long-term destination is explicit, while its timing and authority remain unapproved. First-six-month failure or a cheaper deterministic intervention is compatible with that direction. Human product, risk and release authority is retained. Skills carry knowledge and verification, not permission.
+
+Dependency manifests are unchanged. Previously recorded production audit: 2 critical, 2 high, 2 moderate; this presentation revision is neither remediation nor security-risk acceptance. Chromium viewport testing is not Safari/Firefox, physical-device or full assistive-technology certification. This branch is a review candidate; the dependent reviewer owns merge, exact-main CI and deployed verification.

presentations/less-prompting-more-shipping/runtime.js

@@ -0,0 +1,37 @@
+/* Reveal 5.2.1, fully local runtime; this document is isolated from Docusaurus CSS. */
+const reducedMotion = window.matchMedia('(prefers-reduced-motion: reduce)');
+const portrait = window.matchMedia('(max-width: 700px) and (orientation: portrait)');
+const printing = new URLSearchParams(location.search).has('print-pdf');
+const embedded = new URLSearchParams(location.search).has('embed') && !printing;
+document.documentElement.classList.toggle('embedded', embedded);
+if (embedded) {
+ document.querySelector('.toolbar').hidden = true;
+ // Never load the portal inside the stage when following the reference appendix.
+ document.querySelectorAll('.slides a').forEach(link => { link.target = '_top'; });
+}
+function layoutSize(){
+ const narrow=portrait.matches&&!printing;
+ document.documentElement.classList.toggle('portrait',narrow);
+ return narrow?{width:600,height:1000}:{width:1200,height:660};
+}
+Reveal.initialize({
+  ...layoutSize(), margin:0.04, minScale:0.1, maxScale:2,
+  hash:!embedded, embedded, keyboardCondition:embedded ? () => document.hasFocus() : null,
+  hashOneBasedIndex:false, controls:true, progress:true,
+  slideNumber:'c/t', showSlideNumber:'all', center:false,
+  transition:reducedMotion.matches?'none':'fade', transitionSpeed:'fast',
+  backgroundTransition:'none', autoSlide:0, touch:true,
+  // The host owns fullscreen; speaker tools remain available in the standalone deck.
+  keyboard:embedded ? {70:null,83:null} : true,
+  // Keep deliberate slides on phones rather than Reveal's automatic scroll view.
+  scrollActivationWidth:null, pdfMaxPagesPerSlide:1, pdfSeparateFragments:false,
+  plugins:[RevealNotes]
+});
+portrait.addEventListener('change',()=>Reveal.configure(layoutSize()));
+reducedMotion.addEventListener('change',event=>Reveal.configure({transition:event.matches?'none':'fade'}));
+document.getElementById('overview').addEventListener('click',()=>Reveal.toggleOverview());
+document.getElementById('notes').addEventListener('click',()=>Reveal.getPlugin('notes').open());
+document.getElementById('fullscreen').addEventListener('click',()=>{
+  if(document.fullscreenElement) document.exitFullscreen();
+  else document.documentElement.requestFullscreen?.();
+});

presentations/less-prompting-more-shipping/slides.mjs

@@ -0,0 +1,328 @@
+// Single editorial source for standalone and homepage. Planned narration: 35 + 15 minutes.
+import {cycleFigure,contributionsFigure} from './target-figure.mjs';
+export const slides = [
+  {
+    "id": "opening",
+    "title": "Less Prompting,<br>More Shipping",
+    "minutes": 1,
+    "body": "<p class=\"subtitle\">The destination—and the first six months toward it</p><p class=\"thesis\">Improve accepted engineering work.<br>Not the number of times we ask AI.</p><p class=\"small\">Proposed strategy · 35 minutes + 15 minutes Q&amp;A</p>",
+    "notes": "Open with the outcome, not a tool purchase. The title is a reminder to measure useful work, not an instruction to minimize prompts. More careful prompting may be exactly what good work needs. My proposal is to earn one evidence-backed improvement, make its costs visible, and stop what does not help. Walk through what I do, how I measure, what month six looks like and what comes next. Start with the long-term Target and broad Roadmap, then bound the first-six-month contribution. The five Strategy pages organize this story; the assignment supplies the four questions and total time.",
+    "sources": [
+      "PDF: Format; Context; questions 1–4",
+      "six-months-target",
+      "target-operating-model",
+      "roadmap"
+    ],
+    "kind": "dark",
+    "section": "Why change",
+    "track": "main"
+  },
+  {
+    "id": "starting-point",
+    "title": "We are not starting from “no AI”.",
+    "minutes": 2,
+    "body": "<div class=\"facts\"><div><strong>≈80 → ≈100</strong><span>engineers, by year end</span></div><div><strong>&gt;10</strong><span>teams</span></div><div><strong>Already using AI</strong><span>uneven depth and quality</span></div></div><div class=\"contrast\"><p>Solo architect → CTO<br>No formal authority over teams</p><p>Stack, tools, process, baselines<br>Capacity and actual bottlenecks</p></div>",
+    "notes": "These headcount and usage facts are from the assignment, not independent research. The comparison is existing AI-assisted practice, never an invented no-AI baseline. Delivery is a starting hypothesis, not a finding. The documented departmental model is not evidence of actual assignment staffing. Ask about stack and tool/data restrictions in discovery; do not assume familiar clients are in use. Every timeline and proposed allocation in this deck remains subject to agreement.",
+    "sources": [
+      "PDF: Context; question 1; final assumptions instruction",
+      "six-months-target"
+    ],
+    "kind": "",
+    "section": "Why change",
+    "track": "main"
+  },
+  {
+    "id": "north-star",
+    "title": "A faster draft is not a shipped outcome.",
+    "minutes": 1,
+    "body": "<div class=\"flow\"><span>Intent</span><i>→</i><span>Change + tests</span><i>→</i><span>Independent acceptance</span></div><div class=\"rail\">Existing release authority stays with people.</div><p class=\"statement\">Less rework. Sound quality.<br>Understand the total burden.</p><p class=\"small\">If the bottleneck is CI or review capacity, fix that—not the prompt count.</p>",
+    "notes": "Trace a change through acceptance and its existing release route. An agent can shorten drafting and still make reviewers work harder. The outcome must survive independent acceptance, defect follow-up and total-cost accounting. Observe why work comes back rather than assume more output from the model means more output from engineering. Flaky tests, unclear scope or scarce reviewers may make a non-AI intervention the right investment.",
+    "sources": [
+      "six-months-target",
+      "baseline",
+      "measurement"
+    ],
+    "kind": "",
+    "section": "Why change",
+    "track": "main"
+  },
+  {
+    "id": "target",
+    "title": "Target / Autonomous SDLC.",
+    "minutes": 3,
+    "body": cycleFigure + `<p class="diagram-legend">Solid → lifecycle · Dotted ⇢ executes and governs</p><p class="small">Humans direct, guide and review. Not deployed or promised in six months.</p>`,
+    "notes": "This is the intended destination, not deployed software, an agreed date or a six-month promise. Read the solid cycle clockwise from Scope: Architecture, UI/UX, Planning, Delivery, UAT, Security, Releases, then evidence returns to Scope. The single central autonomous agent executes and governs every phase, not merely routing tickets. Dotted spokes connect it to all eight phases; people direct, guide and review throughout. There is deliberately no separate Humans node or organizational reporting hierarchy. This view isolates the lifecycle and governance relationships for readability; the next slide restores all eight outside human-controlled contributors. Neither diagram assigns approval roles or grants permissions.",
+    "sources": [
+      "target-operating-model"
+    ],
+    "kind": "",
+    "section": "Target",
+    "track": "main"
+  },
+  {
+    "id": "contributors",
+    "title": "People contribute throughout the cycle.",
+    "minutes": 1,
+    "body": `<p class="diagram-intro">Eight separate AI Agents, each human-controlled.</p>` + contributionsFigure + `<p class="small">AI Agent = Claude, Cline, ChatGPT or a similar tool, used under human control.</p><div class="rail">Dashed ⇢ contribution from outside the cycle.</div>`,
+    "notes": "Keep the previous cycle in mind: these eight pairs are its contribution layer, not a second lifecycle or eight central coordinators. Each separate human-controlled AI Agent contributes to its corresponding phase from outside the cycle. The central autonomous agent remains connected to every phase, executing and governing under human direction. Splitting the original topology into two presentation-sized views preserves all eight lifecycle arrows, eight governance spokes and eight contribution arrows without miniaturizing seventeen nodes. Laptop client choice and adapters are implementation options, not a promise of installed support. Human review, product and risk decisions remain necessary.",
+    "sources": [
+      "target-operating-model"
+    ],
+    "kind": "",
+    "section": "Target",
+    "track": "main"
+  },
+  {
+    "id": "roadmap",
+    "title": "Roadmap / Build dependable work first.",
+    "minutes": 2,
+    "body": "<div class=\"journey\"><div><small>STAGE 1 · HUMAN + AI</small><b>Delivery first</b><span>Standardize connected skills<br>and working practices</span></div><i>→</i><div><small>STAGE 1 · EXPAND</small><b>Other SDLC phases</b><span>Order undecided<br>Delivery keeps improving</span></div><i>⇢</i><div><small>STAGE 2 · SEPARATE AUTHORITY</small><b>Autonomous capabilities</b><span>Proven practices + controls<br>toward the Target</span></div></div><div class=\"rail\">Humans direct, guide and review throughout.</div><p class=\"small\">A strategic progression—not a six-month schedule or automatic graduation.</p>",
+    "notes": "The Roadmap has two broad stages. First standardize skills and practices in human plus AI Agent work, starting with Delivery. Then expand across other SDLC phases, with their remaining order explicitly undecided. This adoption order is different from the Target lifecycle sequence. Delivery continues improving while other phases join. Proven skills, measurements and working practices provide a foundation for the future autonomous agent, but adoption volume never grants authority. Stage one is useful in its own right. Evidence may support coaching, context or deterministic tooling rather than a skill for a particular bottleneck; that practical choice contributes to dependable work rather than cancelling the long-term destination.",
+    "sources": [
+      "roadmap",
+      "target-operating-model"
+    ],
+    "kind": "",
+    "section": "Roadmap",
+    "track": "main"
+  },
+  {
+    "id": "learning-loop",
+    "title": "Connected skills. A repeating learning loop.",
+    "minutes": 2,
+    "body": "<div class=\"learning-loop\"><span>Understand work</span><i>→</i><span>Measure + baseline</span><i>↓</i><span>Engineer topology</span><i>→</i><span>Use in real work</span><i>↓</i><span>Collect results</span><i>→</i><span>Reassess</span></div><div class=\"rail\">↻ Repeat within each phase. Not six global rollout stages.</div><p class=\"statement\">Triggers → skills → handoffs → acceptance.</p><p class=\"small\">Relationships and cooperation—not merely a catalogue.</p>",
+    "notes": "Within every adopted phase repeat the loop: understand the current situation, select relevant metrics and baseline, engineer connected skills, use them in real work, collect outcomes/friction/feedback, then reassess and repeat. Topology defines what exists, how skills relate, when each triggers and how they cooperate. In Delivery trace codebase principles through system logic, tests, builds/packaging and deployment before designing that topology. A code-change skill may hand an exact patch and regression evidence to independent review; its trigger is an eligible change, not an ambient right to act. Governance and Measurement support the whole loop. Qualify revisions before use, and reconsider simpler interventions whenever the evidence says they fit better.",
+    "sources": [
+      "roadmap",
+      "stage-01-skills-adoption"
+    ],
+    "kind": "",
+    "section": "Roadmap",
+    "track": "main"
+  },
+  {
+    "id": "six-month-target",
+    "title": "6 Months Target / One credible contribution.",
+    "minutes": 1,
+    "body": "<div class=\"horizon\"><div><small>LONG-TERM DESTINATION</small><b>Human-controlled autonomous SDLC</b></div><div class=\"near\"><small>FIRST SIX MONTHS</small><b>One workflow understood and improved—or stopped with evidence</b><span>One willing partner · reusable practice · owned upkeep</span></div></div><p class=\"statement\">Earn a dependable building block.<br>Do not promise the entire destination.</p>",
+    "notes": "Separate the horizons without making them opposing stories. A credible six-month contribution is a current-work map, an agreed comparison, a bounded intervention and transparent evidence, with a team owner if useful practice is retained. One workflow with one willing team is already meaningful for a solo architect; a second team is conditional on fit and support. These are proposed outcomes, not known company results or guaranteed gains. If an intervention fails, the useful result is an explained stop, retained learning and a better next investment. The autonomous SDLC remains the destination, with no claim that it can or should be delivered in six months.",
+    "sources": [
+      "six-months-target",
+      "target-operating-model"
+    ],
+    "kind": "",
+    "section": "6 Months Target",
+    "track": "main"
+  },
+  {
+    "id": "influence",
+    "title": "Influence is earned beside the work.",
+    "minutes": 1,
+    "body": "<div class=\"roles\"><div><b>CTO</b><span>Sponsor access<br>Resolve priority trade-offs</span></div><div class=\"gold\"><b>Architect</b><span>Pair, build, evaluate<br>Bring evidence—not mandates</span></div><div><b>Willing team</b><span>Agree contribution<br>Own acceptance and upkeep</span></div></div><p class=\"statement\">An invitation with an exit.<br>Not a rollout disguised as a favor.</p>",
+    "notes": "Meet leads, developers and reviewers across contrasting workflows before recruiting one willing team. Show a concrete example to a skeptic and invite them to judge it without requiring enrollment. Agree a short weekly team check-in and a monthly CTO decision review. Record participant and reviewer effort: it is not free labor. If priorities conflict, ask the CTO to choose a trade-off rather than use sponsorship as a compliance escalation. Actual approvers must be named before a pilot.",
+    "sources": [
+      "six-months-roadmap"
+    ],
+    "kind": "",
+    "section": "6 Months Roadmap",
+    "track": "main"
+  },
+  {
+    "id": "months-one-two",
+    "title": "Months 1–2 / Earn the right to test.",
+    "minutes": 2,
+    "body": "<div class=\"timeline\"><div><b>01 · Discover</b><p>Trace real changes.<br>Rank friction and evidence gaps.</p><span>Output: current-work map</span></div><div><b>02 · Agree</b><p>One willing team.<br>Baseline + smallest intervention.</p><span>Output: bounded experiment packet</span></div></div><div class=\"gate\">Decision 1 → Fund one experiment—or hold.</div><p class=\"small\">No partner, reliable checks or lawful evidence → no live pilot.</p>",
+    "notes": "In month one agree expectations and access with the CTO, pair on contrasting workflows and trace repository principles, system logic, tests, builds and deployments. Rank bottlenecks, not teams. Month two observes a prospective baseline and compares context, coaching, test feedback, deterministic automation and skills. Agree task eligibility, acceptance, evidence, people, spend/effort limits and a stop date. The experiment packet can be one worksheet plus existing records. Discovery may need to continue; the calendar does not waive prerequisites.",
+    "sources": [
+      "six-months-roadmap",
+      "baseline"
+    ],
+    "kind": "",
+    "section": "6 Months Roadmap",
+    "track": "main"
+  },
+  {
+    "id": "months-three-four",
+    "title": "Months 3–4 / Test, then decide.",
+    "minutes": 2,
+    "body": "<div class=\"timeline\"><div><b>03 · Work alongside</b><p>Build and independently qualify.<br>Pair on bounded real work.</p><span>Output: failures + reproducible examples</span></div><div><b>04 · Compare</b><p>Reconcile outcomes and burden.<br>Include pending and abandoned work.</p><span>Output: retain / change / hold / stop</span></div></div><div class=\"gate\">Decision 2 → Keep only what the evidence supports.</div><p class=\"small\">Missing follow-up is “unknown”, not “all clear”.</p>",
+    "notes": "Qualification precedes exposure to real work; actual pilot permission is a separate human decision. During month three I pair and collect both benefits and transferred work. Month four compares matured cohorts with the reviewer, records task mix and concurrent changes, and gives the owner and CTO a recommendation. Unsafe work stops immediately. Sparse tasks or missing follow-up make the result inconclusive. Only an explicitly approved bounded extension can continue; otherwise narrow or stop. Do not silently convert a feasibility exercise into a rollout.",
+    "sources": [
+      "six-months-roadmap"
+    ],
+    "kind": "",
+    "section": "6 Months Roadmap",
+    "track": "main"
+  },
+  {
+    "id": "months-five-six",
+    "title": "Months 5–6 / Transfer only if earned.",
+    "minutes": 2,
+    "body": "<div class=\"timeline\"><div><b>05 · Selective transfer</b><p>Champion + backup.<br>Check a second team’s fit.</p><span>Only with capacity and funded upkeep</span></div><div><b>06 · Evidence review</b><p>Team operates without daily help.<br>CTO chooses the next investment.</p><span>Owned workflow—or documented stop</span></div></div><p class=\"statement\">New scope → new baseline.<br>No automatic company-wide rollout.</p>",
+    "notes": "A second team is conditional: willingness, different task mix and support capacity can all change the answer. Keep improving the first workflow if transfer is premature. Hand over a reproducible example, support and recovery instructions to an actual owner and backup. Test operation without my daily assistance rather than treating training attendance as handover. Month six must show limits and stopped work as well as retained value. The CTO decides what is worth funding next.",
+    "sources": [
+      "six-months-roadmap",
+      "six-months-target"
+    ],
+    "kind": "",
+    "section": "6 Months Roadmap",
+    "track": "main"
+  },
+  {
+    "id": "capacity",
+    "title": "One architect. One active live pilot.",
+    "minutes": 1,
+    "body": "<p>Example weekly allocation for the AI architect</p><div class=\"capacity\" aria-label=\"Proposed weekly allocation: two days hands-on, one evaluation, one relationships, one support and decisions\"><div class=\"pair\">2 days<br><b>Pair + build</b></div><div>1 day<br><b>Evaluate</b></div><div>1 day<br><b>Relationships</b></div><div>1 day<br><b>Decisions + buffer</b></div></div><p class=\"statement\">Support is work.<br>Put it in the budget.</p><p class=\"small\">Proposed capacity envelope—not known company availability.</p>",
+    "notes": "This five-day allocation is a planning envelope, not a claim about company staffing. Two days are hands-on, one evaluation, one coaching/relationships, one sponsor decisions, support and contingency. Team lead agreement must include review time. A second team begins only when the first is supportable. Offer reusable examples and bounded office hours, not a permanent help desk to more than ten teams. Excess support demand becomes a CTO investment decision or a smaller scope.",
+    "sources": [
+      "six-months-roadmap"
+    ],
+    "kind": "",
+    "section": "6 Months Roadmap",
+    "track": "main"
+  },
+  {
+    "id": "measures",
+    "title": "Three measures. One decision.",
+    "minutes": 2,
+    "body": "<div class=\"measure-list\"><div><b>Accepted work</b><span>Accepted / all matured eligible starts</span></div><div><b>Review + rework</b><span>Comparable effort, including shifted burden</span></div><div><b>Escaped defects</b><span>Severity and complete follow-up</span></div></div><div class=\"rail\">Alongside: setup, support, upkeep and tool cost. Critical effects stop work.</div><p class=\"small\">Task / PR / CI / defect links + a small effort record; no individual league tables.</p>",
+    "notes": "Use a small balanced set matched to the mechanism, not all sixteen optional metric contracts. Predeclare eligibility, maturity horizons, denominator and follow-up. Register every eligible task start, including failures, abandoned work and unresolved matured starts; pending tasks stay separate. Link tasks to exact PR/CI acceptance and defect records, with a minimal effort log. Record checked reasons for returns, such as missing regression evidence. Agree access, purpose and retention; avoid raw prompt collection and individual performance ranking. Show total setup and recurring cost beside outcomes. If linkage is incomplete, hold the claim.",
+    "sources": [
+      "measurement",
+      "six-months-roadmap"
+    ],
+    "kind": "",
+    "section": "6 Months Roadmap",
+    "track": "main"
+  },
+  {
+    "id": "misleading",
+    "title": "A dashboard can be confidently wrong.",
+    "minutes": 2,
+    "body": "<div class=\"contrast traps\"><p><b>Tempting signal</b><br>More PRs or generated lines<br>Shorter PR elapsed time<br>Higher acceptance rate<br>No defects recorded</p><p><b>Question before believing it</b><br>Useful work—or smaller slices?<br>Less effort—or less waiting?<br>Same task mix and denominator?<br>Enough follow-up and linkage?</p></div><p class=\"statement\">AI usage is diagnostic.<br>It is not the score.</p>",
+    "notes": "Invocation counts, licenses and positive sentiment can help diagnose reach or friction, but are not productivity outcomes. Acceptance changes may reflect selection and learning; stratify by complexity and reviewer availability and record concurrent model/tool/CI changes. Elapsed time is not engineer hours. Missing quality records are not zero defects. Small descriptive samples cannot establish causal ROI; agree uncertainty and precision rules before collecting evidence for a promotion claim. Do not annualize a tiny difference into cash savings.",
+    "sources": [
+      "measurement",
+      "six-months-roadmap"
+    ],
+    "kind": "",
+    "section": "6 Months Roadmap",
+    "track": "main"
+  },
+  {
+    "id": "qualification",
+    "title": "“It worked once” is not a release gate.",
+    "minutes": 2,
+    "body": "<div class=\"flow\"><span>Pin candidate<br>and environment</span><i>→</i><span>Independent<br>qualification</span><i>→</i><span>Separate<br>pilot permission</span></div><div class=\"contrast\"><p><b>Try to break it</b><br>Wrong task · injected instruction<br>Missing tests · recovery</p><p><b>First revision</b><br>No approved prior skill = N/A<br>Remove + reload → current practice</p></div><div class=\"rail\">Failed mandatory safety checks → HOLD. An average cannot override them.</div>",
+    "notes": "The author cannot approve their own evidence or deployment. Test representative work, unrelated-task decline, injected instructions to bypass review, missing-test escalation, and removal/reload recovery. These examples are not a complete risk-tier evaluation suite. A real independent reviewer approves a risk-appropriate design and inspects all results. First-revision regression against an approved skill is N/A, not a fake pass; prove recovery to declared existing AI-assisted practice. The actual workflow approver separately authorizes the exact revision/client, cohort, window, expiry and effects. Security/data boundaries need their actual owners. Later revision changes return to qualification.",
+    "sources": [
+      "six-months-roadmap",
+      "skills-quality"
+    ],
+    "kind": "",
+    "section": "6 Months Roadmap",
+    "track": "main"
+  },
+  {
+    "id": "experiment",
+    "title": "EXP-01 / Better acceptance is not enough.",
+    "minutes": 2,
+    "body": "<p class=\"fiction\">Fictional teaching example · not Eldorado results or approval</p><div class=\"flow\"><span>Missing test evidence<br>→ checklist first</span><i>→</i><span>Incomplete follow-up<br>→ hold expansion</span><i>→</i><span>Higher review burden<br>→ stop candidate</span></div><p class=\"statement\">Keep the useful practice.<br>Reject the unsupported benefit claim.</p><p class=\"small\">Existing AI practice is the comparator. A skill is tested only if needed.</p>",
+    "notes": "Keep one example from baseline to decision. Suppose changes repeatedly lack regression evidence. Compare a repository test map plus review checklist against packaging the same guidance as a skill; the cheaper checklist wins if it performs as well. A skill carries reusable instructions and verification, not authority. Freeze a small non-urgent bug-fix scope, one willing team and one qualified client/model tuple. The full fictional packet includes explicit real-use blanks for people, dates, immutable references, sources and data approval. Those blanks are not permission. The apparent nine versus eight accepted is not a demonstrated gain. Baseline has two failed, one abandoned and one unresolved; pilot has one of each. Three later starts have not matured and stay out of the matured denominator. At first review pilot effort median is 35 minutes among observed rows only, not the whole cohort. One non-severe baseline defect is known; pilot defect follow-up is incomplete. A tiny sample, different mix and learning also limit inference. The fictional owner may authorize one two-week evidence-only extension with no new starts, at most four architect hours, two reviewer hours and EUR25 additional spend. If reconciliation cannot finish, stop rather than keep extending. Assume reconciliation finds a 40-minute median against 30 baseline for comparable work, with reviewers tracing extra effort to checking generated tests. This breaches the fictional no-increase burden guardrail even with nine accepted tasks. It is sufficient for a local stop decision, not statistical proof the intervention fails everywhere. Remove/reload and verify current-practice recovery; preserve evidence and useful test map/checklist. Return failure cases to the author. Retain would require different evidence: complete comparable outcomes and costs, acceptable quality/burden, agreed precision, independent acceptance and funded upkeep. A new revision must requalify. Critical unauthorized effects stop immediately, not at the scheduled review. The sample table and extension caps are speaker-reference detail, not the main strategy story. Use only the three visible decisions in the planned narration; expand into these numbers only if asked.",
+    "sources": [
+      "six-months-roadmap"
+    ],
+    "kind": "",
+    "section": "6 Months Roadmap",
+    "track": "main"
+  },
+  {
+    "id": "month-six",
+    "title": "Month six / An evidence portfolio, not a victory lap.",
+    "minutes": 1,
+    "body": "<div class=\"ledger\"><div><b>Visible change</b><b>Evidence to ask for</b></div><div><span>One workflow understood</span><span>Map + baseline + explicit gaps</span></div><div><span>Retained practice—or justified stop</span><span>Comparable outcomes + costs + limits</span></div><div><span>Less dependence on the architect</span><span>Owner + backup + recovery rehearsal</span></div></div><p class=\"small\">Proposed achievable picture. No guaranteed savings, headcount reduction or org-wide uplift.</p>",
+    "notes": "Commit to activities I can drive: discovery, agreement, hands-on support, reproducible evidence and clear decisions. Do not promise a positive effect outside my control. A realistic month-six organization has one bounded workflow learned from, transparent limitations, some reusable examples and an owner if anything is retained. A second willing team may have a new baseline, not a blanket rollout. If experiments stop, explain what was ruled out, what remains useful and why the next investment changes. Independent source-linked evidence, not a polished demo or attendance count, backs the picture.",
+    "sources": [
+      "six-months-target",
+      "six-months-roadmap"
+    ],
+    "kind": "",
+    "section": "6 Months Target",
+    "track": "main"
+  },
+  {
+    "id": "beyond",
+    "title": "Beyond 6 Months / Progress toward the Target.",
+    "minutes": 2,
+    "body": "<div class=\"choices\"><div><b>Deepen</b><p>Coaching, context or deterministic tooling where friction remains.</p></div><div><b>Transfer</b><p>Only with repeatable value, local fit and supported ownership.</p></div><div><b>Toward autonomy</b><p>Separate authority case, containment and human takeover.</p></div></div><p class=\"statement\">Established destination. Evidence-led steps.<br>Separate authority—not automatic graduation.</p>",
+    "notes": "The next quarter may deepen the existing workflow or stop expansion entirely. Skills remain optional; no catalog or central control platform is a prerequisite. Transfer needs new-scope baseline and local capacity. Consider bounded autonomy only if it solves an evidenced bottleneck and controls are proven: exact-artifact approvals, scoped identity, idempotency, audit, independent stop and takeover. People retain product, risk and release decisions. The long-term destination remains human-directed, guided and reviewed autonomous SDLC. These six months contribute toward that vision, not replace it; they do not promise its timing or authorize its execution. The CTO chooses investment based on the evidence, not an inevitable maturity staircase.",
+    "sources": [
+      "stage-02-autonomous-agent",
+      "target-operating-model",
+      "roadmap",
+      "six-months-target"
+    ],
+    "kind": "",
+    "section": "Beyond 6 Months",
+    "track": "main"
+  },
+  {
+    "id": "authority",
+    "title": "Toward autonomy / Change authority deliberately.",
+    "minutes": 2,
+    "body": "<div class=\"flow\"><span>Observe +<br>assemble evidence</span><i>→</i><span>Propose +<br>route work</span><i>⇢</i><span>Separately authorize<br>scoped execution</span></div><div class=\"rail\">Exact-artifact approval · scoped identity · audit + recovery</div><p class=\"statement\">Independent stop. Human takeover.</p><p class=\"small\">Readiness failure → hold or redesign. Missing evidence is never permission.</p>",
+    "notes": "Progress toward the established Target by granting only the extra operation that an evidenced business case needs. Reliable observation and evidence assembly come before proposing and routing; neither permits mutation, merge or deployment. A separate human decision names the exact resources, data, artifact and scope. Prove identity separation, checks outside candidate control, idempotency, duplicate/outage recovery and audit. Test a kill switch and human takeover outside the model before trusting scoped execution. The agent cannot appoint approvers or edit its own gates. Changed boundaries reopen review; harmful behavior revokes authority and feeds learning back to Quality and Maintenance. This is the bridge toward the autonomous Target, not an installed system or a dated commitment.",
+    "sources": [
+      "stage-02-autonomous-agent",
+      "target-operating-model"
+    ],
+    "kind": "",
+    "section": "Beyond 6 Months",
+    "track": "main"
+  },
+  {
+    "id": "alignment",
+    "title": "The first CTO conversation",
+    "minutes": 1,
+    "body": "<ol class=\"asks\"><li>Which outcome is worth improving first?</li><li>Who can volunteer time—and independent review?</li><li>What data, risk and effort limits apply?</li><li>When will we decide to continue or stop?</li></ol><p class=\"statement\">Sponsor the learning.<br>Do not pre-approve the answer.</p>",
+    "notes": "Close with concrete alignment, not a shopping list. Ask the CTO to agree an outcome, access to willing teams, independent review capacity, risk/data boundary and decision cadence. Agree success and stop criteria before collecting favorable anecdotes. The long-term Target and Roadmap establish the destination; the six-month plan is a realistic contribution toward it. We have covered the four assignment questions: action, measurement, realistic six-month evidence and conditional next investment. Transition to the fifteen-minute discussion. If time runs short, skip detail in narration rather than the decision and its limits.",
+    "sources": [
+      "PDF: questions 1–4",
+      "six-months-roadmap"
+    ],
+    "kind": "dark",
+    "section": "Discussion",
+    "track": "main"
+  },
+  {
+    "id": "discussion",
+    "title": "Q&A / What would change your mind?",
+    "minutes": 15,
+    "body": "<p class=\"subtitle\">15 minutes for the hard questions.</p><div class=\"discussion\"><p>No willing team?</p><p>Too little evidence?</p><p>A cheaper non-AI fix?</p></div><p class=\"small\">The proposed plan can change. The evidence standard should not.</p>",
+    "notes": "Reserve the full fifteen minutes. If no team volunteers, revisit the problem and sponsor trade-offs rather than conscript people. If evidence is sparse, narrow the question, explicitly authorize a bounded evidence-completion window or stop. If deterministic tooling is better, choose it. Discuss the company’s real constraints rather than pretend the fictional example estimates company benefit. The next slide provides linked sources for follow-up, not additional spoken content.",
+    "sources": [
+      "PDF: Format",
+      "six-months-target"
+    ],
+    "kind": "dark",
+    "section": "Discussion",
+    "track": "discussion"
+  },
+  {
+    "id": "references",
+    "title": "References / Follow the evidence.",
+    "minutes": 0,
+    "body": "<ul class=\"references\"><li>AI Architect Test Task · Eldorado.gg<br><span>Context, four questions, assumptions, 50-minute format</span></li><li><a href=\"../../strategy/target-operating-model/\">Long-term Target</a> · <a href=\"../../strategy/roadmap/\">Roadmap →</a></li><li><a href=\"../../strategy/six-months-target/\">6 Months Target →</a></li><li><a href=\"../../strategy/six-months-roadmap/\">6 Months Roadmap →</a></li><li><a href=\"../../strategy/six-months-roadmap/#exp-01-a-small-decision-ready-example\">EXP-01 packet and decision limits →</a></li><li><a href=\"../../strategy/measurement/\">Measurement definitions and safeguards →</a></li><li><a href=\"../../strategy/stage-02-autonomous-agent/\">Beyond 6 Months →</a></li></ul>",
+    "notes": "Appendix, zero planned talk time. The original assignment is the supplied AI_Architect_Test_Task.pdf. The source-reference map in this presentation directory records every slide against the PDF and reviewed Strategy. The deck does not reproduce the assignment file publicly. EXP-01 remains entirely fictional; its budget, medians, samples and outcomes are teaching devices. Official Reveal documentation consulted: installation, speaker-view and pdf-export on revealjs.com. All runtime assets are pinned and bundled locally.",
+    "sources": [
+      "PDF: complete assignment",
+      "six-months-target",
+      "six-months-roadmap",
+      "measurement",
+      "stage-02-autonomous-agent"
+    ],
+    "kind": "",
+    "section": "Reference",
+    "track": "appendix"
+  }
+];

presentations/less-prompting-more-shipping/target-figure.mjs

@@ -0,0 +1,25 @@
+// Presentation-sized views of the canonical topology, not a new operating model.
+export const phases=['scope','architecture','ui-ux','planning','delivery','uat','security','releases'];
+export const labels=['Scope','Architecture','UI/UX','Planning','Delivery','UAT','Security','Releases'];
+export const topology={
+ lifecycle:phases.map((id,i)=>[id,phases[(i+1)%phases.length]]),
+ governance:phases.map(id=>['agent',id]),
+ contributions:phases.map(id=>[`code-${id}`,id]),
+};
+function cycle(portrait){
+ const key=portrait?'phone':'wide';
+ const w=portrait?540:1096,h=portrait?540:350;
+ const xs=portrait?[100,270,440]:[200,548,896],ys=portrait?[65,270,475]:[40,175,310];
+ const pos=[[xs[1],ys[0]],[xs[2],ys[0]],[xs[2],ys[1]],[xs[2],ys[2]],[xs[1],ys[2]],[xs[0],ys[2]],[xs[0],ys[1]],[xs[0],ys[0]]];
+ const bw=portrait?154:202,bh=52,cx=xs[1],cy=ys[1],cw=portrait?164:270,ch=portrait?112:94;
+ const edge=(a,b)=>{const dx=b[0]-a[0],dy=b[1]-a[1],t=Math.min(dx?bw/2/Math.abs(dx):Infinity,dy?bh/2/Math.abs(dy):Infinity);return [a[0]+dx*t,a[1]+dy*t]};
+ const path=(d,type,from,to)=>`<path d="${d}" class="${type}" data-from="${from}" data-to="${to}" marker-end="url(#${key}-${type})"/>`;
+ let lines=pos.map((a,i)=>{const b=pos[(i+1)%8],p=edge(a,b),q=edge(b,a);return path(`M${p} L${q}`,'cycle-edge',...topology.lifecycle[i])}).join('');
+ // Top and bottom share a center exit; side spokes enter the side phases.
+ lines+=pos.map(([x,y],i)=>{let d;if(y<cy)d=`M${cx},${cy-ch/2} V${(cy-ch/2+y+bh/2)/2} H${x+(x<cx?30:x>cx?-30:0)} V${y+bh/2}`;else if(y>cy)d=`M${cx},${cy+ch/2} V${(cy+ch/2+y-bh/2)/2} H${x+(x<cx?30:x>cx?-30:0)} V${y-bh/2}`;else d=`M${cx+(x>cx?cw/2:-cw/2)},${cy} H${x+(x>cx?-bw/2:bw/2)}`;return path(d,'govern-edge',...topology.governance[i])}).join('');
+ const nodes=pos.map(([x,y],i)=>`<g data-node="${phases[i]}"><rect x="${x-bw/2}" y="${y-bh/2}" width="${bw}" height="${bh}"/><text x="${x}" y="${y+8}">${labels[i]}</text></g>`).join('');
+ const center=portrait?['Autonomous','agent','Human-controlled']:['Autonomous agent','Human-controlled'];
+ return `<svg class="target-cycle ${key}" viewBox="0 0 ${w} ${h}" role="img" aria-label="Intended SDLC: Scope, Architecture, UI/UX, Planning, Delivery, UAT, Security, Releases and back to Scope. One human-controlled autonomous agent executes and governs all eight phases."><defs>${['cycle-edge','govern-edge'].map(t=>`<marker id="${key}-${t}" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="5" markerHeight="5" orient="auto-start-reverse"><path d="M0 0 L10 5 L0 10z" fill="${t==='cycle-edge'?'#14131a':'#936500'}"/></marker>`).join('')}</defs>${lines}${nodes}<g data-node="agent" class="central"><rect x="${cx-cw/2}" y="${cy-ch/2}" width="${cw}" height="${ch}"/>${center.map((t,i)=>`<text x="${cx}" y="${cy-(center.length-1)*14+i*28+8}" class="${i===center.length-1?'control-label':''}">${t}</text>`).join('')}</g></svg>`;
+}
+export const cycleFigure=cycle(false)+cycle(true);
+export const contributionsFigure=`<div class="contribution-grid">${phases.map((id,i)=>`<div data-from="code-${id}" data-to="${id}"><span>AI Agent</span><i aria-label="contributes to">⇢</i><b>${labels[i]}</b></div>`).join('')}</div>`;

presentations/less-prompting-more-shipping/theme.css

@@ -0,0 +1,115 @@
+@font-face{font-family:Lato;src:url(./assets/lato-latin-400-normal.woff2) format('woff2');font-weight:400;font-display:swap}
+@font-face{font-family:Lato;src:url(./assets/lato-latin-700-normal.woff2) format('woff2');font-weight:700;font-display:swap}
+@font-face{font-family:Lato;src:url(./assets/lato-latin-900-normal.woff2) format('woff2');font-weight:900;font-display:swap}
+:root{--gold:#ffc950;--ink:#14131a;--paper:#f6f6f6}
+body{margin:0;background:var(--paper);color:var(--ink)}
+.deck{font:30px/1.35 Lato,sans-serif;color:var(--ink)}
+.deck .slides{text-align:left}
+.deck .slides section{box-sizing:border-box;padding:48px 52px;height:660px}
+.deck h1,.deck h2{font-weight:900;letter-spacing:-.045em;line-height:1.07;margin:18px 0 30px;color:inherit;text-transform:none}
+.deck h1{font-size:80px;max-width:960px}.deck h2{font-size:52px;max-width:1020px}
+.deck p{margin:20px 0}.deck .eyebrow{font-size:17px;letter-spacing:.15em;font-weight:900;color:#805b00;margin:0}
+.deck .subtitle{font-size:34px}.deck .thesis{font-size:37px;margin-top:52px;border-left:6px solid var(--gold);padding-left:24px}
+.deck .small{font-size:21px;line-height:1.4;color:#62616b;margin-top:24px}.deck .statement{font-size:35px;font-weight:700;margin-top:32px}
+.deck .dark{color:var(--paper)}.deck .dark .eyebrow,.deck .dark h1{color:var(--gold)}.deck .dark .small{color:#d5d4dc}
+.deck .facts{display:flex;gap:40px;justify-content:space-between;margin:35px 0}.deck .facts strong{display:block;font-size:43px;line-height:1.12}.deck .facts span{display:block;font-size:24px;margin-top:12px}
+.deck .contrast{display:grid;grid-template-columns:1fr 1fr;gap:44px;border-top:2px solid #dedee3;margin-top:28px;padding-top:8px}.deck .contrast p{font-size:27px;line-height:1.55}.deck .contrast b{color:#805b00;display:inline-block;margin-bottom:10px}
+.deck .flow{display:flex;align-items:stretch;gap:18px;margin:40px 0 26px}.deck .flow span{flex:1;border:2px solid #14131a;padding:24px 18px;font-weight:700;font-size:27px;text-align:center;display:flex;align-items:center;justify-content:center}.deck .flow i{align-self:center;font-style:normal}
+.deck .rail{border-left:6px solid var(--gold);padding:16px 24px;background:#e9e9ec;font-size:25px;font-weight:700}
+.deck .roles{display:grid;grid-template-columns:1fr 1.2fr 1fr;gap:18px;margin:32px 0}.deck .roles div{padding:24px;border:2px solid #14131a}.deck .roles b{display:block;font-size:34px;margin-bottom:18px}.deck .roles span{font-size:26px;line-height:1.5}.deck .roles .gold{background:var(--gold)}
+.deck .timeline{display:grid;grid-template-columns:1fr 1fr;gap:46px;margin:35px 0}.deck .timeline>div{border-top:8px solid var(--gold);padding-top:20px}.deck .timeline b{font-size:35px}.deck .timeline p{font-size:28px}.deck .timeline span{font-size:23px;color:#62616b}
+.deck .gate{background:var(--ink);color:var(--gold);font-size:29px;font-weight:900;padding:20px 24px}
+.deck .capacity{display:flex;margin:50px 0;gap:5px}.deck .capacity>div{flex:1;background:#e3e3e7;font-size:25px;padding:28px 16px;border-bottom:5px solid var(--ink)}.deck .capacity .pair{flex:2;background:var(--gold)}.deck .capacity b{display:block;margin-top:18px;font-size:24px}
+.deck .measure-list>div{display:grid;grid-template-columns:310px 1fr;gap:24px;border-top:1px solid #b8b7c0;padding:20px 0}.deck .measure-list b{font-size:32px}.deck .measure-list span{font-size:27px}.deck .measure-list{margin-bottom:24px}
+.deck .fiction{display:inline-block;background:#fff0cd;color:#594000;font-size:21px;padding:7px 12px;margin:0}
+.deck table{width:100%;border-collapse:collapse;margin:22px 0;font-size:25px}.deck th,.deck td{text-align:left;border-bottom:1px solid #b8b7c0;padding:15px 10px}.deck th{font-weight:900;font-size:23px;background:#e9e9ec}
+.deck .comparison{display:flex;align-items:center;gap:35px;margin:40px 0}.deck .comparison div{flex:1}.deck .comparison strong{display:block;font-size:80px;letter-spacing:-.05em}.deck .comparison span{font-size:23px}.deck .comparison .versus{font-size:50px}
+.deck .ledger{margin:40px 0}.deck .ledger>div{display:grid;grid-template-columns:1fr 1fr;gap:32px;padding:21px 0;border-bottom:1px solid #b8b7c0;font-size:27px}.deck .ledger b{color:#805b00}
+.deck .choices{display:grid;grid-template-columns:repeat(3,1fr);gap:28px;margin:40px 0}.deck .choices>div{border-top:6px solid var(--gold);padding-top:20px}.deck .choices b{font-size:33px}.deck .choices p{font-size:27px}
+.deck .asks{font-size:33px;line-height:1.6;margin:35px 0 0;padding-left:38px}.deck .asks li{padding-left:12px}
+.deck .discussion{display:flex;flex-direction:column;border-left:5px solid var(--gold);padding-left:28px;margin-top:40px}.deck .discussion p{font-size:36px;margin:10px 0}
+.deck a{color:#805b00;text-decoration:underline}.deck .references{font-size:27px;line-height:1.5;padding-left:28px}.deck .references li{margin:12px 0}.deck .references span{font-size:22px;color:#62616b}
+.deck .controls{color:#805b00}.deck .slide-number{font:16px Lato,sans-serif;background:#14131a;color:#fff;left:18px;right:auto;bottom:18px;padding:8px}
+.deck .progress{color:#805b00;height:4px}
+.toolbar{position:fixed;z-index:30;top:0;left:0;right:0;display:flex;align-items:center;gap:16px;background:#101014;color:#fff;padding:8px 18px;font:14px Lato,sans-serif;min-height:32px;box-sizing:content-box}
+.toolbar a{color:var(--gold)}.toolbar button{font:inherit;color:white;border:1px solid #62616b;background:transparent;padding:6px 10px;cursor:pointer}.toolbar .help{margin-left:auto}
+a:focus-visible,button:focus-visible{outline:3px solid #b88719;outline-offset:3px}
+.reveal.deck{height:calc(100dvh - 48px);top:48px}
+@media(max-width:600px){.toolbar{gap:9px;font-size:12px;padding:8px}.toolbar .help{display:none}.toolbar button{padding:6px}.deck .controls{bottom:18px}}
+@media(max-width:360px){.toolbar{gap:4px}}
+/* Portrait is re-composed, not a postage-stamp landscape slide. */
+.portrait .deck .slides section{height:1000px;padding:28px}
+.portrait .deck h1{font-size:64px}.portrait .deck h2{font-size:43px;margin-bottom:24px}
+.portrait .deck .facts{flex-wrap:wrap;gap:28px;margin:30px 0}.portrait .deck .facts strong{font-size:38px}
+.portrait .deck .contrast{grid-template-columns:1fr;gap:0;margin-top:20px}.portrait .deck .contrast p{font-size:27px;margin:14px 0;line-height:1.4}
+.portrait .deck .flow{flex-direction:column;gap:8px;margin:24px 0}.portrait .deck .flow span{padding:14px;font-size:27px}.portrait .deck .flow i{transform:rotate(90deg);line-height:1}
+.portrait .deck .roles{grid-template-columns:1fr;gap:12px}.portrait .deck .roles div{padding:18px}.portrait .deck .roles b{font-size:30px;margin-bottom:8px}.portrait .deck .roles span{font-size:26px}
+.portrait .deck .timeline{grid-template-columns:1fr;gap:24px;margin:25px 0}.portrait .deck .timeline>div{padding-top:14px}.portrait .deck .timeline p{margin:14px 0;font-size:28px}
+.portrait .deck .statement{font-size:33px;margin-top:28px}.portrait .deck .rail{font-size:25px;padding:16px}.portrait .deck .gate{font-size:27px;padding:18px}
+.portrait .deck .capacity{display:grid;grid-template-columns:1fr 1fr;gap:8px}.portrait .deck .capacity>div{padding:24px 16px}
+.portrait .deck .measure-list>div{grid-template-columns:1fr;gap:10px}.portrait .deck .measure-list b{font-size:31px}
+.portrait .deck .fiction{font-size:22px}.portrait .deck table{font-size:23px;table-layout:fixed}.portrait .deck th{font-size:22px}.portrait .deck th,.portrait .deck td{padding:15px 8px}
+.portrait .deck .comparison{gap:20px}.portrait .deck .comparison strong{font-size:54px}.portrait .deck .comparison span{font-size:24px}
+.portrait .deck .ledger>div{font-size:26px;gap:20px}.portrait .deck .choices{grid-template-columns:1fr;gap:20px}.portrait .deck .choices>div{padding-top:12px}.portrait .deck .choices p{margin:10px 0}
+.portrait .deck .asks{font-size:31px;line-height:1.45}.portrait .deck .asks li{margin:22px 0}.portrait .deck .small{font-size:24px}
+.portrait #qualification .contrast{grid-template-columns:1fr 1fr;gap:24px}.portrait #qualification .contrast p{font-size:24px}
+.portrait .deck .references{font-size:29px}.portrait .deck .references li{margin:22px 0}
+@media(prefers-reduced-motion:reduce){*{transition:none!important;animation:none!important}}
+.embedded .toolbar{display:none}
+.embedded .reveal.deck{top:0;height:calc(100dvh - 48px)}
+.embedded body{background:#101014}
+.embedded .deck .controls{position:fixed;bottom:8px;color:var(--gold)!important}
+.embedded .deck .progress{color:var(--gold)}
+.embedded .deck .slide-number{position:fixed;bottom:12px}
+.embedded .deck .progress{position:fixed;bottom:0}
+@media print{.toolbar{display:none}.reveal.deck{top:0;height:100%}}
+html.print-pdf .toolbar{display:none}html.print-pdf .reveal.deck{top:0;height:100%}
+
+/* Distinct strategy views: paired topology, progression and learning loop. */
+.deck .target-cycle{width:100%;height:350px;display:block;margin:0 auto}
+.deck .target-cycle.phone{display:none}
+.target-cycle rect{fill:#f6f6f6;stroke:#14131a;stroke-width:2}
+.target-cycle text{text-anchor:middle;font:700 24px Lato,sans-serif;fill:#14131a}
+.target-cycle .central rect{fill:#ffc950}
+.target-cycle .control-label{font-size:20px;font-weight:400}
+.target-cycle .cycle-edge{fill:none;stroke:#14131a;stroke-width:2.5}
+.target-cycle .govern-edge{fill:none;stroke:#936500;stroke-width:2.5;stroke-dasharray:3 5}
+.deck .diagram-legend{font-size:23px;margin:12px 0}
+.deck #target .small{font-size:21px;margin:12px 0}
+.deck .diagram-intro{font-size:30px}
+.deck .contribution-grid{display:grid;grid-template-columns:repeat(4,1fr);gap:12px 20px;margin:22px 0}
+.deck .contribution-grid>div{border-top:4px solid #ffc950;padding:10px 8px;display:flex;flex-direction:column;align-items:center;font-size:26px}
+.deck .contribution-grid i{font-style:normal;transform:rotate(90deg);color:#805b00;font-size:32px;line-height:1.2}
+.deck .journey{display:flex;gap:16px;align-items:center;margin:36px 0}
+.deck .journey>div{flex:1;border-top:6px solid #ffc950;padding:18px 6px;align-self:stretch}
+.deck .journey small,.deck .horizon small{display:block;font-size:17px;color:#805b00;font-weight:900;letter-spacing:.04em;margin-bottom:14px}
+.deck .journey b{font-size:31px;display:block;margin-bottom:20px}
+.deck .journey span{font-size:25px}.deck .journey i{font-style:normal}
+.deck .learning-loop{display:grid;grid-template-columns:1fr 28px 1fr 28px 1fr 28px 1fr;align-items:center;gap:0 8px;margin:22px 0}
+.deck #learning-loop .statement{margin:16px 0 0}.deck #learning-loop .small{margin-top:12px}
+.deck .learning-loop span{border:2px solid #14131a;padding:8px;font-size:27px;text-align:center}
+.deck .learning-loop i{font-style:normal;text-align:center;line-height:1}
+.deck .learning-loop>:nth-child(1){grid-area:1/1}.deck .learning-loop>:nth-child(2){grid-area:1/2}.deck .learning-loop>:nth-child(3){grid-area:1/3}
+.deck .learning-loop>:nth-child(4){grid-area:2/3}
+.deck .learning-loop>:nth-child(5){grid-area:3/3}.deck .learning-loop>:nth-child(6){grid-area:3/4}.deck .learning-loop>:nth-child(7){grid-area:3/5}
+.deck .learning-loop>:nth-child(8){grid-area:4/5}
+.deck .learning-loop>:nth-child(9){grid-area:5/5}.deck .learning-loop>:nth-child(10){grid-area:5/6}.deck .learning-loop>:nth-child(11){grid-area:5/7}
+.deck .horizon{margin:35px 0;border-left:5px solid #ffc950;padding-left:25px}
+.deck .horizon b{font-size:32px;display:block}.deck .horizon .near{background:#e9e9ec;padding:22px;margin-top:28px}
+.deck .horizon span{display:block;font-size:25px;margin-top:14px}
+.portrait .deck .target-cycle.wide{display:none}.portrait .deck .target-cycle.phone{display:block;height:540px}
+.portrait .deck #target h2{font-size:40px}
+.portrait .deck #target .small{font-size:24px;margin-top:20px}
+.portrait .deck #contributors .small{margin:12px 0}
+.portrait .deck #contributors .contribution-grid{gap:6px;margin:14px 0}
+.portrait .deck #contributors .contribution-grid>div{padding:4px 8px}
+.portrait .deck .contribution-grid{grid-template-columns:1fr 1fr;gap:12px;margin:24px 0}
+.portrait .deck .contribution-grid>div{padding:8px;flex-direction:column;justify-content:center;gap:0;font-size:27px}
+.portrait .deck .contribution-grid i{transform:rotate(90deg)}.portrait .deck .contribution-grid b{text-align:center}
+.portrait .deck .journey{flex-direction:column;gap:4px;margin:18px 0}
+.portrait .deck .journey>div{width:100%;padding:12px 0;border-top-width:4px}
+.portrait .deck .journey b{font-size:29px;margin-bottom:8px}.portrait .deck .journey small{margin-bottom:8px}
+.portrait .deck .journey i{transform:rotate(90deg);line-height:1}
+.portrait .deck .learning-loop{grid-template-columns:1fr 16px 1fr 16px 1fr 16px 1fr;gap:0 3px;margin:30px 0}
+.portrait .deck .learning-loop span{font-size:24px;padding:14px 2px}
+.portrait .deck .horizon b{font-size:32px}

research/ai-adoption/assignment-evidence.json

@@ -0,0 +1,169 @@
+{
+  "source": {
+    "file": "AI_Architect_Test_Task.pdf",
+    "sha256": "12b2406766996056d0a361cf76b2d8fbe4dfdfad6a16c2cc4d5ee03a51a384a5",
+    "attachment_message": "1557767519748759646",
+    "authorization_message": "1557786954383368264",
+    "read_scope": "Full PDF, Format, Context and all four assignment questions, plus assumptions instruction"
+  },
+  "requirements": [
+    {
+      "id": "format",
+      "source_section": "Format",
+      "requirement": "Live presentation: 50 minutes including Q&A; content over polish",
+      "pages": [
+        "six-months-target"
+      ],
+      "markers": [
+        "35 minutes content + 15 minutes Q&A",
+        "Content matters more than visual polish"
+      ]
+    },
+    {
+      "id": "context",
+      "source_section": "Context",
+      "requirement": "Close to 80 engineering people, around 100 by year end, more than 10 teams; every developer already uses AI unevenly; real output not usage",
+      "pages": [
+        "six-months-target",
+        "baseline"
+      ],
+      "markers": [
+        "80 engineers",
+        "100 by year end",
+        "more than 10 teams",
+        "current AI-assisted practice"
+      ]
+    },
+    {
+      "id": "q1",
+      "source_section": "Assignment 1",
+      "requirement": "Month 1–6 concrete priorities and change starting solo, CTO reporting, no formal team authority",
+      "pages": [
+        "six-months-roadmap",
+        "six-months-target"
+      ],
+      "markers": [
+        "Month 1",
+        "Month 2",
+        "Month 3",
+        "Month 4",
+        "Month 5",
+        "Month 6",
+        "One active live pilot at a time",
+        "no formal authority",
+        "monthly CTO review"
+      ]
+    },
+    {
+      "id": "q2",
+      "source_section": "Assignment 2",
+      "requirement": "Know whether engineering output improves; track meaningful measures and explain misleading signals",
+      "pages": [
+        "measurement/index",
+        "six-months-roadmap",
+        "baseline"
+      ],
+      "markers": [
+        "Review/rework minutes",
+        "Escaped defects and severity",
+        "Where this misleads",
+        "task mix",
+        "not a causal ROI claim",
+        "source",
+        "uncertainty"
+      ]
+    },
+    {
+      "id": "q3",
+      "source_section": "Assignment 3",
+      "requirement": "Realistic visible month-six changes backed by evidence",
+      "pages": [
+        "six-months-target",
+        "six-months-roadmap"
+      ],
+      "markers": [
+        "Activities I commit",
+        "Contingent visible outcome",
+        "one partner team",
+        "matured defect follow-up",
+        "documented stop"
+      ]
+    },
+    {
+      "id": "q4",
+      "source_section": "Assignment 4",
+      "requirement": "Role and organization AI use beyond six months",
+      "pages": [
+        "stage-02-autonomous-agent",
+        "six-months-target"
+      ],
+      "markers": [
+        "dedicated enablement capacity",
+        "deterministic tooling",
+        "long-term strategy vision",
+        "not automatic progression"
+      ]
+    },
+    {
+      "id": "assumptions",
+      "source_section": "Final instruction",
+      "requirement": "State assumptions where stack, tooling or processes are unknown",
+      "pages": [
+        "six-months-target"
+      ],
+      "markers": [
+        "Assumptions register",
+        "PDF fact",
+        "Unknown:",
+        "Hypothesis:",
+        "If false"
+      ]
+    },
+    {
+      "id": "F1",
+      "source_section": "Professional audit F1",
+      "requirement": "First-revision comparator and recovery without invented prior approved bundle",
+      "pages": [
+        "skills-quality",
+        "skills-governance",
+        "skills-maintenance"
+      ],
+      "markers": [
+        "first-revision",
+        "N/A",
+        "pinned clean",
+        "independent"
+      ]
+    },
+    {
+      "id": "F2-F3",
+      "source_section": "Professional audit F2/F3",
+      "requirement": "Coherent illustrative packet, inconclusive bounded extension/stop, effort and value",
+      "pages": [
+        "six-months-roadmap",
+        "skills-quality"
+      ],
+      "markers": [
+        "EXP-01",
+        "Entirely fictional",
+        "Inconclusive at first review",
+        "one two-week evidence-completion extension",
+        "Conclusive stop on burden",
+        "one-off setup",
+        "optional reference designs"
+      ]
+    }
+  ],
+  "verification_sources": [
+    "scripts/assignment.test.mjs",
+    "scripts/connected-strategy.test.mjs",
+    "scripts/strategy-navigation.test.mjs",
+    "scripts/strategy-story.test.mjs",
+    "scripts/verify.mjs",
+    "scripts/browser/skills-stories.cjs",
+    "scripts/browser/strategy-navigation.cjs",
+    "scripts/browser/target-midpoints.cjs",
+    "scripts/browser/roadmap-timeline.cjs"
+  ],
+  "scope": "Traceability is a review aid, not semantic approval or business evidence. All 30 routes remain in strategy-coverage.json; all 16 canonical contracts retain original checksums, 9 prototypes and 7 unimplemented. Reviewer must cold-read the actual pages and inspect complete exports."
+}

research/ai-adoption/findings.md

@@ -0,0 +1,229 @@
+# Eldorado AI adoption — research handoff
+
+Research only. Retrieved 4 October 2026 UTC. This document separates documented vendor capability, empirical evidence, and recommendations. Nothing here certifies an Eldorado rollout, installed client, enabled telemetry, staffing appointment, measured baseline, or realized productivity improvement. Sources and literal supporting passages are in `sources.json`; fetched text, retrieval outcomes and citation ledger are retained alongside it.
+
+## 1. Local organizational baseline and scope
+
+Read-only remote fetch and status inspection found a clean documentation checkout on `main`, with HEAD and `origin/main` both `14ba1aa1ef66c91525135f743d15c77e32db78d3`. Inspected all three current Organization pages: `structure.mdx`, `collaboration.mdx`, `sdlc.mdx`, plus channel wiki `/opt/data/wiki/channels/1555510466904727622.md`. This is documentation evidence, not independent verification of actual personnel, systems, or deployed controls. No repository file was changed.
+
+Preserve the existing structure:
+
+- Product: Product Management and Product Design.
+- Technology: Product Engineering, Platform & IT, Architecture & Security, Quality Engineering, Data & AI.
+- Operations: Operations Squad; Marketing: Marketing Squad; Finance & Accounting: Finance & Accounting Squad; HR & Administration: People & Administration Squad.
+- Existing leadership documentation locates AI enablement coordination with the AI Architect within Data & AI, alongside established engineering leadership. Do not invent a new AI department, standing committee, delivery team, or confirmed headcount.
+
+The requested target is ONE logical SDLC coordinating agent, with people using local Copilot, Claude Code or Cline agents. Logical coordination does not require a single fragile process and does not transfer human accountability to a model. The recommendations below develop this target; they are not a description of present operations.
+
+## 2. Principal conclusions
+
+1. Standardize a portable skill content contract, not the fiction of one universal client policy. Agent Skills defines `SKILL.md`, metadata and resources; `allowed-tools` is experimental, and the discovery directory is not mandated by the format.[1][21]
+2. Treat instructions as guidance. GitHub explicitly warns of nondeterministic instruction following, and Claude describes memory files as context rather than enforced configuration.[3][5] Recommended enforcement belongs in independently administered repository, CI, artifact and release controls.
+3. Maintain client-specific adapters and an explicit supported version matrix. Current official docs disagree even about collision precedence: Claude enterprise > personal > project; Cline global skill > project skill; Cline rules use the opposite workspace-over-global rule.[4][8][9]
+4. Assess skill selection, execution, artifact quality and business outcomes separately. Repeated trials and environment-state verification matter more than an agent reporting success.[11]
+5. Measure a balanced portfolio of flow, quality, risk, cost and human experience. DORA now uses five delivery metrics; SPACE explicitly rejects a single productivity metric.[12][24] Adoption counts or accepted code are not causal productivity evidence.
+6. Use comparative pilots, not an imported percentage ROI. Controlled studies have reported substantial speedups and slowdowns in different settings, and METR's newer study explains why selection and concurrent-agent timing make current effects difficult to estimate.[16][17][22]
+
+## 3. Compatibility and enforcement matrix
+
+Every capability below is documented upstream, not exercised in Eldorado. A supported client means a particular host, version, model configuration and OS combination that passes local conformance tests; a product brand alone is insufficient.
+
+| Dimension | GitHub Copilot | Claude Code | Cline |
+| --- | --- | --- | --- |
+| Skills and scope | Project `.github/skills`, `.claude/skills`, `.agents/skills`; personal `~/.copilot/skills`, `~/.agents/skills`. About page includes cloud agent, code review, CLI, app, VS Code and JetBrains agent mode.[2] | Common format plus invocation controls, subagents and dynamic context extensions. Native project/personal `.claude/skills`; enterprise and nested scopes also documented.[4] | Workspace `.cline/skills`, global `~/.cline/skills`; explicit invocation and enabled-by-default toggles documented.[8] |
+| Always-on instructions | Repository-wide `.github/copilot-instructions.md`, path-specific files and agent instructions have surface-dependent support. Do not apply the GitHub.com hierarchy to every IDE.[3] | `CLAUDE.md` and related discovered memory files are concatenated into context, not overriding configuration files.[5] | Workspace/global rules combine, with workspace taking precedence for conflicts; toggles may disable rules.[9] |
+| Name collision / precedence | Inspected docs establish instruction precedence on GitHub.com, not a universal skill-name collision order. Test duplicate personal/project skills before approval.[3] | Enterprise skill over personal over project for same-name collisions; distinct from memory-file concatenation.[4][5] | Global skill over project skill, but workspace rules over global rules. Do not conflate them.[8][9] |
+| Trust and execution | GitHub warns shared skills are not verified, may contain injection or malicious scripts, and shell preapproval can remove a protective confirmation.[26] | Trust/permission dialogs and sandbox capability exist, but approved shell access can exceed working directory; unattended sessions differ.[7] | User toggles do not establish an enterprise security boundary. Current hook landing page redirects to SDK plugin documentation, which describes executable plugins.[8][10][23] |
+| Hooks and enforcement | No universal Copilot hook parity established by inspected sources. Do not promise a portable hook API or use absence of research as proof none exists. | PreToolUse supports blocking, but command/http/MCP timeout does NOT block automatically; plain exit 1 is generally nonblocking without valid decision JSON. Agent SDK callbacks differ.[6] | SDK documents lifecycle hooks and explicit `fail_closed` policy. This is not proof every IDE/CLI installation exposes identical configuration or failure semantics.[23] |
+| Distribution | Repository content can travel with code. `gh skill` public preview documents installation, source provenance, `@SHA` and `--pin`; pinned skills are skipped in updates.[26] | Repository/managed deployment plus client-specific facilities. Use an external immutable bundle manifest; do not presume Copilot's installer or plugin semantics apply unchanged.[4] | Commit workspace skill directories for team sharing. SDK plugins can come from npm/git/file sources; these require separate software-supply-chain review.[8][23] |
+| Telemetry | Usage API spans multiple surfaces, but rich IDE detail requires telemetry; server-side active-user recovery does not fill missing dimensional data.[19] | OTel supports configured usage/cost/tool export; detailed skill names/tool arguments require explicit collection settings. Version-specific behavior is substantial.[20] | SDK lifecycle hooks provide instrumentation building blocks, not proof of a ready-made comparable enterprise skill dashboard or retention contract.[23] |
+| Portable guarantee | Readable common content only; neither skill selection nor correct execution follows from installation.[3][26] | Shared format does not standardize extension behavior or guarantee instruction adherence.[4][5] | Shared content and client behavior remain different; toggles and name shadowing affect what executes.[8][9] |
+
+### Version pinning, updates, rollback and stale laptops — recommended operational contract
+
+These are recommended design choices, not features claimed to exist universally:
+
+- Maintain one reviewed registry with stable skill IDs, human owner/reviewer, purpose, risk tier, provenance/license, immutable source revision, artifact digest, dependencies, supported client/OS/version range, evaluation revision/results, approval record, last review date, deprecation state, migration guide and rollback digest. Keep client-specific invocation and tool configuration outside the portable core, generated and tested as adapters.
+- Release a manifest mapping stable IDs to exact immutable content and adapter revisions. Pin full commit/digest, not a mutable branch or tag alone. GitHub's preview installer provides pin/provenance mechanisms, but private Gitea compatibility and availability on Eldorado laptops have not been established.[26] A controlled vendored bundle is the simpler cross-client recommendation until proven otherwise.
+- Promotion: author branch → independent review → format/resource validation → script/dependency/security checks → per-client behavioral and adversarial evals → canary → approval → distribution. Never permit a proposed skill to approve itself or edit its own promotion checks without independent review.
+- Updates: compare signed/verified manifest and content digest; show release notes; stage atomically; restart/reload affected sessions where required by the client. Test whether already-open sessions retain old instructions. Do not infer reload from files changing.
+- Rollback: restore a previously approved manifest AND adapter/dependency versions, revoke the unsafe revision centrally, expire affected sessions, rerun a smoke test and read back effective version. Reverting a file does not undo commands already executed or leaked data.
+- Offline laptop: a verified cached bundle can support permitted low-risk local drafting, provided required local model/tool dependencies actually work offline. Local files being present do not mean cloud-backed inference is offline-capable. No claim of native offline inference or guaranteed durable telemetry buffering is made for any client.
+- Stale/unsupported bundle: show a visible warning and prevent high-risk centrally mediated actions; allow explicitly approved low-risk work only. Recommended grace periods are risk decisions to settle, not fabricated vendor defaults. On reconnect, revalidate revocation and support status before obtaining privileged credentials or submitting gated delivery actions.
+- Laptop evidence is fallible and may be altered by its owner. CI should verify repository-delivered manifest/content and actual output, but cannot prove which private prompt or skill a laptop truly used. Treat client attestations as advisory unless an independently verified device/runtime trust mechanism exists. Central enforcement must still protect work with no attestation.
+- Avoid conflicting names and broad user-directory installation; prefix governed IDs and detect shadowing. Keep an explicit exception route with owner, scope, justification, expiry and compensating checks. An exception must not quietly disable protected-release controls.
+
+## 4. Conflicts, weak evidence and what not to conclude
+
+| Claim / conflict | Classification and resolution |
+| --- | --- |
+| “Project skills universally override user skills.” | Contradicted as a universal claim. Agent Skills implementation guide says this; current Claude and Cline product docs specify personal/global priority for skill collisions. Weight actual client documentation for that client, then verify behavior locally.[21][4][8] |
+| “GitHub organization instructions enforce company policy everywhere.” | Unsupported. GitHub documents limited surfaces, personal/repository precedence, nondeterminism and head-branch review instructions. Use repository ownership and independently protected gates instead.[3] |
+| “All clients support the same skills/hooks/telemetry.” | Unsupported. Standard content exists, but scope, extensions, hooks and instrumentation differ. Cline's hook page now points to SDK plugins; do not repeat historical hook file recipes without version testing.[1][10][23] |
+| “Copilot supports JetBrains skills.” | About-skills page explicitly includes JetBrains; adding-skills overview currently omits it. This is documentation asymmetry, not sufficient evidence to declare unsupported. Verify the exact target host/version during adapter qualification.[2][26] |
+| “Hook failure blocks dangerous work.” | Not generically true. Claude documents nonblocking timeout and exit-code cases; Cline SDK offers an explicit fail-closed setting. Test timeout, crash and malformed output separately.[6][23] |
+| “AI makes developers 55.8% faster.” | Supported paraphrase only for Peng et al.'s controlled JavaScript HTTP-server task; abstract inspected. Not a software-organization forecast.[17] |
+| “AI makes experienced developers 19% slower today.” | Misleading temporal/generalized claim. METR's early-2025 RCT involved 16 developers and 246 issues; the authors now label those results outdated as current capability evidence.[16] |
+| “METR's newer results prove a universal speedup.” | Unsupported. Follow-up raw estimates suggest shorter task time, but intervals include no effect and authors warn participant/task selection and parallel-agent timing compromise the estimate.[22] |
+| “Independent study proves a 21% Eldorado improvement.” | Unsupported. Paradis et al.'s abstract reports approximately 21% shorter task time for 96 Google engineers, with a large interval and explicit ecosystem/generalization caveats. Primary abstract, not full methods, inspected.[18] |
+| “Agent says done / skill was loaded, therefore compliant.” | Unsupported. Outcome must be inspected in the environment; selection, reading, following, tool execution and outcome are separate observations.[11] |
+
+Research hygiene correction: the initial URL seed for arXiv `2410.12944` was mistakenly labelled as a Cui field-experiments source. The retrieved body is Paradis et al.'s Google RCT; `sources.json` records the correct identity. No Cui statistic is used. Likewise, ACM SPACE returned HTTP 403; an author-hosted Microsoft Research publication summary was retrieved instead. These are bounded acquisition limitations, not invented evidence.
+
+## 5. Target coordination, authority and organization mapping
+
+Recommended trust flow: people and approved work records → one logical SDLC coordinator → task-scoped local-agent work proposals → repository review → independently administered CI/artifact evidence → authorized human release decision → release service. The coordinator should maintain workflow state, dependencies, requested evidence, retries and escalation. It should not be sole author, evaluator and approver, nor hold unrestricted production credentials.
+
+Use durable IDs, idempotent task transitions and bounded retry budgets so multiple coordinator replicas cannot publish twice. Keep a human takeover and deterministic queue/authorization path if inference is unavailable. Project-level context sharing must be deliberately scoped; shared coordination is not permission to mix secrets, HR records, customer disputes and source code.
+
+| Existing owner | Recommended accountability, without creating teams |
+| --- | --- |
+| Product Management | Choose outcome hypotheses and eligible work; accept product value and prioritize pilots rather than maximize AI usage. |
+| Product Design | Validate usability/accessibility and customer research handling; review generated experience changes and design-task skills. |
+| Product Engineering | Own code, practical skill authoring and local-agent use; review generated changes and remain responsible for maintainability. |
+| Platform & IT | Own bundle delivery, device/client support, identity, workload isolation, central CI/release integration, telemetry transport and emergency revocation. |
+| Architecture & Security | Own trust boundaries, data/permission risk classification, supply-chain approval requirements and security exceptions; review privileged skill proposals. |
+| Quality Engineering | Own independent regression/adversarial suites, quality rubrics, gate evidence, failure sampling and evaluation reproducibility. |
+| Data & AI | Coordinate the skills catalog and logical SDLC-agent evaluation with the documented AI Architect function; own statistical analysis and model/client experiment design. |
+| Operations Squad | Supply sanitized service cases and operational acceptance; own human decisions on disputes, refunds, fraud and customer communications, not the coordinator. |
+| Marketing Squad | Own brand/claim review, campaign approval and content rights; start with drafting/review skills rather than autonomous spending or publication. |
+| Finance & Accounting Squad | Validate cost allocation and investment evidence; retain payout, accounting and financial approval segregation. |
+| People & Administration Squad | Own training, onboarding, acceptable use and privacy-sensitive adoption feedback, with Platform & IT on access lifecycle; no individual developer ranking. |
+
+Department leaders retain business accountability. Staffing capacity, named approvers and deputies need human confirmation; the operating-model role description is not evidence that every position is filled. For synthesis, map recommendations to existing responsibilities rather than publish uncertain staffing as fact.
+
+### Threat and failure controls
+
+NIST supplies a voluntary lifecycle governance framework and GenAI companion, not certification; the RMF core organizes work around govern, map, measure and manage.[13][14][25]
+
+OWASP identifies external-content injection and recommends least privilege, human approval and adversarial testing.[15]
+
+Recommended controls by failure mode:
+
+- Malicious skill, script, dependency, MCP server or changed upstream tag: allowlisted source, immutable digest, independent review, license/provenance inventory, restricted network/runtime and no automatic arbitrary installs. A reviewed Markdown file does not make referenced executable code safe.
+- Prompt injection from issues, repository instructions, web pages or tool results: treat as untrusted input; separate data from authority; limit credentials and egress; require independent authorization. GitHub code review's use of PR-head instructions is a concrete reason not to trust AI review as the sole gate.[3][15]
+- Fabricated success, omitted tests, cherry-picked evidence or judge manipulation: verify actual artifact/CI state tied to exact commit and policy revision; keep evaluation checks outside candidate-controlled changes; sample human review.
+- Overbroad local shell permissions: isolate process/OS identity, filesystem, network and secrets. A profile, skill folder or current directory is not containment. Claude's own docs distinguish permission prompts from sandbox controls.[7]
+- Duplicate or looping agent work, runaway spend and unavailable coordinator: task idempotency, bounded retries/time/cost, lease expiry, human recovery and read-only/degraded mode. Never downgrade a release gate because the model or evidence service is unavailable.
+- Model/client/context drift or stale session instructions: version-qualified adapters; requalification on material updates; compaction/long-session tests; version-aware incident analysis.
+- Privacy leakage through telemetry or shared memory: minimal structured events, pseudonymous IDs, restricted retention and access; no raw prompts, secrets or source contents by default. Explicitly review the privacy cost before enabling detailed tool/skill-name export.[20]
+- Kill switch: independently revoke mutation/release credentials and stop scheduling; disable affected revisions and preserve evidence. Sending “stop” to a model is not the security boundary.
+
+## 6. Skill quality, evaluation and lifecycle recommendations
+
+A useful skill must state when to use it, when not to use it, prerequisites, exact steps, expected artifacts, verification, failure handling and escalation. Keep the portable body small and reference bounded resources. The format specification supports progressive disclosure and recommends concise main files.[1]
+
+Proposed evaluation layers:
+
+1. Static contract: parse metadata; verify stable identity/owner/review date; validate links and resource paths; detect embedded secrets, prohibited dependencies, unsafe commands and unsupported client-only fields.
+2. Selection tests: positive trigger tasks, near misses and negative tasks; report false activation and missed activation separately. A larger catalog should be tested for routing regressions, not presumed better.
+3. Execution tests: run representative sanitized tasks in disposable environments with fixed starting repositories; verify real outputs, not self-reports. Include missing prerequisite, invalid input, tool timeout, denied permission, malformed evidence and interrupted session.
+4. Safety tests: injected repository text, malicious referenced scripts, conflicting global/project skills, user toggle, unsupported version, expired/revoked bundle, offline network, context compaction and stale in-memory version.
+5. Outcome grading: deterministic tests for mechanically checkable constraints; independent human review for product/design/maintainability; model judges only with explicit rubric and human calibration. Record disagreements and judge version.[11]
+6. Comparison: same tasks and conditions for no-skill/current-approved/candidate versions; repeated trials, failure/abandonment retained; separate client/model/skill changes. Report sample size, variability, confidence and task mix, not only a mean pass percentage.[11]
+
+Recommended promotion policy: all mandatory deterministic safety/authorization checks must pass; any observed critical unauthorized action blocks promotion pending investigation. This is a proposed policy, NOT proof of zero residual risk. Quantitative success-rate thresholds should be set after pilot variance and business impact are known, by risk tier; do not invent universally validated percentages. Privileged release/payment/customer-impact workflows need stronger review than read-only documentation assistance.
+
+Lifecycle: proposed → experimental → approved → deprecated → retired, with quarantine available from every active state. Review triggered by incident, tool/model/client change, dependency change, usage feedback or scheduled owner review. Each approved skill needs an owner and backup, change history, support window, migration route and known-good rollback. Deprecation should warn, offer replacement and track consumers before retirement; urgent security revocation overrides convenience. Do not retain unowned skills merely because they remain popular.
+
+Adoption should begin with training on how to inspect results, report failures and refuse unsafe requests. Build examples from actual team workflows; offer office hours and opt-in feedback; record why a skill was rejected. Measure whether people can perform and verify work, not whether they obey a target number of invocations. Avoid automatically promoting agent-written corrections into the governed catalog.
+
+## 7. KPI instrumentation options and recommended choices
+
+### Practical source tiers
+
+A. Start with authoritative repository/CI/deployment/incident events. These can measure delivery outcomes without observing every laptop prompt. No event feed has been inspected here; feasibility must be verified with the current hosting platforms and retention.
+
+B. Add a governed catalog/version inventory and opt-in task-level skill/client declarations. This supplies adoption and support coverage, but declarations are not proof of execution or adherence.
+
+C. Add client adapters where supported: Copilot usage APIs and Claude OTel may help; their fields, licensing, enabled state and missingness differ.[19][20] Cline SDK hooks are an instrumentation option requiring engineering and exact-version qualification, not a proven universal collector.[23]
+
+D. Use short anonymous surveys, work sampling and pilot comparisons for cognitive load, confidence and rework not visible in logs. SPACE's multidimensional premise supports this combination; surveys alone cannot establish time saved.[24][16]
+
+### Candidate measurement contracts for synthesis
+
+These are recommended options, not observed metrics or approved targets. All denominators must use a predeclared eligible population and reporting window; zero denominators produce “not available,” never zero performance.
+
+| Measure | Definition and useful source | Owner / interpretation / missingness |
+| --- | --- | --- |
+| Validated task success | Independently accepted successful tasks / all eligible initiated tasks with matured observation window; count failed/abandoned tasks as nonsuccess and show still-open separately. Task ID + acceptance evidence, not agent message. | Quality Engineering; weekly pilot report. Show task type, sample size and unobserved outcomes separately; exclude cancelled-before-start work by stated rule, not post-hoc cherry-picking. |
+| Skill selection precision / recall | Correct relevant activations / all activations; relevant tasks with activation / all relevant tasks, on a labeled evaluation set. | Data & AI with Quality Engineering; per candidate/client release. Not obtainable from skill-loaded logs without relevance labels. |
+| Supported bundle coverage | Eligible active installations with verified supported revision / eligible active installations inventoried. | Platform & IT; weekly. Unknown/invisible laptops remain unknown and inventory coverage is separately reported; do not treat silence as compliant. |
+| Useful adoption | Distinct eligible participants using an approved skill in an eligible workflow / eligible participants during window, plus qualitative usefulness. | Data & AI and People & Administration Squad; monthly aggregate. Separate declared, observed and inferred usage; suppress small cohorts and never rank people. |
+| Change lead time | Commit-to-production elapsed time per deployed change; report distribution and population. Repository + deployment SHA association. | Platform & IT / Product Engineering; service-level trend. Missing SHA mapping is missing coverage, not instantaneous delivery. DORA definition, not PR-open-to-merge time.[12] |
+| Deployment frequency | Production deployments / stated period, service-scoped. | Platform & IT; report with quality measures. Exclude retries/duplicate events; no incentive to split meaningless deployments.[12] |
+| Change fail rate | Production deployments requiring immediate intervention / all production deployments. | Quality Engineering / Platform & IT; require incident/rollback linkage and intervention definition. Missing incident links limit confidence.[12] |
+| Failed deployment recovery time | Recovery timestamp minus failed-deployment failure timestamp; distribution over relevant failed deployments. | Platform & IT; unresolved failures shown separately, never dropped as if recovered. Not all-incident MTTR.[12] |
+| Deployment rework rate | Unplanned incident-driven production deployments / all production deployments. | Platform & IT; preserve planned/unplanned classification and incident link. DORA fifth metric, distinct from change fail rate.[12] |
+| Escaped quality issues | Severity-stratified post-acceptance defects / accepted changes with completed follow-up, plus absolute incident counts. | Quality Engineering; agreed maturation window. Do not compare immature and mature cohorts or imply every defect was AI-caused. |
+| Safety / policy violations | Confirmed prohibited actions or attempted bypasses / evaluated eligible runs, with severe incidents also as absolute counts. | Architecture & Security; immediate incident response and periodic trend. Separate detected attempts, blocked attempts and actual effects; zero observed is not proof of no risk. |
+| Cost per accepted outcome | Allocated license + model/tool/compute + human review/rework costs / independently accepted outcomes; include costs of failed/abandoned attempts in numerator. | Finance & Accounting Squad; monthly. Show uncertain allocation and missing spend; do not call model tokens the whole cost. |
+| Human experience | Aggregate survey distribution for cognitive load, confidence in verification and perceived usefulness, with response count / invited eligible population. | People & Administration Squad / Data & AI; periodic. Self-selection and perception bias explicit; no employee surveillance dashboard. |
+| Maintenance health | Approved skills within review window / active approved skills; separately count ownerless, deprecated-in-use and revoked-in-use revisions. | Data & AI / Platform & IT; catalog release and periodic review. Review stamp alone is not quality evidence. |
+
+Recommended minimal event schema: `event_id`, `schema_version`, `event_type`, `occurred_at`, `received_at`, `producer`, `task_id`, `attempt_id`, `project_id`, `pseudonymous_actor_id` where necessary, `client/host/version`, `model_id/version_if_exposed`, `skill_id/revision/digest`, `adapter_revision`, `policy_revision`, `repo_commit`, `outcome`, `reason_code`, `evidence_ref`, `cost_amount/currency/basis`, `measurement_origin` (server/client/self-report), and `consent_or_collection_basis`. Fields can be nullable with reason; do not fabricate a model revision hidden by a provider.
+
+Recommended ingestion rules: deduplicate by producer + event_id; model retries as attempts, not extra completed tasks; preserve late events and recompute versioned aggregates; use server receipt and skew checks rather than trusting laptop clocks blindly. A lost terminal event is unknown until reconciled, not automatically success or abandonment. Distinguish paused, failed, abandoned, cancelled-before-start and accepted. A skill-loaded event records loading only. A task can involve multiple skills/versions and agents; avoid attributing the entire outcome or labor time to every invocation.
+
+Suggested privacy starting point for human approval: short raw structured-event retention (for example 30 days), longer aggregate trends (for example 12 months), no raw prompts/code/screens by default, role-limited incident evidence, and explicit deletion/access process. These durations are policy proposals, not legal requirements or existing Eldorado settings. Confirm employment/privacy constraints with responsible owners before collection.
+
+Pilot comparison recommendation: define task classes and quality acceptance first; collect a prospective baseline and eligible population; compare matched or randomized cohorts when ethical/practical; record concurrent process/client/model changes. Keep quality and risk guardrails fixed. Report descriptive trends separately from causal estimates. Measure elapsed lead time and human effort separately because parallel agents break the assumption that elapsed time equals labor saved; METR's follow-up explicitly raises this issue.[22]
+
+For executable downstream examples, use clearly synthetic fixtures covering duplicates, retries, unknown outcomes, multiple skills, zero denominator, immature quality window and late deployment/incident events. Assert exact expected numerator/denominator and units. Do not display synthetic values as Eldorado baseline data.
+
+## 8. Recommended sequence and evidence gates
+
+- Foundation: inventory actual clients, repositories, data sensitivity, available events and accountable owners. Exit only with a supported pilot boundary and explicit forbidden actions, not with a catalog full of untested skills.
+- Low-risk pilot: small set of useful read-only/drafting/test-assistance skills; reviewed immutable bundles; exact-client smoke and adversarial tests; human review and failure reporting. Exit with reproducible quality evidence and usable measurement coverage.
+- Governed distribution: add version-aware adapters, onboarding, staged upgrades, rollback/revocation drills and exception expiry. Exit when stale/offline/unsupported clients cannot bypass central privileged gates.
+- Logical SDLC coordination: coordinator starts by observing and assembling evidence, then proposing work and routing approvals. Expand mutation only after idempotency, separation of duties, scoped credentials, outage recovery and kill-switch tests pass.
+- Broader departmental use: Operations, Marketing, Finance & Accounting and HR & Administration adopt domain-specific skills with their own human decisions, data boundaries and outcome measures. Do not copy coding autonomy into payments, personnel decisions or disputes.
+
+No invented rollout dates, budget, staffing capacity or required improvement percentage. Scale only when quality, risk and cost evidence support it; stop or narrow scope when benefits are not demonstrated.
+
+## 9. Source coverage and unresolved questions
+
+Coverage: 26 retrieved primary-source records with 50 literal evidence passages. Includes Agent Skills specification and integration guidance; GitHub support/instructions/install/metrics; Claude skills/memory/hooks/security/monitoring; Cline skills/rules/hooks and linked SDK plugins; agent-evaluation methodology; current DORA definitions; author-hosted SPACE summary; NIST framework/core/GenAI profile landing page; OWASP prompt injection; two primary research abstracts plus METR historical study and 2026 follow-up. This is substantive source-body review, but not a systematic literature review, independent replication, legal assessment or live client qualification. Full PDFs for the two arXiv papers and NIST GenAI profile were not reviewed; claims are limited accordingly. ACM's 403 is recorded and resolved only to the author-hosted summary, not bypassed or silently called full text.
+
+Open decisions/evidence needed before implementation:
+
+1. Which actual client hosts, versions, models, OSs, subscriptions and managed-device controls are in use? What is the allowed support window?
+2. Which repository/CI/release systems and protected-branch controls are authoritative? Can required checks and policy definitions be altered by a candidate PR or bypassed by administrators?
+3. Who fills each approving/operating function and who provides cover? What pilot capacity is available? The documented organization does not establish personnel availability.
+4. What data may reach each model provider or telemetry endpoint; what retention/training/region and contractual terms apply? No provider contract was inspected.
+5. Which low-risk workflows have enough representative tasks and independent quality labels? What is the actual eligible population and baseline coverage?
+6. What timeout, stale-bundle grace, critical-risk rejection and emergency-revocation policies will owners approve? Can laptop access be independently revoked?
+7. Does the chosen distributor support private Gitea securely, and can every supported client report effective skill/adapter versions without collecting sensitive content?
+8. What causal claims, if any, can the proposed pilot design justify given self-selection, learning, task mix and parallel work?
+9. Which detailed Cline/Copilot hooks and offline/resume behavior exist in the precise deployed builds? Sources here do not establish cross-client equivalence.
+
+Synthesis handoff: keep this research trail outside reader-facing portal prose. Use ordinary operating-model language for the strategy, preserve all existing teams and leadership uncertainty, visibly distinguish target maturity from current state, and retain recommendation/source mapping internally. No portal publication is part of this research card.
+
+## Sources
+
+[1] https://agentskills.io/specification — Agent Skills specification
+[2] https://docs.github.com/en/copilot/concepts/agents/about-agent-skills — Copilot Agent Skills
+[3] https://docs.github.com/en/copilot/concepts/prompting/response-customization — Copilot custom instructions
+[4] https://code.claude.com/docs/en/skills — Claude Code skills
+[5] https://code.claude.com/docs/en/memory — Claude Code memory
+[6] https://code.claude.com/docs/en/hooks — Claude Code hooks
+[7] https://code.claude.com/docs/en/security — Claude Code security
+[8] https://docs.cline.bot/customization/skills — Cline skills
+[9] https://docs.cline.bot/customization/cline-rules — Cline rules
+[10] https://docs.cline.bot/customization/hooks — Cline hooks
+[11] https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents — Demystifying evals for AI agents
+[12] https://dora.dev/guides/dora-metrics — DORA software delivery metrics
+[13] https://www.nist.gov/itl/ai-risk-management-framework — NIST AI RMF
+[14] https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence — NIST Generative AI Profile
+[15] https://genai.owasp.org/llmrisk/llm01-prompt-injection — OWASP prompt injection
+[16] https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study — Experienced developer RCT
+[17] https://arxiv.org/abs/2302.06590 — AI developer productivity experiment
+[18] https://arxiv.org/abs/2410.12944 — Field experiments in software development
+[19] https://docs.github.com/en/copilot/concepts/billing-and-usage/copilot-usage-metrics/copilot-metrics — Copilot metrics concepts
+[20] https://code.claude.com/docs/en/monitoring-usage — Claude Code monitoring
+[21] https://agentskills.io/client-implementation/adding-skills-support — Agent Skills security
+[22] https://metr.org/blog/2026-02-24-uplift-update — METR productivity update 2026
+[23] https://docs.cline.bot/sdk/plugins — Cline SDK plugins
+[24] https://www.microsoft.com/en-us/research/publication/the-space-of-developer-productivity-theres-more-to-it-than-you-think — SPACE research publication
+[25] https://airc.nist.gov/airmf-resources/airmf/5-sec-core — NIST AI RMF Core
+[26] https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/add-skills — Copilot adding skills

research/ai-adoption/horizon-evidence.md

@@ -0,0 +1,19 @@
+# Strategy horizons — correction evidence matrix
+
+Authority: user message `1557813737941901572` in Eldorado storm-v1. This correction restores the agreed long-term destination; it does not authorize autonomous execution. Original PDF read in full: Format, Context, all four questions and assumptions instruction; its existing SHA-256 remains in `assignment-evidence.json`.
+
+| Horizon / reader destination | Origin and preservation | Result / boundary | Verification |
+| --- | --- | --- | --- |
+| Target `/strategy/target-operating-model/` | Meaningful Target body restored from pre-PR38 `88a43757762114a506f57ed4b44484306cae1aaa`; original desktop/mobile `strategy-target` JSON unchanged | Human-directed/guided/reviewed autonomous SDLC is the long-term vision, not merely a competing optional destination. Eight lifecycle phases, central agent with eight governance spokes, eight outside human-controlled AI Agents; no fixed timing or present permission | `sdlc-cycle`, `target-midpoints`, `assignment` tests; real inline/fullscreen and complete light/dark exports |
+| Roadmap `/strategy/roadmap/` | Original three-level body and six paired workflow JSON files restored from the same historical revision, then reconciled with intervention choice and new links | Skills/practices adoption → controlled autonomous capabilities; Delivery first, remaining phase order undecided, Delivery keeps improving. Evidence and separate human authority, not automatic graduation | `roadmap`, `roadmap-viewer`, browser `roadmap-timeline` |
+| 6 Months Target `/strategy/six-months-target/` | PR38 assignment narrative moved out of Target, including the entire assumptions register and credible outcome conditions | PDF facts: close to80 engineers growing toward100, more than10 teams, everyone already using AI unevenly; solo CTO-reporting architect with no formal team authority. Actual stack/reporting/capacity unknown. First six months contribute toward—not replace—the destination | `assignment-evidence.json` maps all four PDF answers, format and assumptions to actual pages |
+| 6 Months Roadmap `/strategy/six-months-roadmap/` | PR38 month1–6 action plan, influence/capacity and full EXP-01 packet preserved here as the single plan | One active pilot; independent checks; explicit effort limits, recovery, inconclusive extension and stop. EXP-01 remains fictional. No benefits, approvals or organization-wide rollout fabricated | Assignment markers; exact EXP-01 packet preservation; first-revision tests; browser six-month diagram controls and exports |
+| Beyond 6 Months `/strategy/stage-02-autonomous-agent/` | Existing useful autonomy-stage content and diagram retained | Connect evidence-led next investments toward long-term vision; authority expands only through a separate case, scoped credentials, independent checks, stop/takeover and reopening on boundary changes | Connected-strategy tests and actual reader handoffs |
+| Nested lifecycle and references | Stage01 URL retained as concise lifecycle reference beneath 6 Months Roadmap. All6 topic routes,16 metric contracts and2 shared reference pages remain reachable | No second competing monthly plan. First-revision N/A comparator, clean current-practice recovery, qualification-versus-pilot distinction retained. Contract bodies remain byte-identical;9 prototype calculations and7 unimplemented metrics remain explicitly classified |30-route manifest with original metric hashes;44-doc resolved sidebar/link/anchor checks |
+| Presentation integration | Published PR40 merge `432370473d6aaee229b0279551ce7b63da52acb7` merged into isolated branch, including320px toolbar correction |19slides,35-minute content +15-minute Q&A unchanged. Focused source-link and Beyond wording changes only; references now name all five horizons. Homepage and toolbar Strategy still open long-term Target | Generated slide-source map, exact source hashes and presentation browser suite; inspect changed slides16/19 individually |
+
+No Organization body, runtime vendor or dependency changes are introduced relative to integrated PR40 main. Independent child reviewer owns merge/publication and durable wiki reconciliation. Local candidate evidence is not publication evidence.
+
+## Verification environment and limits
+
+Use the prefix-correct static server for full acceptance. Docusaurus `serve` on the installed Node runtime redirects WOFF2 assets to slash-suffixed paths; the regular static server serves the same built font bytes correctly. Chromium executable is selected explicitly from the installed headless build. This is desktop/mobile viewport verification, not Safari/Firefox or physical-device certification. WebM remains unsupported/disabled in this browser; SVG/PNG/JPEG/WebP controls are verified. Existing dependency audit findings are not remediated or accepted by this content change.

research/ai-adoption/measurement-migration.json

@@ -0,0 +1,162 @@
+{
+  "sourceCommit": "b9c2047c614dd4e825fa746815104d35d9500739",
+  "sourcePath": "docs/strategy/reference/measurement-contracts.mdx",
+  "metrics": [
+    {
+      "oldAnchor": "validated-task-success",
+      "title": "Validated task success",
+      "docId": "measurement/validated-task-success",
+      "url": "/strategy/measurement/validated-task-success/",
+      "calculationId": "validated-task-success",
+      "status": "prototype",
+      "contractSha256": "925100f4c84f43e2cfdca4a89d6b4a984c808dae2d2ec5e57202318f70b9c544"
+    },
+    {
+      "oldAnchor": "skill-selection-precision",
+      "title": "Skill selection precision",
+      "docId": "measurement/skill-selection-precision",
+      "url": "/strategy/measurement/skill-selection-precision/",
+      "calculationId": "selection-precision",
+      "status": "prototype",
+      "contractSha256": "189e93e4e5f52a7e70e2045c6b824a9da621382f39ba8ce9a59c0c04812f0ce3"
+    },
+    {
+      "oldAnchor": "skill-selection-recall",
+      "title": "Skill selection recall",
+      "docId": "measurement/skill-selection-recall",
+      "url": "/strategy/measurement/skill-selection-recall/",
+      "calculationId": "selection-recall",
+      "status": "prototype",
+      "contractSha256": "847b5ba6094585eb88b8eb2b55b42e0f3c6822dcaa1629256ad0501a13eb7f18"
+    },
+    {
+      "oldAnchor": "supported-bundle-coverage",
+      "title": "Supported bundle coverage",
+      "docId": "measurement/supported-bundle-coverage",
+      "url": "/strategy/measurement/supported-bundle-coverage/",
+      "calculationId": "supported-bundle-coverage",
+      "status": "unimplemented",
+      "contractSha256": "8b4dc2dbdfb6999fac283814f518645d0830d515125910d79dd7dc8763f0521c"
+    },
+    {
+      "oldAnchor": "approved-workflow-adoption",
+      "title": "Approved-workflow adoption",
+      "docId": "measurement/approved-workflow-adoption",
+      "url": "/strategy/measurement/approved-workflow-adoption/",
+      "calculationId": "useful-adoption",
+      "status": "unimplemented",
+      "contractSha256": "355996d5adb603021ba22f9e1f7f08f2fbea017dac9ee0a4bd42cc00bf7adea3"
+    },
+    {
+      "oldAnchor": "change-lead-time",
+      "title": "Change lead time",
+      "docId": "measurement/change-lead-time",
+      "url": "/strategy/measurement/change-lead-time/",
+      "calculationId": "change-lead-time",
+      "status": "unimplemented",
+      "contractSha256": "96fd0edd5eba139a7c5905b606bcc96e608c5294acd2ef0c962fdb7d339d8251"
+    },
+    {
+      "oldAnchor": "deployment-frequency",
+      "title": "Deployment frequency",
+      "docId": "measurement/deployment-frequency",
+      "url": "/strategy/measurement/deployment-frequency/",
+      "calculationId": "deployment-frequency",
+      "status": "unimplemented",
+      "contractSha256": "5a34ba52e5c2768e29a1a7574274e07a65509f75063e89ccc7ce1b035aeff4c5"
+    },
+    {
+      "oldAnchor": "change-fail-rate",
+      "title": "Change fail rate",
+      "docId": "measurement/change-fail-rate",
+      "url": "/strategy/measurement/change-fail-rate/",
+      "calculationId": "change-fail-rate",
+      "status": "prototype",
+      "contractSha256": "d2a4ecaddd468f42db5824f9bfab8a8c8fcdf9157b33b4e4f047269a83c8567b"
+    },
+    {
+      "oldAnchor": "failed-deployment-recovery-time",
+      "title": "Failed deployment recovery time",
+      "docId": "measurement/failed-deployment-recovery-time",
+      "url": "/strategy/measurement/failed-deployment-recovery-time/",
+      "calculationId": "failed-deployment-recovery-time",
+      "status": "unimplemented",
+      "contractSha256": "489fd756883d4ccee1769fcfaa0b67725420463df2b1f6faf3e7faa7002f7a80"
+    },
+    {
+      "oldAnchor": "deployment-rework-rate",
+      "title": "Deployment rework rate",
+      "docId": "measurement/deployment-rework-rate",
+      "url": "/strategy/measurement/deployment-rework-rate/",
+      "calculationId": "deployment-rework-rate",
+      "status": "prototype",
+      "contractSha256": "e8ade457136feac3ad39e9eba2a9d67142bc605727d9f4f038a7df6d5a0707fd"
+    },
+    {
+      "oldAnchor": "changes-with-escaped-quality-issues",
+      "title": "Changes with escaped quality issues",
+      "docId": "measurement/changes-with-escaped-quality-issues",
+      "url": "/strategy/measurement/changes-with-escaped-quality-issues/",
+      "calculationId": "escaped-quality-rate",
+      "status": "prototype",
+      "contractSha256": "c436d504c8b3a9f655de18b2ca00fa8a0ab47ea1cf37637ff21561f81ecc77c9"
+    },
+    {
+      "oldAnchor": "confirmed-policy-effects",
+      "title": "Confirmed policy effects",
+      "docId": "measurement/confirmed-policy-effects",
+      "url": "/strategy/measurement/confirmed-policy-effects/",
+      "calculationId": "policy-effects",
+      "status": "prototype",
+      "contractSha256": "b64c02f5516b08421fa8b816f0f490571afd05baf5ad6e9d92cb6a7b711ac82a"
+    },
+    {
+      "oldAnchor": "cost-per-accepted-outcome",
+      "title": "Cost per accepted outcome",
+      "docId": "measurement/cost-per-accepted-outcome",
+      "url": "/strategy/measurement/cost-per-accepted-outcome/",
+      "calculationId": "cost-per-accepted-outcome",
+      "status": "prototype",
+      "contractSha256": "d8865ec31315d3c8398ec58cdb6665cb506a7d6309ebec3da0ca7dea84a5f406"
+    },
+    {
+      "oldAnchor": "verification-confidence-and-cognitive-load",
+      "title": "Verification confidence and cognitive load",
+      "docId": "measurement/verification-confidence-and-cognitive-load",
+      "url": "/strategy/measurement/verification-confidence-and-cognitive-load/",
+      "calculationId": "human-experience",
+      "status": "prototype",
+      "contractSha256": "01e017471004c5f780fd0c2671a4d4449d392956cb4c5f0bd7791959d6a9af9a"
+    },
+    {
+      "oldAnchor": "skills-within-substantive-review-window",
+      "title": "Skills within substantive review window",
+      "docId": "measurement/skills-within-substantive-review-window",
+      "url": "/strategy/measurement/skills-within-substantive-review-window/",
+      "calculationId": "maintenance-health",
+      "status": "unimplemented",
+      "contractSha256": "339fe0da6b382a34c52b5ec6005ce08a7293a2b07ccd88540a6df03a02d96ad4"
+    },
+    {
+      "oldAnchor": "workflow-specific-business-acceptance",
+      "title": "Workflow-specific business acceptance",
+      "docId": "measurement/workflow-specific-business-acceptance",
+      "url": "/strategy/measurement/workflow-specific-business-acceptance/",
+      "calculationId": "department-outcome",
+      "status": "unimplemented",
+      "contractSha256": "55fce8843409a1bc1383fef3cee5b9a616b44fa8d45ba84c6e4ed490a25f2de4"
+    }
+  ],
+  "shared": [
+    {
+      "slug": "collection-and-safeguards",
+      "sha256": "37709cf9978a698026492b29f2095996c462e098a74f082a6b3c3a3a7b38ecab",
+      "previousSha256": "8610ed8df6a24cf138f9e6e2c09060db2aab4c0b1259ca0168e581e3fb964e52",
+      "revisionNote": "Stage 01 separation: baseline establishment moved to baseline.mdx; DORA candidates are optional. Event/privacy and outcome safeguards retained."
+    },
+    {
+      "slug": "synthetic-example",
+      "sha256": "24af68ff4fd61159d1c0557ed0f8f8462470d56c6c83816eb93b47fb04149fde"
+    }
+  ]
+}

research/ai-adoption/sources.json

@@ -0,0 +1,564 @@
+[
+  {
+    "id": 1,
+    "title": "Agent Skills specification",
+    "url": "https://agentskills.io/specification",
+    "publisher": "Agent Skills",
+    "retrieved_at": "2026-10-04T10:27:53.189577+00:00",
+    "claims": [
+      {
+        "claim": "The specification defines a skill directory with SKILL.md, not a universal deployment or enforcement service.",
+        "evidence": "A skill is a directory containing, at minimum, a SKILL.md file:",
+        "limitations": "Format compatibility does not certify discovery, precedence, tool permissions, safety, or instruction compliance."
+      },
+      {
+        "claim": "allowed-tools is experimental in the common specification.",
+        "evidence": "allowed-toolsNoSpace-separated string of pre-approved tools the skill may use. (Experimental)",
+        "limitations": "Format compatibility does not certify discovery, precedence, tool permissions, safety, or instruction compliance."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/01.txt",
+    "body_sha256": "0913e84055bc7eb05649aa49123a783dc1a413e4c31d0861f9ac367849c7b00e",
+    "evidence_type": "primary source body"
+  },
+  {
+    "id": 2,
+    "title": "Copilot Agent Skills",
+    "url": "https://docs.github.com/en/copilot/concepts/agents/about-agent-skills",
+    "publisher": "GitHub",
+    "retrieved_at": "2026-10-04T10:27:53.333904+00:00",
+    "claims": [
+      {
+        "claim": "GitHub documents skill support across specified Copilot surfaces, not all modes indiscriminately.",
+        "evidence": "Agent skills work with Copilot cloud agent, Copilot code review, the GitHub Copilot CLI, the GitHub Copilot app, and agent mode in Visual Studio Code and JetBrains IDEs.",
+        "limitations": "Vendor documentation, not an Eldorado installation test. Separate adding-skills page omits JetBrains in its overview; validate exact host/version."
+      },
+      {
+        "claim": "Copilot documents multiple project skill paths.",
+        "evidence": "Project skills, stored in your repository (.github/skills, .claude/skills, or .agents/skills)",
+        "limitations": "Vendor documentation, not an Eldorado installation test. Separate adding-skills page omits JetBrains in its overview; validate exact host/version."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/02.txt",
+    "body_sha256": "26c86bc2afa4813c46361429f015f687164a69f39030fa05dbc1f513a04c0ca3",
+    "evidence_type": "primary source body"
+  },
+  {
+    "id": 3,
+    "title": "Copilot custom instructions",
+    "url": "https://docs.github.com/en/copilot/concepts/prompting/response-customization",
+    "publisher": "GitHub",
+    "retrieved_at": "2026-10-04T10:27:53.960265+00:00",
+    "claims": [
+      {
+        "claim": "GitHub explicitly warns that custom-instruction following is nondeterministic.",
+        "evidence": "Due to the non-deterministic nature of AI, Copilot may not always follow your custom instructions in exactly the same way every time they are used.",
+        "limitations": "Instruction precedence is surface-specific and is not enforceable authorization. Head-branch instructions create a review trust risk."
+      },
+      {
+        "claim": "The GitHub.com instruction hierarchy prioritizes personal over repository over organization instructions.",
+        "evidence": "Multiple types of custom instructions can apply to a request sent to Copilot. Personal instructions take the highest priority. Repository instructions come next, and then organization instructions are prioritized last. However, all sets of relevant instructions are provided to Copilot.",
+        "limitations": "Instruction precedence is surface-specific and is not enforceable authorization. Head-branch instructions create a review trust risk."
+      },
+      {
+        "claim": "Copilot review reads instructions and skills from the PR head branch.",
+        "evidence": "When reviewing a pull request, Copilot reads repository custom instructions, agent instructions, and agent skills from the head branch (the branch with your changes), not the base branch. For example, when merging my-feature-branch into main, Copilot uses the instructions and skills in my-feature-branch, so you can test changes to them in the same pull request without merging them first.",
+        "limitations": "Instruction precedence is surface-specific and is not enforceable authorization. Head-branch instructions create a review trust risk."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/03.txt",
+    "body_sha256": "1c2c190052653b8baad1478dc53b7a0657b741be0dbb0ef202b3f503c6b3379c",
+    "evidence_type": "primary source body"
+  },
+  {
+    "id": 4,
+    "title": "Claude Code skills",
+    "url": "https://code.claude.com/docs/en/skills",
+    "publisher": "Anthropic",
+    "retrieved_at": "2026-10-04T10:27:53.088978+00:00",
+    "claims": [
+      {
+        "claim": "Claude skill name collisions prioritize enterprise over personal over project.",
+        "evidence": "Two of enterprise, personal, and projectEnterprise over personal, and personal over project. With deploy in both ~/.claude/skills/ and the project’s .claude/skills/, /deploy runs the personal one",
+        "limitations": "Vendor extensions and changing versions prevent assuming cross-client parity. No local client exercised."
+      },
+      {
+        "claim": "Claude extends the common skill format with client-specific functionality.",
+        "evidence": "Claude Code skills follow the Agent Skills open standard, which works across multiple AI tools. Claude Code extends the standard with additional features like invocation control, subagent execution, and dynamic context injection. See Using skill frontmatter outside Claude Code for which frontmatter fields are part of the standard and which are Claude Code extensions.",
+        "limitations": "Vendor extensions and changing versions prevent assuming cross-client parity. No local client exercised."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/04.txt",
+    "body_sha256": "4ac3de187f2ba050da149e1bea3364a959366be03963e7a76dc9f9041bdb4e1f",
+    "evidence_type": "primary source body"
+  },
+  {
+    "id": 5,
+    "title": "Claude Code memory",
+    "url": "https://code.claude.com/docs/en/memory",
+    "publisher": "Anthropic",
+    "retrieved_at": "2026-10-04T10:27:52.994293+00:00",
+    "claims": [
+      {
+        "claim": "Claude memory instructions are context, not enforced configuration.",
+        "evidence": "Claude Code has two complementary memory systems. Both are loaded at the start of every conversation. Claude treats them as context, not enforced configuration. To block an action regardless of what Claude decides, use a PreToolUse hook instead. The more specific and concise your instructions, the more consistently Claude follows them.",
+        "limitations": "Context order does not establish deterministic behavior; conflicting prose may still produce arbitrary choices."
+      },
+      {
+        "claim": "Claude concatenates discovered memory files rather than treating them as override-only configuration.",
+        "evidence": "All discovered files are concatenated into context rather than overriding each other. Across the directory tree, content is ordered from the filesystem root down to your working directory. For the foo/bar/ example, foo/CLAUDE.md appears in context before foo/bar/CLAUDE.md, so instructions closer to where you launched Claude are read last. Within each directory, CLAUDE.local.md is appended after CLAUDE.md, so your personal notes are the last thing Claude reads at that level.",
+        "limitations": "Context order does not establish deterministic behavior; conflicting prose may still produce arbitrary choices."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/05.txt",
+    "body_sha256": "b19869f25886f95f8d93cec941482cbf9472b507ab8d643b446b1450b915e0df",
+    "evidence_type": "primary source body"
+  },
+  {
+    "id": 6,
+    "title": "Claude Code hooks",
+    "url": "https://code.claude.com/docs/en/hooks",
+    "publisher": "Anthropic",
+    "retrieved_at": "2026-10-04T10:27:53.059984+00:00",
+    "claims": [
+      {
+        "claim": "Claude PreToolUse command/http/MCP hook timeout is not fail-closed.",
+        "evidence": "A timed-out command, http, or mcp_tool hook doesn’t block the tool call. The call continues through the normal permission flow, so don’t count on a stalled hook to act as a gate.",
+        "limitations": "Event and hook-family distinctions matter; no universal fail-closed promise. No hook was installed or tested here."
+      },
+      {
+        "claim": "A conventional exit code 1 alone does not reliably block most Claude hook events.",
+        "evidence": "For most hook events, exit code 2 is the only exit code that blocks through the code alone. Without valid JSON on stdout, Claude Code treats exit code 1 as a non-blocking error and proceeds with the action, even though 1 is the conventional Unix failure code. If your hook is meant to enforce a policy, use exit 2. The worktree events differ: any non-zero exit code from WorktreeCreate aborts worktree creation, and any non-zero exit code from WorktreeRemove makes worktree removal fail if the directory still exists afterward.",
+        "limitations": "Event and hook-family distinctions matter; no universal fail-closed promise. No hook was installed or tested here."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/06.txt",
+    "body_sha256": "ae1919a5b06aa6d4a213bfafcaab1d2473f0b89d53b9fcc35358a19ab9ca3e5d",
+    "evidence_type": "primary source body"
+  },
+  {
+    "id": 7,
+    "title": "Claude Code security",
+    "url": "https://code.claude.com/docs/en/security",
+    "publisher": "Anthropic",
+    "retrieved_at": "2026-10-04T10:27:52.953904+00:00",
+    "claims": [
+      {
+        "claim": "Claude working-directory approval is not OS-level containment.",
+        "evidence": "Working directory boundary: In Manual mode, Claude Code asks you before its file tools read or write outside the folder where it was started and its subfolders. The boundary is a permission prompt, so a Bash command you approve can still write anywhere your user account can",
+        "limitations": "Vendor capability is not evidence the sandbox is enabled; approved shell commands inherit actual OS authority."
+      },
+      {
+        "claim": "OS-level Bash restrictions require sandboxing.",
+        "evidence": "To restrict Bash commands at the operating system level, turn on sandboxing",
+        "limitations": "Vendor capability is not evidence the sandbox is enabled; approved shell commands inherit actual OS authority."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/07.txt",
+    "body_sha256": "a8a2ad7d077347f1d3ea43549b0be1070e03c7737647f73ef40035d5dafb5f40",
+    "evidence_type": "primary source body"
+  },
+  {
+    "id": 8,
+    "title": "Cline skills",
+    "url": "https://docs.cline.bot/customization/skills",
+    "publisher": "Cline",
+    "retrieved_at": "2026-10-04T10:27:53.250798+00:00",
+    "claims": [
+      {
+        "claim": "Cline global skill overrides same-name project skill.",
+        "evidence": "When a global skill and project skill have the same name, the global skill takes precedence. This lets you keep general-purpose skills globally while using project-specific skills in .cline/skills/ so the whole team can use them.",
+        "limitations": "Current docs disagree with Agent Skills guide generalization. Exact installed Cline version remains unknown."
+      },
+      {
+        "claim": "Discovered Cline skills have user-controlled enable/disable toggles.",
+        "evidence": "Every skill has a toggle to enable or disable it. This lets you control which skills are active without deleting the skill directory. Skills are enabled by default when discovered.",
+        "limitations": "Current docs disagree with Agent Skills guide generalization. Exact installed Cline version remains unknown."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/08.txt",
+    "body_sha256": "38e6af22c7e9f78e90e899a7bd285e6556bfd64197fbc3f7cf279cc9ff29d416",
+    "evidence_type": "primary source body"
+  },
+  {
+    "id": 9,
+    "title": "Cline rules",
+    "url": "https://docs.cline.bot/customization/cline-rules",
+    "publisher": "Cline",
+    "retrieved_at": "2026-10-04T10:27:53.308915+00:00",
+    "claims": [
+      {
+        "claim": "Cline workspace rules override conflicting global rules, unlike skill name precedence.",
+        "evidence": "When both workspace and global rules exist, Cline combines them. Workspace rules take precedence when they conflict with global rules. See Storage Locations for more guidance.",
+        "limitations": "Rule precedence is not skill precedence; both are guidance and can be toggled."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/09.txt",
+    "body_sha256": "c1a2353c024491a42961e5ea171c341c66bbed2647464d200bf90fdbaa8a48e3",
+    "evidence_type": "primary source body"
+  },
+  {
+    "id": 10,
+    "title": "Cline hooks",
+    "url": "https://docs.cline.bot/customization/hooks",
+    "publisher": "Cline",
+    "retrieved_at": "2026-10-04T10:27:53.370475+00:00",
+    "claims": [
+      {
+        "claim": "Cline hooks landing page delegates details to SDK plugins.",
+        "evidence": "See details under SDK Plugins page.",
+        "limitations": "Landing page alone proves no event schema or IDE compatibility. SDK page was followed separately."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/10.txt",
+    "body_sha256": "2ebd8cd1c0b11fec466a3b577971382d2c4ec1f9911679b10100029e9b3be095",
+    "evidence_type": "primary source body"
+  },
+  {
+    "id": 11,
+    "title": "Demystifying evals for AI agents",
+    "url": "https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents",
+    "publisher": "Anthropic",
+    "retrieved_at": "2026-10-04T10:27:53.451618+00:00",
+    "claims": [
+      {
+        "claim": "Repeated trials are needed for variable agent outputs.",
+        "evidence": "Each attempt at a task is a trial. Because model outputs vary between runs, we run multiple trials to produce more consistent results.",
+        "limitations": "Vendor-authored methodology and examples, not independent proof of any skill gain or target threshold."
+      },
+      {
+        "claim": "Agent outcome evaluation must inspect environment state rather than trust claimed completion.",
+        "evidence": "The outcome is the final state in the environment at the end of the trial. A flight-booking agent might say “Your flight has been booked” at the end of the transcript, but the outcome is whether a reservation exists in the environment’s SQL database.",
+        "limitations": "Vendor-authored methodology and examples, not independent proof of any skill gain or target threshold."
+      },
+      {
+        "claim": "Agent evals combine code, model and human graders.",
+        "evidence": "Agent evaluations typically combine three types of graders: code-based, model-based, and human. Each grader evaluates some portion of either the transcript or the outcome. An essential component of effective evaluation design is to choose the right graders for the job.",
+        "limitations": "Vendor-authored methodology and examples, not independent proof of any skill gain or target threshold."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/11.txt",
+    "body_sha256": "7940a33d8e19ff68aac5e3c095e0fa771565a4b2416e8a781e9ed02d55668a12",
+    "evidence_type": "primary source body"
+  },
+  {
+    "id": 12,
+    "title": "DORA software delivery metrics",
+    "url": "https://dora.dev/guides/dora-metrics/",
+    "publisher": "DORA",
+    "retrieved_at": "2026-10-04T10:27:53.335018+00:00",
+    "claims": [
+      {
+        "claim": "DORA now documents five software-delivery performance metrics.",
+        "evidence": "These metrics have evolved alongside the technology landscape: shifting from the original four keys to the current five-metric model. To understand the research behind changes like the move from MTTR to Failed Deployment Recovery Time, read A history of DORA’s software delivery metrics.",
+        "limitations": "Service/team outcome measures, not causal AI-effect estimates or individual productivity scores."
+      },
+      {
+        "claim": "DORA change lead time runs from commit to production deployment.",
+        "evidence": "Change lead time: The amount of time it takes for a change to go from committed to version control to deployed in production.",
+        "limitations": "Service/team outcome measures, not causal AI-effect estimates or individual productivity scores."
+      },
+      {
+        "claim": "DORA deployment rework measures unplanned incident-driven deployments.",
+        "evidence": "Deployment rework rate: The ratio of deployments that are unplanned but happen as a result of an incident in production.",
+        "limitations": "Service/team outcome measures, not causal AI-effect estimates or individual productivity scores."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/12.txt",
+    "body_sha256": "0535efe22d238f38d1de5ec655efeb44a313e59f8a71085e902bde5c7a693cb9",
+    "evidence_type": "primary source body"
+  },
+  {
+    "id": 13,
+    "title": "NIST AI RMF",
+    "url": "https://www.nist.gov/itl/ai-risk-management-framework",
+    "publisher": "NIST",
+    "retrieved_at": "2026-10-04T10:27:53.731461+00:00",
+    "claims": [
+      {
+        "claim": "NIST AI RMF is voluntary guidance for trustworthiness across the AI lifecycle.",
+        "evidence": "Led by the Information Technology Laboratory (ITL) AI Program, and in collaboration with the private and public sectors, NIST has developed a framework to better manage risks to individuals, organizations, and society associated with artificial intelligence (AI). The NIST AI Risk Management Framework (AI RMF) is intended for voluntary use and to improve the ability to incorporate trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems.",
+        "limitations": "Voluntary framework, not certification, legal advice, or evidence of Eldorado compliance."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/14.txt",
+    "body_sha256": "2fed4e9811f05579384a23b9c3b81600ddf0f011fc4cfe638352a817f91ed603",
+    "evidence_type": "primary source body"
+  },
+  {
+    "id": 14,
+    "title": "NIST Generative AI Profile",
+    "url": "https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence",
+    "publisher": "NIST",
+    "retrieved_at": "2026-10-04T10:27:53.743664+00:00",
+    "claims": [
+      {
+        "claim": "NIST GenAI profile is a cross-sectoral companion to AI RMF.",
+        "evidence": "This document is a cross-sectoral profile of and companion resource for the AI Risk Management Framework (AI RMF 1.0) for Generative AI, pursuant to President Biden's Executive Order (EO) 14110 on Safe, Secure, and Trustworthy Artificial Intelligence. The AI RMF was released in January 2023, and is intended for voluntary use and to improve the ability of organizations to incorporate trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems.",
+        "limitations": "Publication landing-page abstract inspected; full PDF not read. Do not attribute detailed risk taxonomy to this excerpt."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/15.txt",
+    "body_sha256": "7998580f4dc83770568dc361ecae1d46e1d652a2df12a278263b88de6cbfb624",
+    "evidence_type": "primary source body"
+  },
+  {
+    "id": 15,
+    "title": "OWASP prompt injection",
+    "url": "https://genai.owasp.org/llmrisk/llm01-prompt-injection/",
+    "publisher": "OWASP",
+    "retrieved_at": "2026-10-04T10:27:53.529810+00:00",
+    "claims": [
+      {
+        "claim": "External sources can carry prompt injections.",
+        "evidence": "Indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files. The content may have in the external content data that when interpreted by the model, alters the behavior of the model in unintended or unexpected ways. Like direct injections, indirect injections can be either intentional or unintentional.",
+        "limitations": "Mitigations reduce exposure; no guarantee that prompt injection is eliminated."
+      },
+      {
+        "claim": "OWASP recommends least privilege.",
+        "evidence": "Provide the application with its own API tokens for extensible functionality, and handle these functions in code rather than providing them to the model. Restrict the model’s access privileges to the minimum necessary for its intended operations.",
+        "limitations": "Mitigations reduce exposure; no guarantee that prompt injection is eliminated."
+      },
+      {
+        "claim": "OWASP recommends human approval for high-risk operations.",
+        "evidence": "Implement human-in-the-loop controls for privileged operations to prevent unauthorized actions.",
+        "limitations": "Mitigations reduce exposure; no guarantee that prompt injection is eliminated."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/16.txt",
+    "body_sha256": "5bfcc42a422165d0a6b25f28fbff144fc0dec5289f1a672a40203e1d64200c07",
+    "evidence_type": "primary source body"
+  },
+  {
+    "id": 16,
+    "title": "Experienced developer RCT",
+    "url": "https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/",
+    "publisher": "METR",
+    "retrieved_at": "2026-10-04T10:27:54.289507+00:00",
+    "claims": [
+      {
+        "claim": "METR early-2025 RCT found 19% longer task time in its setting.",
+        "evidence": "We conduct a randomized controlled trial (RCT) to understand how early-2025 AI tools affect the productivity of experienced open-source developers working on their own repositories. Surprisingly, we find that when developers use AI tools, they take 19% longer than without—AI makes them slower. We view this result as a snapshot of early-2025 AI capabilities in one relevant setting; as these systems continue to rapidly evolve, we plan on continuing to use this methodology to help estimate AI acceleration from AI R&D automation.",
+        "limitations": "Historical narrow setting, tools from early 2025; superseded as a current estimate by authors. No Eldorado forecast."
+      },
+      {
+        "claim": "Study involved 16 experienced developers and 246 issues on their repositories.",
+        "evidence": "To directly measure the real-world impact of AI tools on software development, we recruited 16 experienced developers from large open-source repositories (averaging 22k+ stars and 1M+ lines of code) that they’ve contributed to for multiple years. Developers provide lists of real issues (246 total) that would be valuable to the repository—bug fixes, features, and refactors that would normally be part of their regular work. Then, we randomly assign each issue to either allow or disallow use of AI while working on the issue. When AI is allowed, developers can use any tools they choose (primarily Cursor Pro with Claude 3.5/3.7 Sonnet—frontier models at the time of the study); when disallowed, they work without generative AI assistance. Developers complete these tasks (which average two hours each) while recording their screens, then self-report the total implementation time they needed. We pay developers $150/hr as compensation for their participation in the study.",
+        "limitations": "Historical narrow setting, tools from early 2025; superseded as a current estimate by authors. No Eldorado forecast."
+      },
+      {
+        "claim": "METR now explicitly marks those historical results as not current.",
+        "evidence": "We have released results that are current as of early 2026, in a continuation of this study. We believe these historical results no longer reflect the current impact of AI models on open-source developer productivity.",
+        "limitations": "Historical narrow setting, tools from early 2025; superseded as a current estimate by authors. No Eldorado forecast."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/17.txt",
+    "body_sha256": "f9abab8a3ad312279800d8327122ebae70c13804d9f91fda1788db1a466a178b",
+    "evidence_type": "primary source body"
+  },
+  {
+    "id": 17,
+    "title": "AI developer productivity experiment",
+    "url": "https://arxiv.org/abs/2302.06590",
+    "publisher": "Peng et al.",
+    "retrieved_at": "2026-10-04T10:27:53.477297+00:00",
+    "claims": [
+      {
+        "claim": "Peng et al. controlled HTTP-server task study reports 55.8% faster completion with Copilot.",
+        "evidence": "Abstract:Generative AI tools hold promise to increase human productivity. This paper presents results from a controlled experiment with GitHub Copilot, an AI pair programmer. Recruited software developers were asked to implement an HTTP server in JavaScript as quickly as possible. The treatment group, with access to the AI pair programmer, completed the task 55.8% faster than the control group. Observed heterogenous effects show promise for AI pair programmers to help people transition into software development careers.",
+        "limitations": "Primary paper abstract inspected, not full methods. Bounded JavaScript task; not whole-SDLC productivity."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/18.txt",
+    "body_sha256": "76c71ee9844c5066d184ec5006945c48959dfcd75854842463cd756f348a3140",
+    "evidence_type": "primary research abstract"
+  },
+  {
+    "id": 18,
+    "title": "How much does AI impact development speed? An enterprise-based randomized controlled trial",
+    "url": "https://arxiv.org/abs/2410.12944",
+    "publisher": "Paradis et al. / arXiv",
+    "retrieved_at": "2026-10-04T10:27:53.495104+00:00",
+    "claims": [
+      {
+        "claim": "Paradis et al. Google RCT abstract reports about 21% shorter task time with a large confidence interval, among 96 engineers.",
+        "evidence": "Abstract:How much does AI assistance impact developer productivity? To date, the software engineering literature has provided a range of answers, targeting a diversity of outcomes: from perceived productivity to speed on task and developer throughput. Our randomized controlled trial with 96 full-time Google software engineers contributes to this literature by sharing an estimate of the impact of three AI features on the time developers spent on a complex, enterprise-grade task. We found that AI significantly shortened the time developers spent on task. Our best estimate of the size of this effect, controlling for factors known to influence developer time on task, stands at about 21\\%, although our confidence interval is large. We also found an interesting effect whereby developers who spend more hours on code-related activities per day were faster with AI. Product and future research considerations are discussed. In particular, we invite further research that explores the impact of AI at the ecosystem level and across multiple suites of AI-enhanced tools, since we cannot assume that the effect size obtained in our lab study will necessarily apply more broadly, or that the effect of AI found using internal Google tooling in the summer of 2024 will translate across tools and over time.",
+        "limitations": "Primary paper abstract inspected, not full methods. Google-specific task/tool setting; no universal gain claim. Retrieval seed title was wrong and corrected from body."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/19.txt",
+    "body_sha256": "e3ac83e7a8c9a613ed67b179321599538d4132e0caf858c4d335452c924c6839",
+    "evidence_type": "primary research abstract"
+  },
+  {
+    "id": 19,
+    "title": "Copilot metrics concepts",
+    "url": "https://docs.github.com/en/copilot/concepts/billing-and-usage/copilot-usage-metrics/copilot-metrics",
+    "publisher": "GitHub",
+    "retrieved_at": "2026-10-04T10:27:54.384631+00:00",
+    "claims": [
+      {
+        "claim": "Copilot richest metrics depend on enabled client telemetry.",
+        "evidence": "Copilot usage metrics are derived from telemetry across multiple Copilot surfaces, including IDE, Copilot CLI, and agent apps activity. Most metrics come from client-side IDE telemetry, and end users need telemetry enabled in their IDE for the richest data in these metrics.",
+        "limitations": "No access to Eldorado subscription, settings, enabled exporters, reports or coverage. Adoption is not impact."
+      },
+      {
+        "claim": "Server-side active-user coverage does not ensure complete feature/LOC breakdowns.",
+        "evidence": "Users surfaced through server-side telemetry are fully counted toward your active user totals (such as daily active users, daily_active_users ). When available, they may also appear in totals_by_ide (including the most recently detected IDE and Copilot extension versions in per-user reports). However, other dimensional breakdowns—such as totals_by_feature and lines-of-code metrics—remain empty until richer telemetry is available for them. Top-level totals and breakdowns for users already captured by client telemetry are unchanged.",
+        "limitations": "No access to Eldorado subscription, settings, enabled exporters, reports or coverage. Adoption is not impact."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/20.txt",
+    "body_sha256": "556fe5be28952b3b7d980b86b8a1a15713f0cff8359a7a0e02e09af7d6916ace",
+    "evidence_type": "primary source body"
+  },
+  {
+    "id": 20,
+    "title": "Claude Code monitoring",
+    "url": "https://code.claude.com/docs/en/monitoring-usage",
+    "publisher": "Anthropic",
+    "retrieved_at": "2026-10-04T10:27:53.636289+00:00",
+    "claims": [
+      {
+        "claim": "Claude supports configured OTel usage/cost/tool telemetry.",
+        "evidence": "Track Claude Code usage, costs, and tool activity across your organization by exporting telemetry data through OpenTelemetry (OTel). Claude Code exports metrics as time series data via the standard metrics protocol, events via the logs/events protocol, and optionally distributed traces via the traces protocol.",
+        "limitations": "Capability depends on version/configuration. Tool/skill-name export may expose confidential identifiers; no observed Eldorado telemetry."
+      },
+      {
+        "claim": "Skill-name/tool detail collection has explicit opt-in and privacy implications.",
+        "evidence": "OTEL_LOG_TOOL_DETAILSEnable logging of tool parameters and input arguments in tool events and trace span attributes: Bash commands, MCP server and tool names, skill names, user-authored workflow names, and tool input. Also enables custom, plugin, and MCP command names on user_prompt events, and real agent, skill, plugin, and MCP server and tool names on the cost and token counters (default: disabled). For Claude Desktop’s built-in servers, in sessions Claude Desktop owns, mcp_server_name/mcp_tool_name emit on tool_decision/tool_result even with the flag off. The exception requires Claude Code v2.1.214 or later1 to enable",
+        "limitations": "Capability depends on version/configuration. Tool/skill-name export may expose confidential identifiers; no observed Eldorado telemetry."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/21.txt",
+    "body_sha256": "197b3be58cae62470e82ac24074ca81024b030701ab3e2729116067dac798b48",
+    "evidence_type": "primary source body"
+  },
+  {
+    "id": 21,
+    "title": "Agent Skills security",
+    "url": "https://agentskills.io/client-implementation/adding-skills-support",
+    "publisher": "Agent Skills",
+    "retrieved_at": "2026-10-04T10:27:53.937245+00:00",
+    "claims": [
+      {
+        "claim": "The implementation guide claims project-over-user skill precedence as universal.",
+        "evidence": "The universal convention across existing implementations: project-level skills override user-level skills.",
+        "limitations": "Implementation guidance rather than normative format; universal precedence claim contradicted by current Claude and Cline docs."
+      },
+      {
+        "claim": "Agent Skills format does not mandate discovery paths.",
+        "evidence": "The .agents/skills/ paths have emerged as a widely-adopted convention for cross-client skill sharing. While the Agent Skills specification does not mandate where skill directories live (it only defines what goes inside them), scanning .agents/skills/ means skills installed by other compliant clients are automatically visible to yours, and vice versa.",
+        "limitations": "Implementation guidance rather than normative format; universal precedence claim contradicted by current Claude and Cline docs."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/22.txt",
+    "body_sha256": "fb2909a93d445a4b18a7cab89c22a7e92502e99d2caa586cf785e8aa8ae7a77b",
+    "evidence_type": "primary source body"
+  },
+  {
+    "id": 22,
+    "title": "METR productivity update 2026",
+    "url": "https://metr.org/blog/2026-02-24-uplift-update/",
+    "publisher": "METR",
+    "retrieved_at": "2026-10-04T10:29:00.438454+00:00",
+    "claims": [
+      {
+        "claim": "METR 2026 follow-up calls its productivity signal unreliable because of selection and time-measurement issues.",
+        "evidence": "Unfortunately, given participant feedback and surveys, we believe that the data from our new experiment gives us an unreliable signal of the current productivity effect of AI tools. The primary reason is that we have observed a significant increase in developers choosing not to participate in the study because they do not wish to work without AI, which likely biases downwards our estimate of AI-assisted speedup. We additionally believe there have been selection effects due to a lower pay rate (we reduced the pay from $150/hr to $50/hr), and that our measurements of time-spent on each task are unreliable for the fraction of developers who use multiple AI agents concurrently.",
+        "limitations": "Authors explicitly warn selection and parallel-agent timing compromise causal magnitude. Neither raw estimate is an Eldorado baseline."
+      },
+      {
+        "claim": "2026 raw estimates suggest speedup, but intervals include no effect and selection limits generalization.",
+        "evidence": "Our raw results show some evidence for speedup. Our early 2025 study found the use of AI causes tasks to take 19% longer, with a confidence interval between +2% and +39%. For the subset of the original developers who participated in the later study, we now estimate a speedup of -18% with a confidence interval between -38% and +9%. Among newly-recruited developers the estimated speedup is -4%, with a confidence interval between -15% and +9%.",
+        "limitations": "Authors explicitly warn selection and parallel-agent timing compromise causal magnitude. Neither raw estimate is an Eldorado baseline."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/23.txt",
+    "body_sha256": "7a4ce4ac6ba1a7a2410e17982493ab0d905d5d6418f28dda7460ca2aa4068306",
+    "evidence_type": "primary source body"
+  },
+  {
+    "id": 23,
+    "title": "Cline SDK plugins",
+    "url": "https://docs.cline.bot/sdk/plugins",
+    "publisher": "Cline",
+    "retrieved_at": "2026-10-04T10:28:59.766735+00:00",
+    "claims": [
+      {
+        "claim": "Cline SDK plugins document fail_closed hook policy.",
+        "evidence": "Use fail_closed for policy-enforcement hooks where bypassing the hook is unsafe.",
+        "limitations": "SDK capability cannot be assumed identical in every Cline IDE/CLI build. Fail-closed behavior needs adapter conformance tests."
+      },
+      {
+        "claim": "Cline plugin installation accepts npm/git/file sources.",
+        "evidence": "Plugins can also be installed from file URLs, npm, git, or local paths using cline plugin install. See Plugins for install commands, the manifest format, and directory layout.",
+        "limitations": "SDK capability cannot be assumed identical in every Cline IDE/CLI build. Fail-closed behavior needs adapter conformance tests."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/24.txt",
+    "body_sha256": "445ba1089e4157e9eac938d1b7f1adf482769f3ae6d495d4bef5d666614fbd6a",
+    "evidence_type": "primary source body"
+  },
+  {
+    "id": 24,
+    "title": "SPACE research publication",
+    "url": "https://www.microsoft.com/en-us/research/publication/the-space-of-developer-productivity-theres-more-to-it-than-you-think/",
+    "publisher": "Microsoft Research",
+    "retrieved_at": "2026-10-04T10:29:02.189612+00:00",
+    "claims": [
+      {
+        "claim": "SPACE rejects productivity measurement with a single activity metric.",
+        "evidence": "Developer productivity is about more than an individual’s activity levels or the efficiency of the engineering systems relied on to ship software, and it cannot be measured by a single metric or dimension. The SPACE framework captures different dimensions of productivity, and here we demonstrate how this framework can be used to understand productivity in practice and why using it will help teams better understand developer productivity and create better measures to inform their work and teams.",
+        "limitations": "Author-hosted publication summary retrieved after ACM 403; supports multidimensional principle, not detailed instrument validity."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/25.txt",
+    "body_sha256": "1f8176ad5b14a5f4053162f670b95bdef81e191104f682c506b11099525b734e",
+    "evidence_type": "primary research abstract"
+  },
+  {
+    "id": 25,
+    "title": "NIST AI RMF Core",
+    "url": "https://airc.nist.gov/airmf-resources/airmf/5-sec-core/",
+    "publisher": "NIST",
+    "retrieved_at": "2026-10-04T10:29:00.075579+00:00",
+    "claims": [
+      {
+        "claim": "NIST RMF organizes risk activity into govern, map, measure, manage.",
+        "evidence": "highest level to govern, map, measure, and manage AI risks. Governance is designed to be a cross-cutting function",
+        "limitations": "Risk-framework recommendations are not proof controls are deployed or staffing exists."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/26.txt",
+    "body_sha256": "c80bf3d3d59511eb3932cfd285893aa2a329ca9d997939c7c8c7718d704f857b",
+    "evidence_type": "primary source body"
+  },
+  {
+    "id": 26,
+    "title": "Copilot adding skills",
+    "url": "https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/add-skills",
+    "publisher": "GitHub",
+    "retrieved_at": "2026-10-04T10:29:00.472587+00:00",
+    "claims": [
+      {
+        "claim": "gh skill --pin skips pinned skills during updates.",
+        "evidence": "To lock a skill to a specific version (or commit SHA) so it is skipped during updates, use --pin:",
+        "limitations": "gh skill is public preview, requires documented minimum CLI version; Gitea interoperability not verified. Pinning is not artifact safety."
+      },
+      {
+        "claim": "GitHub warns shared skills are unverified and may be malicious.",
+        "evidence": "Skills are not verified by GitHub and may contain prompt injections, hidden instructions, or malicious scripts. Always inspect the content of a skill before installation using gh skill preview.",
+        "limitations": "gh skill is public preview, requires documented minimum CLI version; Gitea interoperability not verified. Pinning is not artifact safety."
+      },
+      {
+        "claim": "gh skill records source ref and tree SHA in frontmatter.",
+        "evidence": "When you install a skill with gh skill, provenance metadata is written into the skill's SKILL.md frontmatter, including the source repository, ref, and tree SHA. The gh skill update command uses this metadata to check for upstream changes.",
+        "limitations": "gh skill is public preview, requires documented minimum CLI version; Gitea interoperability not verified. Pinning is not artifact safety."
+      }
+    ],
+    "evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/27.txt",
+    "body_sha256": "7a5d8597f2ed72edb4610124e83f2abc282311739eabb561b3997ab6cbcbc46b",
+    "evidence_type": "primary source body"
+  }
+]

research/ai-adoption/strategy-blueprint.md

@@ -0,0 +1,190 @@
+# Eldorado AI adoption — strategy implementation blueprint
+
+Status: target operating model for review; not an approved rollout or an inventory of deployed controls. This handoff is documentation design only. It does not authorize installing agents, collecting employee telemetry, changing permissions or enabling autonomous delivery.
+
+## Implementation contract
+
+Create eight substantive pages in the independent Strategy navigation, in this order: `index`, `target-operating-model`, `skills-governance`, `skills-quality`, `skills-adoption`, `measurement`, `skills-maintenance`, `roadmap`. The structured companion is `strategy-model.json`; its KPI definitions and identifiers are authoritative for the measurement prototype. Preserve Organization Structure, Collaboration and SDLC and their exact department/team names. Cross-link rather than duplicate reporting charts. The existing organizational documentation is an operating model, not certification of staffing.
+
+Use the existing Archify JSON renderer and shared icon-only modal control. Diagram logical ID: `ai-adoption-target`; editable source: `diagrams/ai-adoption-target.architecture.json`. Do not expose downloadable JSON. Keep source mapping and open-decision material outside docs/static/search. Reader-facing prose below can be adapted into MDX without bibliography, evidence codes, recruitment commentary or repeated caveats. Use a visible **Target operating model** introduction and prospective verbs where status matters. Never present synthetic calculations as Eldorado results.
+
+## 1. Overview — index
+
+### Govern skills first, expand authority only with evidence
+
+Eldorado's target is to make AI-assisted work dependable across the organization: useful guidance, clear human ownership, controlled execution and measurable outcomes. The first investment is a governed skills system, not an autonomous replacement for the organization. A skill packages reusable working knowledge, prerequisites and verification steps. It helps an agent perform a task; it does not grant permission or guarantee that the work is correct.
+
+The target combines one logical SDLC coordinating agent with developer choice on local laptops. Copilot, Claude Code and Cline remain client options within a qualified support matrix. They receive the same reviewed portable skill content through client-specific adapters. Repository, CI and release services remain the enforcement points, independently of what any agent says or which local tool produced a change.
+
+The strategy describes the intended operating model and the evidence required to introduce it. It does not establish that these controls are installed, that every client is supported, or that AI has improved Eldorado's performance. The current reference is the documented six-department organization. Rollout begins by validating actual clients, responsibilities, data boundaries and available evidence.
+
+Success means accepted outcomes with maintained quality, controlled risk and understood total cost. Faster activity without reliable outcomes is not success. More skill invocations, generated lines or tool subscriptions are not productivity targets. People remain accountable for product, customer, financial and personnel decisions.
+
+## 2. Target operating model — target-operating-model
+
+### One coordination function, distributed contributions
+
+Data & AI owns the coordinating function, with the existing AI Architect function connecting it to Technology leadership. The logical coordinator maintains approved work records, dependencies, evidence requests, bounded retries and escalation. It can summarize, propose work and route decisions. It cannot declare its own work approved, change protected checks, authorize production release or replace the responsible human.
+
+One logical coordinator does not mean one fragile process. A durable task ledger, explicit state transitions, leases and idempotency keys allow recovery or multiple replicas without duplicate delivery. Inference outages stop new agent decisions, not the organization's ability to take over. People can resume work through the normal deterministic workflow. Evidence and authorization services fail closed for privileged actions; missing evidence never becomes permission.
+
+The delivery path is: an approved problem and acceptance criteria; an authorized task; local or isolated worker proposals; independently reviewed repository changes; exact-revision CI evidence; a human release decision; execution by the release service; then operational feedback. Product Management accepts the outcome hypothesis and business result. Product Design reviews experience and accessibility. Product Engineering owns the code and maintainability. Quality Engineering assesses quality independently. Architecture & Security assesses risk. Platform & IT operates the delivery boundary. No arrow from a laptop or coordinator goes directly to production authority.
+
+### Trust and authority boundaries
+
+People authenticate to the work system; the coordinator receives only the project context it needs. Untrusted issue text, repository content, web pages and tool output are task data, never an authorization source. Local clients operate under device controls and project-scoped access. Hard containment requires OS/container isolation, filesystem and network restrictions and separate short-lived identities; a skill folder, prompt or working directory is not a sandbox.
+
+The registry distributes reviewed immutable content and adapters, not ambient credentials. Executable scripts, plugins, MCP servers and dependencies are separately reviewed and pinned. Model-provider routing is allowlisted for the data classification, with approved retention and training-use terms before sensitive data crosses that boundary. Fallback to another provider must not silently change the data policy.
+
+Central controls verify protected-branch review, actual artifact identity, exact commit and policy revision, required checks and a scoped human approval. Candidate changes cannot edit their own authoritative gate or reuse approval for a different artifact. Deployment credentials belong to the release service, not the local agent. Approval expires or is invalidated by changed content. Emergency stop revokes mutation credentials and stops scheduling independently of the model, preserves evidence and enables human takeover.
+
+### Department contributions
+
+| Department / existing team | Contribution and retained human decision | First bounded workflow and evidence |
+| --- | --- | --- |
+| Product / Product Management | Own pilot priorities, acceptance criteria and outcome hypotheses; decide product value. | Draft acceptance criteria from sanitized discovery notes; independent completeness review and accepted-task success. |
+| Product / Product Design | Own design quality, accessibility and research handling. | Review a proposed flow against an accessibility checklist; verify findings against the interface. |
+| Technology / Product Engineering | Own skill authoring, code review and maintainability; remain accountable for generated code. | Test scaffolding and change summaries in a disposable branch; independent tests and escaped-quality follow-up. |
+| Technology / Platform & IT | Own supported client inventory, distribution, identity, isolation, CI/release integration, transport and emergency revocation. | Qualify a pinned bundle and exercise rollback; inventory and exact-revision gate evidence. |
+| Technology / Architecture & Security | Own risk classification, data boundaries, security review and bounded exceptions. | Review injected-input and unauthorized-tool cases; independent control evidence and policy-effect counts. |
+| Technology / Quality Engineering | Own regression/adversarial suites, rubric calibration and acceptance evidence. | Evaluate candidate versus approved skills on repeated representative tasks; retain all failures. |
+| Technology / Data & AI | Own catalog coordination, coordinator evaluation and measurement design, through existing AI enablement responsibilities. | Curate a small skill set and analyze a prospective pilot; no new AI department. |
+| Operations / Operations Squad | Own service acceptance, disputes, fraud, refunds and customer communications. | Draft an answer from sanitized resolved cases; Operational Quality workstream checks correctness before any send. No automated dispute/refund decision. |
+| Marketing / Marketing Squad | Own brand, factual claims, content rights, publication and spend approvals. | Draft a campaign brief against approved brand material; human claim/rights review before publication. |
+| Finance & Accounting / Finance & Accounting Squad | Own allocation of total costs, financial evidence and segregation of approvals. | Explain a sanitized reconciliation exception; no posting, payout or payment authority. |
+| HR & Administration / People & Administration Squad | Own coaching, acceptable use, feedback privacy and people decisions; partner with Platform & IT on access lifecycle. | Draft onboarding guidance from approved policy; human accuracy review. No hiring or performance decision automation. |
+
+Product keeps two teams; Technology keeps five; the other four departments keep one squad each. Coordination, skill ownership, approval and cover are assignments inside these teams, not new standing departments, roles or headcount. Department leaders retain accountability and designate real approvers before a pilot starts.
+
+## 3. Skills governance — skills-governance
+
+### A contract that travels, controls that stay authoritative
+
+Maintain one catalog entry per stable skill ID, with immutable revisions and a concise portable `SKILL.md` body. Required content includes when to use and when not to use the skill, prerequisites, bounded steps, expected artifacts, verification, failure handling and escalation. The companion model defines the complete metadata contract: owner and independent reviewer, risk tier, supported clients and versions, dependencies, digest, provenance and license, evaluations, approval, review date, deprecation and rollback.
+
+The release manifest pins the content, dependencies and adapter revisions by full immutable commit or digest. Names use an `eldorado-` prefix to reduce collisions. Friendly versions aid communication but never replace the digest. No arbitrary upstream automatic update is admitted into the approved bundle. Changes to scripts, resources or dependencies count as skill changes, not harmless documentation edits.
+
+Adapters place content in the qualified client's discovery paths and implement only verified client-specific behavior. Qualification records the host, exact build, OS, model configuration, discovery, explicit invocation, collisions, disabled skills, permission behavior, context compaction and reload behavior. A common file format is not common precedence or a portable hooks API. Claude and Cline skill-name precedence differs from rule/memory behavior; Copilot support varies by surface. Test the actual build, not the brand name.
+
+### Lifecycle and decision rights
+
+A proposal names the problem, owner, data scope and testable outcome. Experimental revisions run only in approved disposable environments. Promotion requires independent review, static and executable dependency checks, per-client behavioral evaluations and a bounded canary. Approval records bind the exact artifact and permitted uses. Deprecated revisions carry a migration path and deadline; retired revisions are unavailable for new work. Any active revision can be quarantined immediately.
+
+The author never supplies the only approval. Data & AI maintains catalog state; the owning team is accountable for content; Quality Engineering approves evaluation evidence; Architecture & Security approves higher-risk boundaries; Platform & IT verifies distribution and revocation. A business owner accepts workflow outcomes. These functions can be covered by existing staff, but incompatible author/approver duties must remain separate for the same release.
+
+An exception contains its ID, skill/client revision, scope, business reason, risk owner, compensating checks, approver, start and expiry, affected users/projects and rollback route. It does not disable protected release, payment or identity controls. Expired or unverifiable exceptions deny privileged actions. Repeated exceptions trigger a supported-design change rather than permanent informal bypass.
+
+### Distribution, stale clients and rollback
+
+Stage a verified bundle atomically, check its digest, load it through the qualified adapter and read back its effective revision. Test already-open sessions; changing files is not proof of reloading instructions. Record immutable last-known-good content and adapter dependencies. Canary upgrades precede wider distribution.
+
+A cached verified bundle may support explicitly permitted low-risk work if its model and tool dependencies are available. It does not make a cloud-backed client work offline. Stale or unsupported sessions cannot obtain centrally mediated privileged access. Reconnection revalidates support, revocation and policy before credentials are issued. Central artifact review protects delivery even when a laptop declaration is absent or false; a client report cannot prove which private prompt was actually followed.
+
+Rollback restores the approved manifest and dependencies, invalidates affected sessions, revokes unsafe revisions, runs a smoke test and verifies effective state. It cannot undo data disclosure or commands already executed. Those require incident response.
+
+## 4. Skills quality — skills-quality
+
+Quality has four separate questions: was the right skill selected, was the procedure executed safely, did the artifact pass independent checks, and did the workflow produce useful outcomes? A successful invocation answers none of the remaining questions by itself.
+
+The proposed qualification contract uses three tiers. R1 is read-only or drafting with nonsensitive approved material; R2 creates code or material with customer impact but no privileged external effect; R3 touches privileged, financial, sensitive-personal or production decisions. R3 remains human-authorized and out of the initial autonomous scope.
+
+Every tier requires all mandatory deterministic safety, schema, authorization and provenance checks to pass, with no observed critical unauthorized action. An observed critical effect blocks promotion. The model gives proposed pilot evaluation floors and success thresholds; these are design defaults for owner ratification, not externally validated guarantees or approved service levels. If sample coverage, acceptance criteria or responsible reviewers are missing, qualification remains incomplete. No aggregate score can trade off a failed mandatory safety check.
+
+Use sanitized, predeclared task sets containing positive triggers, near misses, negative cases and the normal workload mix. Compare no-skill, current-approved and candidate paths with the same starting artifacts; repeat stochastic trials and retain failed and abandoned attempts. Independently inspect output state. Deterministic tests grade checkable constraints; calibrated humans grade usefulness, maintainability and experience. A model judge is supplementary, versioned and checked against human disagreements, never the sole safety or promotion authority.
+
+Include adversarial repository text, malicious referenced code, wrong permissions, client toggles, name shadowing, unsupported versions, hook timeout/crash/malformed response, stale sessions, offline recovery and rollback. Run central checks against forged/missing client declarations. Hook presence is not fail-closed enforcement: failure semantics must be tested on each client, and central authorization remains independent.
+
+Report denominators, task mix, trial counts, per-client results and uncertainty. A passing benchmark is evidence within a tested envelope, not proof that all future tasks are safe. Material model, client, adapter or dependency changes trigger requalification.
+
+## 5. Adoption — skills-adoption
+
+Start with a small set of useful workflows chosen by the existing teams. Product Management and the departmental owner identify the outcome; Data & AI helps turn it into a skill; Quality Engineering establishes acceptance; Platform & IT qualifies the client path; Architecture & Security clears the data boundary. People & Administration Squad coordinates learning and accessible feedback.
+
+Onboarding should teach people to select the right skill, inspect the actual artifact, recognize untrusted instructions, use the exception and incident routes and recover without AI. A practice task ends with verified work and an explanation of limits, not just a logged invocation. Demonstrate the same portable skill on the supported local clients without promising identical agent behavior.
+
+Use short worked examples, peer pairing, office hours and a clear catalog search path. Gather reasons for non-use and rejected suggestions without penalizing them. Preserve a manual path. Training feedback improves the skill only through review, not automatic self-modification of the approved catalog. Departmental workflow outcomes matter more than uniform uptake.
+
+No developer rankings, individual productivity scores, minimum invocation quotas or inference of effort from token counts are part of this strategy. Report cohort-level evidence with privacy protection and balanced quality, flow, risk and cost. A participant may reasonably stop using a skill that creates more work or uncertainty.
+
+## 6. Measurement — measurement
+
+### Decide what counts before counting
+
+Use the machine-readable KPI catalog for exact definitions. Every report states its eligible population, observation window, numerator and denominator or distribution sample count, source coverage, exclusions and calculation version. Zero denominators return “not available.” Missing telemetry is unknown, not inactivity, compliance or success. Examples are explicitly synthetic and illustrative.
+
+Begin with task acceptance, repository, CI, deployment and incident systems because they can independently establish outcomes. Add catalog/version inventory and task-level declarations. Client telemetry is supplementary and version-dependent; enabling rich tool details may collect sensitive commands and identifiers. Do not enable it merely to count skills. A normalized adapter may report approved skill identifiers without forwarding raw arguments.
+
+Validated success uses all eligible initiated tasks whose predeclared observation window has matured. Failed and abandoned tasks remain nonsuccess. Unresolved or unobserved outcomes remain in the denominator, with known-outcome coverage shown alongside the conservative confirmed-success share. They are not relabeled as observed failure. A task cancelled before start is excluded; cancellation after start remains visible. Count a task once across retries and multiple skills. For timeliness, also show unfinished work and age; accepted-only lead-time distributions have survivorship limitations.
+
+Track all five service-level DORA measures: commit-to-production lead time, deployment frequency, change fail rate, failed deployment recovery time and deployment rework rate. Do not substitute PR-open-to-merge time or all-incident MTTR. Pair them with matured escaped-quality rates, policy effects, total cost per accepted outcome, support coverage, adoption, human experience and catalog maintenance. Keep customer/business outcomes linked to their departmental hypotheses; do not infer conversion, trust or revenue improvement from delivery telemetry.
+
+### Baseline and interpretation
+
+Before a pilot, freeze eligibility and acceptance rules and verify event joins. Collect prospective no-skill/current-practice evidence over a complete comparable workflow cycle and until the preregistered precision/sample requirement is met. Do not select a convenient end date after seeing results. Retain task class, service, skill, client/model configuration and concurrent changes. A matched or randomized comparison may be used when practical and ethical; label observational trends as descriptive and report confounding, selection and uncertainty.
+
+Elapsed time and human effort are different quantities. Parallel agents may reduce waiting while increasing review or compute. Include failed attempts and human review/rework in cost, do not multiply a multi-skill task's value across every invocation, and do not convert survey perceptions into proven time savings. Small or incomplete populations yield evidence limits, not an ROI percentage.
+
+### Event and privacy contract
+
+Use the event envelope and per-event required fields in the model. Source producer plus event ID deduplicates transport retries. Conflicting payloads under the same key are quarantined. Attempts have distinct IDs under one task. Domain IDs deduplicate deployments, defects and approvals even when multiple feeds describe them. Late arrivals produce versioned aggregate corrections; never silently overwrite a published result. Preserve occurrence and receipt times, reject impossible orderings and flag clock skew. Missing terminal events remain unresolved until the work owner reconciles them.
+
+Many-to-many task/attempt/skill/client associations preserve exact immutable versions. Unknown version stays null with a reason; never assign the latest revision retroactively. Client declarations, server facts and self-reports remain separately labeled. A skill-loaded event is evidence of loading only. The minimal prototype can operate without actor identity except where a lawful, necessary adoption denominator requires pseudonymous cohort membership.
+
+The privacy starting proposal is 30 days for raw structured analytics events and 12 months for aggregated trends, subject to the responsible owners' review. Keep the approved catalog/approval record for the supported revision's lifetime and its required audit period, which must be decided separately. Incident evidence uses a restricted, explicitly authorized hold and deletion schedule, not an indefinite analytics exception. Suppress reports below five people and prohibit drill-down or overlapping cohort slices that reconstruct identities. Five is a proposed minimum, not a guarantee against re-identification. No raw prompts, code, screens, customer cases or secrets are collected by default. Publish the purpose, lawful collection basis, access/deletion route and retention before collecting. Consent is not presumed to be an appropriate employment-law basis.
+
+## 7. Maintenance — skills-maintenance
+
+Every approved skill has an accountable owning team, independent reviewer, review due date, supported client matrix and rollback bundle. Review both usefulness and safety, not just metadata freshness. Proposed maximum review intervals are recorded by risk tier; incidents, dependency changes, model/client drift or repeated failures trigger earlier review.
+
+Data & AI reviews catalog health with the owning teams. Quality Engineering samples accepted outputs and adds confirmed failures to regression sets without exposing sensitive content. Platform & IT watches unsupported, deprecated and revoked revisions and tests distribution recovery. Architecture & Security reviews emerging misuse and exception expiry. Remove redundant or unused entries deliberately, after examining whether poor discoverability or fit explains non-use.
+
+A reported unsafe behavior opens an incident with artifact, policy and client versions. Architecture & Security coordinates containment; Platform & IT revokes authority, stops scheduling and quarantines affected revisions; the owning department handles customer or business consequences; Quality Engineering reproduces the failure; Data & AI coordinates catalog correction and trend analysis. Preserve minimal restricted evidence and involve People & Administration Squad for employee-data concerns and Finance & Accounting Squad for financial effects. Restart requires a reviewed fix, regression evidence, verified rollback/revocation and accountable human authorization. Closing the incident does not erase the historical failure from measurement.
+
+## 8. Roadmap — roadmap
+
+| Phase | Entry evidence | Work | Exit evidence and hold condition |
+| --- | --- | --- | --- |
+| Foundation | Strategy scope accepted for planning; existing teams identified. | Inventory actual client hosts/builds, provider/data terms, repositories, authority, owners and event availability; select low-risk workflows and metric definitions. | Named accountable people and independent reviewers, bounded pilot charter, forbidden actions, data/retention decision and reproducible baseline plan. Hold if accountability or lawful collection is unresolved. |
+| Governed skills pilot | Foundation evidence approved; no privileged autonomous effects. | Build a small registry, immutable contract, client adapters, evaluations, coaching and synthetic measurement verification. | Qualified client/skill tuples, mandatory safety checks, independent task acceptance, reconciled coverage and user feedback. Hold or narrow scope if quality or data coverage is inadequate. |
+| Reliable distribution | Pilot quality and usefulness support continuing. | Canary updates, effective-version readback, version locking, exception expiry, stale/offline handling and rollback. | Tested revocation and recovery, no bypass of central privileged gates, owners can support the catalog. Hold if effective versions or controls cannot be verified. |
+| Logical SDLC coordination | Distribution, authority and measurement evidence stable. | Observe and assemble evidence first, then propose and route work within scoped identities and budgets. | Exact-artifact approvals, idempotency, duplicate/outage recovery, separation of duties, audit and kill-switch drills pass; humans can take over. No authority expansion based on usage alone. |
+| Departmental expansion | Each department supplies a workflow owner, outcome, data boundary and capacity. | Add Operations, Marketing, Finance & Accounting and HR & Administration workflows with domain-specific review; Product and Technology continue quality improvement. | Departmental accepted outcomes, guardrails, total cost and experience justify continuation; sensitive decisions stay human. Stop or roll back workflows without adequate evidence. |
+
+There are no invented launch dates, budgets, staffing commitments or guaranteed gains. Phase gates permit narrowing or stopping. Re-evaluate earlier phases when the underlying client, provider, data scope or authority changes.
+
+## Internal architecture brief for implementer
+
+Use a small overview with six groups: (1) accountable people and approved work; (2) one logical coordinator and durable ledger; (3) governed registry plus qualified adapters; (4) local client contributors; (5) independent repository/CI/release boundary with separate human approval; (6) audit/measurement feedback. Put external model-provider access across a labeled data/egress boundary, with approved routing. Show registry-to-coordinator and registry-to-local-client distribution; coordinator-to-work proposals; clients-to-repository proposals; CI-to-human approval evidence; approval-to-release service; resulting evidence-to-audit and audit-to-people/coordinator feedback. Distinguish proposal/evidence arrows from authorization arrows. No coordinator-to-production or laptop-to-production edge. Diagram alt text must state target status, human accountability and lack of direct production authority. Keep full contract detail in prose, not tiny diagram boxes. Organization page links identify existing teams, not a new hierarchy.
+
+## Internal evidence mapping and open decisions
+
+Source IDs below refer to `research/ai-adoption/sources.json`. They support principles and documented capabilities, not local deployment or approval. Organization mapping was read from `repositories/documentation/docs/organization/{structure,collaboration,sdlc}.mdx` at `14ba1aa1ef66c91525135f743d15c77e32db78d3`.
+
+| Recommendation | Evidence | Design decision / limit |
+| --- | --- | --- |
+| Portable contract plus exact-client adapters | 1, 2, 4, 8, 9, 21, 26 | Content format is portable; precedence and enforcement are not. Vendored immutable distribution is the proposed default; no Gitea installer compatibility established. |
+| Independent gates, least privilege and human authority | 3, 5, 6, 7, 15, 23 | Central authorization and kill switch are target controls; local hooks are supplementary and may fail open. |
+| One logical coordinator, resilient task ledger and bounded authority | Task direction; 11, 15, 25 | Replica/idempotency/recovery topology is a design choice, not an observed installation or a vendor guarantee. |
+| Exact existing-team ownership | Three organization pages; findings section 5 | Assignments extend the documented model without asserting named staffing, capacity or approval. |
+| Immutable provenance, review, dependency checks and rollback | 1, 26, 15 | Approval digest and distribution manifest are proposed operational contracts. Pinning alone does not make content safe. |
+| Layered repeated evaluation and independent output checks | 11, 15 | Risk tiers, evaluation floors, review intervals and proposed percentages are local design defaults requiring ratification, not thresholds from the literature. |
+| Balanced KPIs and all five delivery measures | 12, 24 | Service/team evidence; no individual ranking or AI causal claim from activity. |
+| Comparative baseline, effort/elapsed distinction and no forecast ROI | 16, 17, 18, 22 | Studies vary by context; abstract-only evidence for 17/18 and known 2026 selection/timing limitations. Do not reproduce percentages as expected gains. |
+| Version-aware optional client telemetry | 19, 20, 23 | Actual licensing, settings and host coverage unknown; normalize only minimally necessary events. |
+| Lifecycle ownership, privacy and gates before expansion | 13, 14, 25; 20 | NIST voluntary framework is not certification; 14 inspected at landing-page level. Retention and cohort floor are proposals for review. |
+
+Open decisions (not blockers to writing target documentation; blockers to their corresponding rollout gates):
+
+1. Platform & IT with Architecture & Security: actual supported hosts/builds/OSs, identity boundaries, authoritative CI/release controls, protected-policy administration and stale-bundle access rule.
+2. Department leaders with Data & AI: named owner/reviewer/deputy coverage, pilot capacity and selected workflows; no new headcount is implied.
+3. Architecture & Security with People & Administration Squad and the relevant data owner: provider processing terms, data classification, lawful telemetry basis, retention, incident holds and access/deletion handling. Obtain specialist legal advice where needed; no new permanent legal role is invented.
+4. Quality Engineering with Data & AI and each workflow owner: ratify or replace the proposed risk-tier thresholds, task distributions, minimum samples, uncertainty criterion and quality follow-up windows before using them for promotion.
+5. Finance & Accounting Squad: cost allocation, currency normalization, treatment of shared licenses, effort sampling and confidence required for investment decisions.
+6. Product Management with departmental owners: business outcome hypotheses and whether a matched/randomized pilot is practical. No tool choice is coerced for an unreviewed experiment.
+7. Platform & IT: private registry distribution method, digest verification, revocation semantics, coordinator recovery and feasible minimal adapters. Do not assume vendor-preview installation or Cline SDK telemetry is already available.
+
+## Executable handoff and verification
+
+`build_strategy_model.py` writes the structured contract and illustrative values. `sample_calculations.py` is an executable reference/test plan using only labeled synthetic in-memory fixtures. The implementation child should port the same assertions into the documentation repository's established test tooling and add a CLI/fixture interface, rather than treating this reference as a production collector. Required cases are declared in the model. Do not ship research files or raw event fixtures into public static assets inadvertently.
+
+Acceptance for this synthesis: both requested files parse/exist; eight page IDs and all eleven existing teams are exact; every KPI has the full calculation/evidence/privacy contract; source IDs resolve; illustrative arithmetic is executed; synthetic edge-case tests pass; documentation repository remains unchanged. Publication, browser review, diagrams and production measurement infrastructure belong to the downstream implementation task, not this synthesis.

research/ai-adoption/strategy-coverage.json

@@ -0,0 +1,337 @@
+{
+  "purpose": "Route-level editorial and verification contract for connected Strategy; no deployed-result claims",
+  "routes": [
+    {
+      "source": "docs/strategy/baseline.mdx",
+      "route": "/strategy/baseline/",
+      "question": "What is the actual starting position of this workflow?",
+      "inputs": "Current-practice map, desired improvement and candidate contracts",
+      "action_or_decision": "Select feasible relevant evidence; confirm eligibility and gaps",
+      "output": "Traceable comparison record, not approval",
+      "next_or_feedback": "/strategy/skills-governance/",
+      "review": "Illustrative Delivery evidence handoff and return paths"
+    },
+    {
+      "source": "docs/strategy/measurement/approved-workflow-adoption.mdx",
+      "route": "/strategy/measurement/approved-workflow-adoption/",
+      "question": "Is the enrolled cohort using approved revisions in eligible work?",
+      "inputs": "skill.used; cohort.snapshot; optional qualified client adapter or declaration",
+      "action_or_decision": "Apply only if selected; preserve Consented or otherwise lawfully enrolled pilot cohort for the period; supported workflow available.",
+      "output": "percent; Show observed lower bound and telemetry/response coverage; missing usage unknown rather than non-use.",
+      "next_or_feedback": "/strategy/skills-adoption/",
+      "review": "Canonical contract and URL preserved; populations, exclusions, missingness and crosslinks reviewed",
+      "contract_sha256": "355996d5adb603021ba22f9e1f7f08f2fbea017dac9ee0a4bd42cc00bf7adea3",
+      "implementation": "unimplemented"
+    },
+    {
+      "source": "docs/strategy/measurement/change-fail-rate.mdx",
+      "route": "/strategy/measurement/change-fail-rate/",
+      "question": "How often do production deployments require immediate intervention?",
+      "inputs": "deployment.completed; deployment.failed; incident.linked; release and incident records",
+      "action_or_decision": "Apply only if selected; preserve Deployments with production effect during window and approved intervention follow-up horizon elapsed.",
+      "output": "percent; Known failures / all eligible deployments is a lower bound where incident linkage incomplete; label provisional and report unknown links.",
+      "next_or_feedback": "/strategy/skills-adoption/",
+      "review": "Canonical contract and URL preserved; populations, exclusions, missingness and crosslinks reviewed",
+      "contract_sha256": "d2a4ecaddd468f42db5824f9bfab8a8c8fcdf9157b33b4e4f047269a83c8567b",
+      "implementation": "prototype"
+    },
+    {
+      "source": "docs/strategy/measurement/change-lead-time.mdx",
+      "route": "/strategy/measurement/change-lead-time/",
+      "question": "How long does a service change take from commit to production?",
+      "inputs": "change.committed; deployment.completed; VCS immutable commit timestamps and release manifest",
+      "action_or_decision": "Apply only if selected; preserve Changes first successfully deployed to a service in reporting window; rollout retries collapse to same logical deployment.",
+      "output": "mean; Missing commit mapping or negative/skewed duration excluded from numeric sample, reported explicitly; no zero substitution.",
+      "next_or_feedback": "/strategy/skills-adoption/",
+      "review": "Canonical contract and URL preserved; populations, exclusions, missingness and crosslinks reviewed",
+      "contract_sha256": "96fd0edd5eba139a7c5905b606bcc96e608c5294acd2ef0c962fdb7d339d8251",
+      "implementation": "unimplemented"
+    },
+    {
+      "source": "docs/strategy/measurement/changes-with-escaped-quality-issues.mdx",
+      "route": "/strategy/measurement/changes-with-escaped-quality-issues/",
+      "question": "Which accepted changes have confirmed downstream defects?",
+      "inputs": "change.accepted; defect.confirmed; defect tracking and acceptance evidence",
+      "action_or_decision": "Apply only if selected; preserve Accepted changes in acceptance window whose follow-up is complete by as_of.",
+      "output": "percent; Unknown linkage is a coverage warning; no fabricated clean outcome. Show absolute defect and severe incident counts as well.",
+      "next_or_feedback": "/strategy/skills-adoption/",
+      "review": "Canonical contract and URL preserved; populations, exclusions, missingness and crosslinks reviewed",
+      "contract_sha256": "c436d504c8b3a9f655de18b2ca00fa8a0ab47ea1cf37637ff21561f81ecc77c9",
+      "implementation": "prototype"
+    },
+    {
+      "source": "docs/strategy/measurement/collection-and-safeguards.mdx",
+      "route": "/strategy/measurement/collection-and-safeguards/",
+      "question": "How can I collect and interpret selected evidence safely?",
+      "inputs": "Selected contracts, source inventory and approved collection purpose",
+      "action_or_decision": "Agree populations, deduplication, permissions and retention before collection",
+      "output": "Traceable lawful collection and interpretation contract",
+      "next_or_feedback": "/strategy/baseline/",
+      "review": "Linked to full journey; obsolete roadmap-gates link replaced only in safeguards; preserved arithmetic/privacy substance"
+    },
+    {
+      "source": "docs/strategy/measurement/confirmed-policy-effects.mdx",
+      "route": "/strategy/measurement/confirmed-policy-effects/",
+      "question": "Did eligible attempts produce prohibited effects?",
+      "inputs": "attempt.started; policy.violation; gate.blocked; security audit and incident triage",
+      "action_or_decision": "Apply only if selected; preserve Governed skill trials or supported workflow attempts, reported separately for eval and live populations.",
+      "output": "percent; Unknown outcomes remain visible; zero detected effects never proves safety. Missing audits make rate provisional.",
+      "next_or_feedback": "/strategy/skills-adoption/",
+      "review": "Canonical contract and URL preserved; populations, exclusions, missingness and crosslinks reviewed",
+      "contract_sha256": "b64c02f5516b08421fa8b816f0f490571afd05baf5ad6e9d92cb6a7b711ac82a",
+      "implementation": "prototype"
+    },
+    {
+      "source": "docs/strategy/measurement/cost-per-accepted-outcome.mdx",
+      "route": "/strategy/measurement/cost-per-accepted-outcome/",
+      "question": "What recorded total or partial cost supports each accepted outcome?",
+      "inputs": "cost.recorded; task.accepted; finance invoices, usage ledger, sampled effort with approved rates",
+      "action_or_decision": "Apply only if selected; preserve Matured eligible started-task cohort, with all attempt costs through as_of and allocated shared period costs.",
+      "output": "ratio; Missing cost buckets produce partial estimate plus coverage, not a total. Mixed currency requires dated approved conversion; zero accepted outcomes = null with full cost shown.",
+      "next_or_feedback": "/strategy/skills-adoption/",
+      "review": "Canonical contract and URL preserved; populations, exclusions, missingness and crosslinks reviewed",
+      "contract_sha256": "d8865ec31315d3c8398ec58cdb6665cb506a7d6309ebec3da0ca7dea84a5f406",
+      "implementation": "prototype"
+    },
+    {
+      "source": "docs/strategy/measurement/deployment-frequency.mdx",
+      "route": "/strategy/measurement/deployment-frequency/",
+      "question": "How frequently does this service deploy successfully?",
+      "inputs": "deployment.completed; authoritative deployment service",
+      "action_or_decision": "Apply only if selected; preserve Declared production services and complete UTC observation days; report each service before pooled views.",
+      "output": "ratio; Missing feed periods not zero; report coverage and no unqualified overall rate when period incomplete.",
+      "next_or_feedback": "/strategy/skills-adoption/",
+      "review": "Canonical contract and URL preserved; populations, exclusions, missingness and crosslinks reviewed",
+      "contract_sha256": "5a34ba52e5c2768e29a1a7574274e07a65509f75063e89ccc7ce1b035aeff4c5",
+      "implementation": "unimplemented"
+    },
+    {
+      "source": "docs/strategy/measurement/deployment-rework-rate.mdx",
+      "route": "/strategy/measurement/deployment-rework-rate/",
+      "question": "How much production deployment activity is corrective?",
+      "inputs": "deployment.completed; incident.linked; release intent classification",
+      "action_or_decision": "Apply only if selected; preserve Production deployment effects in window with immutable planned/unplanned classification and incident linkage.",
+      "output": "percent; Unknown classification stays denominator; observed numerator is lower bound until reconciliation; show classification coverage.",
+      "next_or_feedback": "/strategy/skills-adoption/",
+      "review": "Canonical contract and URL preserved; populations, exclusions, missingness and crosslinks reviewed",
+      "contract_sha256": "e8ade457136feac3ad39e9eba2a9d67142bc605727d9f4f038a7df6d5a0707fd",
+      "implementation": "prototype"
+    },
+    {
+      "source": "docs/strategy/measurement/failed-deployment-recovery-time.mdx",
+      "route": "/strategy/measurement/failed-deployment-recovery-time/",
+      "question": "How long did recovered deployment failures take to restore?",
+      "inputs": "deployment.failed; service.restored; incident service",
+      "action_or_decision": "Apply only if selected; preserve Production deployment failures beginning in window; latest verified restoration if a recovery is rescinded.",
+      "output": "mean; Unresolved failures reported separately and excluded only from recovered-duration distribution; prevent declaring improvement without their visibility.",
+      "next_or_feedback": "/strategy/skills-adoption/",
+      "review": "Canonical contract and URL preserved; populations, exclusions, missingness and crosslinks reviewed",
+      "contract_sha256": "489fd756883d4ccee1769fcfaa0b67725420463df2b1f6faf3e7faa7002f7a80",
+      "implementation": "unimplemented"
+    },
+    {
+      "source": "docs/strategy/measurement/index.mdx",
+      "route": "/strategy/measurement/",
+      "question": "Which evidence can support this workflow decision?",
+      "inputs": "Workflow question and available populations",
+      "action_or_decision": "Choose applicable contracts and connect fitness to Quality",
+      "output": "Selected definitions and limits, never mandatory full collection",
+      "next_or_feedback": "/strategy/baseline/",
+      "review": "Two tracks retained; fitness not reduced to health proxies"
+    },
+    {
+      "source": "docs/strategy/measurement/skill-selection-precision.mdx",
+      "route": "/strategy/measurement/skill-selection-precision/",
+      "question": "Were selected skills relevant to the labeled cases?",
+      "inputs": "eval.selection; versioned labeled corpus and runner",
+      "action_or_decision": "Apply only if selected; preserve All candidate/client labeled evaluation task-trials with known activation and relevance.",
+      "output": "percent; Unknown activation/relevance is unscorable; publish missing count and deny qualification if planned coverage incomplete.",
+      "next_or_feedback": "/strategy/skills-quality/",
+      "review": "Canonical contract and URL preserved; populations, exclusions, missingness and crosslinks reviewed",
+      "contract_sha256": "189e93e4e5f52a7e70e2045c6b824a9da621382f39ba8ce9a59c0c04812f0ce3",
+      "implementation": "prototype"
+    },
+    {
+      "source": "docs/strategy/measurement/skill-selection-recall.mdx",
+      "route": "/strategy/measurement/skill-selection-recall/",
+      "question": "Were expected skills found in relevant labeled cases?",
+      "inputs": "eval.selection; versioned labeled corpus and runner",
+      "action_or_decision": "Apply only if selected; preserve Independently labeled relevant evaluation task-trials for a skill/client tuple.",
+      "output": "percent; Report evaluation coverage; null if no relevant labeled tasks.",
+      "next_or_feedback": "/strategy/skills-quality/",
+      "review": "Canonical contract and URL preserved; populations, exclusions, missingness and crosslinks reviewed",
+      "contract_sha256": "847b5ba6094585eb88b8eb2b55b42e0f3c6822dcaa1629256ad0501a13eb7f18",
+      "implementation": "prototype"
+    },
+    {
+      "source": "docs/strategy/measurement/skills-within-substantive-review-window.mdx",
+      "route": "/strategy/measurement/skills-within-substantive-review-window/",
+      "question": "Which approved revisions have current ownership and substantive review?",
+      "inputs": "catalog.published; catalog.reviewed; catalog.deprecated; catalog.revoked; version inventory",
+      "action_or_decision": "Apply only if selected; preserve Approved revisions currently supported for use at as_of.",
+      "output": "percent; Missing owner/date/evidence outside numerator; show ownerless, deprecated-in-use and revoked-in-use absolute counts.",
+      "next_or_feedback": "/strategy/skills-maintenance/",
+      "review": "Canonical contract and URL preserved; populations, exclusions, missingness and crosslinks reviewed",
+      "contract_sha256": "339fe0da6b382a34c52b5ec6005ce08a7293a2b07ccd88540a6df03a02d96ad4",
+      "implementation": "unimplemented"
+    },
+    {
+      "source": "docs/strategy/measurement/supported-bundle-coverage.mdx",
+      "route": "/strategy/measurement/supported-bundle-coverage/",
+      "question": "Which expected installations have verified supported revisions?",
+      "inputs": "inventory.observed; catalog.published; catalog.revoked; device inventory",
+      "action_or_decision": "Apply only if selected; preserve Active installation inventory frozen for report, including invisible/offline entries until authoritative offboarding.",
+      "output": "percent; Unknown/stale versions count outside numerator, inside denominator. Show inventory discovery coverage versus eligible device roster; if roster unknown metric is provisional.",
+      "next_or_feedback": "/strategy/skills-maintenance/",
+      "review": "Canonical contract and URL preserved; populations, exclusions, missingness and crosslinks reviewed",
+      "contract_sha256": "8b4dc2dbdfb6999fac283814f518645d0830d515125910d79dd7dc8763f0521c",
+      "implementation": "unimplemented"
+    },
+    {
+      "source": "docs/strategy/measurement/synthetic-example.mdx",
+      "route": "/strategy/measurement/synthetic-example/",
+      "question": "How can I reproduce the arithmetic without claiming real results?",
+      "inputs": "Labeled synthetic fixture",
+      "action_or_decision": "Run the prototype and verify missingness",
+      "output": "Synthetic calculations with omissions, not baseline values",
+      "next_or_feedback": "/strategy/baseline/",
+      "review": "Linked to full journey; obsolete roadmap-gates link replaced only in safeguards; preserved arithmetic/privacy substance"
+    },
+    {
+      "source": "docs/strategy/measurement/validated-task-success.mdx",
+      "route": "/strategy/measurement/validated-task-success/",
+      "question": "Which matured workflow starts reached independent acceptance?",
+      "inputs": "task.started; task.accepted; task.failed; task.abandoned; task.cancelled; work-management acceptance record",
+      "action_or_decision": "Apply only if selected; preserve Tasks in a preregistered workflow cohort, started in window; each counted once across retries, skills and clients.",
+      "output": "percent; Unresolved/missing terminal outcomes remain in denominator with unknown count and known-outcome coverage; do not label them failed. Invalid/missing start excluded from calculation but flagged as orphan evidence.",
+      "next_or_feedback": "/strategy/skills-adoption/",
+      "review": "Canonical contract and URL preserved; populations, exclusions, missingness and crosslinks reviewed",
+      "contract_sha256": "925100f4c84f43e2cfdca4a89d6b4a984c808dae2d2ec5e57202318f70b9c544",
+      "implementation": "prototype"
+    },
+    {
+      "source": "docs/strategy/measurement/verification-confidence-and-cognitive-load.mdx",
+      "route": "/strategy/measurement/verification-confidence-and-cognitive-load/",
+      "question": "Can the cohort confidently verify work without excessive perceived load?",
+      "inputs": "survey.response; anonymous survey with single-use token and aggregate invitation count",
+      "action_or_decision": "Apply only if selected; preserve Invited eligible cohort at fixed survey wave; voluntary responses.",
+      "output": "mean; Report valid response count / invited count and item nonresponse; no imputation. Suppress people cohorts below five.",
+      "next_or_feedback": "/strategy/skills-adoption/",
+      "review": "Canonical contract and URL preserved; populations, exclusions, missingness and crosslinks reviewed",
+      "contract_sha256": "01e017471004c5f780fd0c2671a4d4449d392956cb4c5f0bd7791959d6a9af9a",
+      "implementation": "prototype"
+    },
+    {
+      "source": "docs/strategy/measurement/workflow-specific-business-acceptance.mdx",
+      "route": "/strategy/measurement/workflow-specific-business-acceptance/",
+      "question": "Did a named workflow meet its departmental acceptance rubric?",
+      "inputs": "task.started; business.accepted; departmental case/content/reconciliation/onboarding review record",
+      "action_or_decision": "Apply only if selected; preserve One named departmental workflow and predeclared start cohort; never pool unlike rubrics.",
+      "output": "percent; Unknown follow-up stays denominator with unresolved count; no claim actual business outcome changed without source evidence.",
+      "next_or_feedback": "/strategy/skills-adoption/",
+      "review": "Canonical contract and URL preserved; populations, exclusions, missingness and crosslinks reviewed",
+      "contract_sha256": "55fce8843409a1bc1383fef3cee5b9a616b44fa8d45ba84c6e4ed490a25f2de4",
+      "implementation": "unimplemented"
+    },
+    {
+      "source": "docs/strategy/roadmap.mdx",
+      "route": "/strategy/roadmap/",
+      "question": "How do practices and skills progress toward controlled autonomous capabilities?",
+      "inputs": "Long-term Target and evidence from actual work",
+      "action_or_decision": "Delivery first; later phase order undecided; separate authority decision",
+      "output": "Broad progression with no fixed dates",
+      "next_or_feedback": "/strategy/six-months-target/",
+      "review": "Historical three-level roadmap restored, distinct from monthly plan"
+    },
+    {
+      "source": "docs/strategy/skills-adoption.mdx",
+      "route": "/strategy/skills-adoption/",
+      "question": "Should a qualified skill become a retained workflow?",
+      "inputs": "Baseline, qualification and explicit bounded-pilot authorization",
+      "action_or_decision": "Run comparable real work; owner decides retain/improve/expand/stop",
+      "output": "Decision record; retained revision requires exact-scope approval",
+      "next_or_feedback": "/strategy/skills-maintenance/",
+      "review": "Manual path and feedback to author/Quality/Baseline"
+    },
+    {
+      "source": "docs/strategy/skills-governance.mdx",
+      "route": "/strategy/skills-governance/",
+      "question": "Who may authorize which revision for which use?",
+      "inputs": "Workflow map, candidate topology and risk boundary",
+      "action_or_decision": "Name people, independent reviewers and staged permissions",
+      "output": "Pinned candidate, bounded-pilot authorization then exact-scope approval",
+      "next_or_feedback": "/strategy/skills-quality/",
+      "review": "Reconciled disposable qualification, authorized pilot and wider use"
+    },
+    {
+      "source": "docs/strategy/skills-maintenance.mdx",
+      "route": "/strategy/skills-maintenance/",
+      "question": "How do retained skills remain useful and safe?",
+      "inputs": "Approved manifest, outcomes, failures and client/model drift",
+      "action_or_decision": "Continue authorized use, requalify, contain or retire",
+      "output": "Support/recovery evidence, regression cases or migration record",
+      "next_or_feedback": "/strategy/skills-quality/",
+      "review": "Fitness/regression beyond metadata health; no automatic autonomy"
+    },
+    {
+      "source": "docs/strategy/skills-quality.mdx",
+      "route": "/strategy/skills-quality/",
+      "question": "Is the named candidate fit and non-regressing?",
+      "inputs": "Pinned revision/client, declared cases and acceptance rules",
+      "action_or_decision": "Independent fitness/safety/regression evaluation; recommend pilot or hold",
+      "output": "Versioned qualification report with failures and limits",
+      "next_or_feedback": "/strategy/skills-adoption/",
+      "review": "Separates artifact trial population from matured live tasks"
+    },
+    {
+      "source": "docs/strategy/stage-01-skills-adoption.mdx",
+      "route": "/strategy/stage-01-skills-adoption/",
+      "question": "How do reusable lifecycle activities hand off evidence?",
+      "inputs": "Workflow problem, people and current evidence",
+      "action_or_decision": "Baseline, qualify, authorize pilot, compare and maintain; link canonical EXP-01 in six-month roadmap",
+      "output": "Lifecycle reference and feedback paths, not a competing plan",
+      "next_or_feedback": "/strategy/baseline/",
+      "review": "New native dependency story plus evidence handoffs"
+    },
+    {
+      "source": "docs/strategy/stage-02-autonomous-agent.mdx",
+      "route": "/strategy/stage-02-autonomous-agent/",
+      "question": "Is additional autonomous authority justified and recoverable?",
+      "inputs": "Proven Stage01 practices, limits and explicit operation proposal",
+      "action_or_decision": "Existing designated functions assess scope, enforcement and takeover",
+      "output": "Recorded hold or conditional bounded authority",
+      "next_or_feedback": "/strategy/stage-01-skills-adoption/",
+      "review": "New authority boundary diagram and return-to-Stage01 path"
+    },
+    {
+      "source": "docs/strategy/target-operating-model.mdx",
+      "route": "/strategy/target-operating-model/",
+      "question": "What is the long-term human-controlled autonomous SDLC destination?",
+      "inputs": "Original agreed topology and human direction",
+      "action_or_decision": "Preserve ambition with independent controls and no present authority",
+      "output": "Long-term operating model, not six-month promise",
+      "next_or_feedback": "/strategy/roadmap/",
+      "review": "Original topology restored from pre-PR38; safeguards retained"
+    },
+    {
+      "source": "docs/strategy/six-months-target.mdx",
+      "route": "/strategy/six-months-target/",
+      "question": "What six-month strategy answers the AI Architect assignment?",
+      "inputs": "Full PDF facts; explicitly unknown stack, processes and capacity",
+      "action_or_decision": "Improve current AI-assisted engineering output with the smallest suitable intervention",
+      "output": "Realistic month-six scenario, assumptions register and 35+15-minute presentation narrative",
+      "next_or_feedback": "/strategy/six-months-roadmap/",
+      "review": "PDF assignment retained independently of long-term destination; EXP-01 lives in six-month action plan"
+    },
+    {
+      "source": "docs/strategy/six-months-roadmap.mdx",
+      "route": "/strategy/six-months-roadmap/",
+      "question": "What does a solo architect do month by month without team authority?",
+      "inputs": "PDF constraints, current AI practice, willing partners and unknown capacity",
+      "action_or_decision": "Month 1–6 discovery, bounded experiment, compare, selective transfer and CTO investment decision",
+      "output": "Proposed six-month plan with dependencies, evidence, capacity and stop choices",
+      "next_or_feedback": "/strategy/stage-02-autonomous-agent/",
+      "review": "PDF assignment retained independently of long-term destination; EXP-01 lives in six-month action plan"
+    }
+  ]
+}

research/organization/department-migration.json

@@ -0,0 +1,41 @@
+{
+  "sourceCommit": "88a43757762114a506f57ed4b44484306cae1aaa",
+  "departments": [
+    {
+      "label": "Product",
+      "slug": "product",
+      "bodySha256": "b7fd948091dbd7b7c2f51d494a5e83241a53c5d1d9b751267102a6c97ad29bd9",
+      "rows": 2
+    },
+    {
+      "label": "Technology",
+      "slug": "technology",
+      "bodySha256": "a74405d41a58b43e4e8ffbb0e98f835d25d80c6ab2ef9f314925832280c038d3",
+      "rows": 5
+    },
+    {
+      "label": "Operations",
+      "slug": "operations",
+      "bodySha256": "03254f56a3ea8e353a5d9b65c0342954bf65edec59073d20fb1ceaaf31d683c7",
+      "rows": 4
+    },
+    {
+      "label": "Marketing",
+      "slug": "marketing",
+      "bodySha256": "424d7c1d147472ced3b73eb8041048a982ce10330a51246ca35bed0cd150e633",
+      "rows": 6
+    },
+    {
+      "label": "Finance & Accounting",
+      "slug": "finance-accounting",
+      "bodySha256": "ffdacb9930114a6caf25a475bb207dcb58f27c13e08fb04e098ef1e30ea538a9",
+      "rows": 3
+    },
+    {
+      "label": "HR & Administration",
+      "slug": "hr-administration",
+      "bodySha256": "e663ca1c7b7fe83cff70d6e33235591fa082304d201dc4538235cc1a341ffd3c",
+      "rows": 3
+    }
+  ]
+}

scripts/ai-kpi.mjs

@@ -0,0 +1,143 @@
+#!/usr/bin/env node
+/** SYNTHETIC reference only. No collectors, network access or production authorization.
+ * Input is a deliberately simplified, reconciled fixture, NOT a production event schema.
+ * Conflicts fail closed (no output); reconciliation/quarantine storage is not implemented.
+ */
+import { readFileSync } from 'node:fs';
+import { pathToFileURL } from 'node:url';
+export const LABEL = 'SYNTHETIC — illustrative, not Eldorado observations';
+export const CALCULATION_VERSION = 'synthetic-1.0.0';
+export const ratio = (n, d, scale = 100) => d === 0 ? null : n / d * scale;
+export function time(value) {
+  if (typeof value !== 'string' || !/^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(?:\.\d{1,3})?(?:Z|\+00:00)$/.test(value)) throw new Error('UTC timestamp required');
+  const t = Date.parse(value);
+  if (!Number.isFinite(t) || new Date(t).toISOString().slice(0,19) !== value.slice(0,19)) throw new Error('Invalid timestamp');
+  return t;
+}
+const canonical = value => JSON.stringify(value, (_, v) => v && typeof v === 'object' && !Array.isArray(v) ? Object.fromEntries(Object.entries(v).sort(([a],[b]) => a.localeCompare(b))) : v);
+const without = (row, keys) => Object.fromEntries(Object.entries(row).filter(([k]) => !keys.includes(k)));
+export function dedup(events) {
+  const kept = new Map();
+  for (const e of events) {
+    if (!e.producer || !e.event_id) throw new Error('Missing transport identity');
+    if (time(e.received_at) < time(e.occurred_at)) throw new Error('Receipt before occurrence');
+    const key = canonical([e.producer, e.event_id]), prior = kept.get(key);
+    if (prior && canonical(without(prior,['received_at'])) !== canonical(without(e,['received_at']))) throw new Error('Conflicting duplicate requires quarantine');
+    if (!prior || time(e.received_at) < time(prior.received_at)) kept.set(key,e);
+  }
+  return [...kept.values()];
+}
+function result(n, d, as_of, {unit = '%', scale = 100, unknown = 0, exclusions = {}, ...extra} = {}) {
+  return {label:LABEL, as_of, calculation_version:CALCULATION_VERSION, numerator:n, denominator:d, unit, value_or_null:ratio(n,d,scale), unknown_count:unknown, exclusions, coverage:{known_percent:ratio(d-unknown,d)}, warnings:unknown ? ['Unknown records remain visible; this is not a failure/non-use rate.'] : [], ...extra};
+}
+function taskCohort(events, start, end, as_of) {
+  const lo=time(start), hi=time(end), cutoff=time(as_of);
+  if (lo >= hi) throw new Error('Invalid half-open window');
+  const starts=new Map(), terminal=new Map();
+  for (const e of dedup(events)) {
+    if (time(e.occurred_at)>cutoff || time(e.received_at)>cutoff) continue;
+    if (e.event_type.startsWith('task.') && !e.task_id) throw new Error('Missing task ID');
+    if (e.event_type==='task.started') {
+      if (!Number.isFinite(e.horizon_hours) || e.horizon_hours<0) throw new Error('Missing/invalid observation horizon');
+      const prior=starts.get(e.task_id);
+      if (prior && (time(prior.occurred_at)!==time(e.occurred_at) || prior.horizon_hours!==e.horizon_hours)) throw new Error('Conflicting semantic task start');
+      starts.set(e.task_id,e);
+    } else if (['task.accepted','task.failed','task.abandoned','task.cancelled'].includes(e.event_type)) {
+      if (e.event_type==='task.accepted' && e.independent_evidence!==true) continue;
+      const prior=terminal.get(e.task_id);
+      if (prior && prior.event_type!==e.event_type) throw new Error('Conflicting task terminal state');
+      if (!prior || time(e.occurred_at)<time(prior.occurred_at)) terminal.set(e.task_id,e);
+    }
+  }
+  for (const [id,e] of terminal) if (starts.has(id) && time(e.occurred_at)<time(starts.get(id).occurred_at)) throw new Error('Terminal before start');
+  const eligible = new Set([...starts].filter(([,e]) => time(e.occurred_at)>=lo && time(e.occurred_at)<hi && time(e.occurred_at)+e.horizon_hours*3600000<=cutoff).map(([id])=>id));
+  return {starts, terminal, eligible};
+}
+// Snapshot rows are pre-reconciled at fixture as_of. Optional receipt/occurrence
+// timestamps support late-record tests; missing timestamps are NOT inferred events.
+function unique(rows, fields=['id']) {
+  const map=new Map();
+  for (const r of rows) {
+    if (fields.some(k=>typeof r[k]!=='string' || !r[k])) throw new Error('Missing semantic identity');
+    const key=canonical(fields.map(k=>r[k])), payload=without(r,['producer','event_id','received_at']);
+    if (map.has(key) && canonical(without(map.get(key),['producer','event_id','received_at']))!==canonical(payload)) throw new Error('Semantic conflict requires reconciliation');
+    const prior=map.get(key);
+    if (!prior || (r.received_at && prior.received_at && time(r.received_at)<time(prior.received_at))) map.set(key,r);
+  }
+  return [...map.values()];
+}
+const visible = (r, as_of) => (!r.received_at || time(r.received_at)<=time(as_of)) && (!r.occurred_at || time(r.occurred_at)<=time(as_of));
+const within = (t,start,end) => time(t)>=time(start) && time(t)<time(end);
+function horizon(r) {
+  if (!Number.isFinite(r.followup_hours) || r.followup_hours<0) throw new Error('Missing/invalid followup horizon');
+  return r.followup_hours*3600000;
+}
+export function association(rows) {
+  const map=new Map();
+  for (const r of rows) {
+    const tuple={skill_id:r.skill_id,revision:r.revision ?? null,version_status:!Object.hasOwn(r,'revision') ? 'missing' : r.revision===null ? 'unknown' : 'known',client:r.client,missing_reason:r.missing_reason ?? null};
+    if (!map.has(r.task_id)) map.set(r.task_id,new Map());
+    map.get(r.task_id).set(canonical(tuple),tuple);
+  }
+  return Object.fromEntries([...map].map(([id, tuples])=>[id,[...tuples.values()].sort((a,b)=>canonical(a).localeCompare(canonical(b)))]));
+}
+export function deployments(rows) {
+  const effects=unique(rows,['service_id','deployment_id']).filter(r=>r.environment==='production' && r.production_effect===true);
+  return {effects:effects.length,successful:effects.filter(r=>r.succeeded===true).length,change_fail_rate:ratio(effects.filter(r=>r.intervention===true).length,effects.length),rework_rate:ratio(effects.filter(r=>r.planned===false && Boolean(r.incident_id)).length,effects.length)};
+}
+export function matureDefects(changes,defects,as_of,start='0001-01-01T00:00:00Z',end=as_of) {
+  const eligible=unique(changes).filter(c=>visible(c,as_of) && within(c.accepted_at,start,end) && time(c.accepted_at)+horizon(c)<=time(as_of));
+  const affected=new Set();
+  for (const d of unique(defects)) {
+    const c=eligible.find(c=>c.id===d.change_id);
+    if (c && d.confirmed===true && visible(d,as_of) && time(d.detected_at)>=time(c.accepted_at) && time(d.detected_at)<=time(c.accepted_at)+horizon(c)) affected.add(c.id);
+  }
+  return [affected.size,eligible.length];
+}
+export function survey(rows,invited,as_of) {
+  if (!Number.isInteger(invited) || invited<0) throw new Error('Invalid invitation count');
+  const all=unique(rows), valid=all.filter(r=>Number.isInteger(r.score) && r.score>=1 && r.score<=5);
+  if (all.length>invited) throw new Error('Responses exceed invitations');
+  const suppressed=valid.length<5;
+  return result(suppressed?null:valid.reduce((n,r)=>n+r.score,0),valid.length,as_of,{unit:'points (1–5)',scale:1,value_or_null:suppressed?null:ratio(valid.reduce((n,r)=>n+r.score,0),valid.length,1),suppressed,exclusions:{invalid_answers:all.length-valid.length},coverage:{response_percent:ratio(valid.length,invited)},distribution:suppressed?null:Object.fromEntries([1,2,3,4,5].map(s=>[s,valid.filter(r=>r.score===s).length])),warnings:suppressed?['People cohort below five suppressed.']:[]});
+}
+export function calculate(f) {
+  if (f.synthetic!==true || f.schema_version!=='1.0') throw new Error('Explicit synthetic schema 1.0 fixture required');
+  const {start,end,as_of}=f, kpis={};
+  kpis['validated-task-success']=success(f.events,start,end,as_of);
+  const trials=unique(f.selection).filter(r=>visible(r,as_of));
+  const scored=trials.filter(r=>typeof r.relevant==='boolean' && typeof r.activated==='boolean');
+  const tp=scored.filter(r=>r.relevant && r.activated).length;
+  for (const [id,den] of [['selection-precision',scored.filter(r=>r.activated).length],['selection-recall',scored.filter(r=>r.relevant).length]]) {
+    kpis[id]=result(tp,den,as_of,{unknown:trials.length-scored.length,coverage:{scorable_percent:ratio(scored.length,trials.length)},exclusions:{unscorable:trials.length-scored.length}});
+  }
+  const effects=unique(f.deployments,['service_id','deployment_id']).filter(r=>visible(r,as_of) && r.environment==='production' && r.production_effect===true && within(r.deployed_at,start,end));
+  const mature=effects.filter(r=>time(r.deployed_at)+horizon(r)<=time(as_of));
+  kpis['change-fail-rate']=result(mature.filter(r=>r.intervention===true).length,mature.length,as_of,{unknown:mature.filter(r=>typeof r.intervention!=='boolean').length,exclusions:{immature:effects.length-mature.length}});
+  kpis['deployment-rework-rate']=result(effects.filter(r=>r.planned===false && Boolean(r.incident_id)).length,effects.length,as_of,{unknown:effects.filter(r=>typeof r.planned!=='boolean' || (r.planned===false && !Object.hasOwn(r,'incident_id'))).length});
+  const [affected,accepted]=matureDefects(f.changes,f.defects,as_of,start,end);
+  const matureChanges=unique(f.changes).filter(r=>visible(r,as_of) && within(r.accepted_at,start,end) && time(r.accepted_at)+horizon(r)<=time(as_of));
+  kpis['escaped-quality-rate']=result(affected,accepted,as_of,{unknown:matureChanges.filter(r=>r.linkage_complete!==true).length,exclusions:{outside_window_immature_or_late:unique(f.changes).length-matureChanges.length},pending_triage_count:unique(f.defects).filter(r=>visible(r,as_of) && r.confirmed!==true).length});
+  const attempts=unique(f.attempts).filter(r=>visible(r,as_of));
+  kpis['policy-effects']=result(attempts.filter(r=>r.actual_effect===true).length,attempts.length,as_of,{unknown:attempts.filter(r=>typeof r.actual_effect!=='boolean').length,blocked_count:attempts.filter(r=>r.blocked===true).length});
+  const {eligible}=taskCohort(f.events,start,end,as_of);
+  const costs=unique(f.costs).filter(r=>visible(r,as_of) && (eligible.has(r.task_id) || r.task_id==='shared_pool'));
+  if (costs.some(r=>r.currency!==f.currency || !Number.isFinite(r.amount) || r.amount<0)) throw new Error('Invalid cost or mixed currency: approved conversion required');
+  const missing=f.expected_cost_buckets.filter(b=>!costs.some(r=>r.bucket===b));
+  kpis['cost-per-accepted-outcome']=result(costs.reduce((sum,r)=>sum+r.amount,0),kpis['validated-task-success'].numerator,as_of,{scale:1,unit:`${f.currency}/accepted outcome`,partial_estimate:missing.length>0,coverage:{missing_cost_buckets:missing},warnings:missing.length?['Partial estimate, not total cost; missing cost buckets.']:[]});
+  kpis['human-experience']=survey(f.survey.responses.filter(r=>visible(r,as_of)),f.survey.invited,as_of);
+  return {label:LABEL,as_of,calculation_version:CALCULATION_VERSION,window:{start,end},kpis,associations:association(f.associations),not_implemented:['supported-bundle-coverage','useful-adoption','change-lead-time','deployment-frequency','failed-deployment-recovery-time','maintenance-health','department-outcome'],limitations:['Synthetic simplified reconciled snapshots only; not the full production event envelope.','Snapshot rows without timestamps are assumed frozen at as_of, not missing-event evidence.','No causal attribution, uncertainty intervals, authorization or telemetry collection.','Survey implements primary item only; no cross-slice disclosure protection.','Defect severity strata and policy severity counts are not implemented.']};
+}
+if (process.argv[1] && import.meta.url===pathToFileURL(process.argv[1]).href) {
+  try {
+    if (process.argv.length>3) throw new Error('Usage: node scripts/ai-kpi.mjs [synthetic-fixture.json]');
+    const source=process.argv[2] ?? new URL('./fixtures/ai-kpi-synthetic.json',import.meta.url);
+    console.log(JSON.stringify(calculate(JSON.parse(readFileSync(source,'utf8'))),null,2));
+  } catch (error) { console.error(`Synthetic KPI calculation failed: ${error.message}`); process.exitCode=1; }
+}
+export function success(events,start,end,as_of) {
+  const {starts,terminal,eligible}=taskCohort(events,start,end,as_of);
+  const n=[...eligible].filter(id=>terminal.get(id)?.event_type==='task.accepted').length;
+  const unknown=[...eligible].filter(id=>!terminal.has(id)).length;
+  return result(n,eligible.size,as_of,{unknown, known_outcome_coverage:ratio(eligible.size-unknown,eligible.size), orphan_terminal_count:[...terminal.keys()].filter(id=>!starts.has(id)).length, excluded_start_count:starts.size-eligible.size, exclusions:{outside_window_or_immature:starts.size-eligible.size}});
+}

scripts/ai-kpi.test.mjs

@@ -0,0 +1,153 @@
+import test from 'node:test';
+import assert from 'node:assert/strict';
+import { existsSync, readFileSync } from 'node:fs';
+const moduleUrl = new URL('./ai-kpi.mjs', import.meta.url);
+import { spawnSync } from 'node:child_process';
+import * as api from './ai-kpi.mjs';
+const fixture = () => JSON.parse(readFileSync(new URL('./fixtures/ai-kpi-synthetic.json', import.meta.url)));
+test('semantic change duplicates preserve the complete quality report including exclusions', () => {
+  const original = fixture();
+  const repeated = fixture();
+  repeated.changes.push({...repeated.changes[0]});
+  assert.deepEqual(api.calculate(repeated).kpis['escaped-quality-rate'], api.calculate(original).kpis['escaped-quality-rate']);
+});
+test('CLI report exposes implemented KPI contracts and explicit omissions', async () => {
+  const m = await import(moduleUrl);
+  assert.equal(typeof m.calculate, 'function');
+  const r = m.calculate(fixture());
+  assert.equal(Object.keys(r.kpis).length, 9);
+  assert.equal(r.not_implemented.length, 7);
+  assert.equal(r.kpis['cost-per-accepted-outcome'].value_or_null, 60);
+  assert.equal(r.kpis['selection-precision'].value_or_null, 50);
+  assert.equal(r.kpis['selection-recall'].value_or_null, 50);
+  assert.equal(r.kpis['change-fail-rate'].value_or_null, 100);
+  assert.equal(r.kpis['deployment-rework-rate'].value_or_null, 100);
+  assert.equal(r.kpis['escaped-quality-rate'].value_or_null, 100);
+  assert.equal(r.kpis['policy-effects'].value_or_null, 50);
+  assert.equal(r.kpis['human-experience'].value_or_null, 4);
+});
+function event(id,task,kind,day=1,extra={}) {
+  const timestamp=`2026-01-${String(day).padStart(2,'0')}T00:00:00Z`;
+  return {producer:'synthetic',event_id:id,task_id:task,event_type:kind,occurred_at:timestamp,received_at:timestamp,...extra};
+}
+const run = (events,as_of=fixture().as_of) => api.success(events,fixture().start,fixture().end,as_of);
+test('transport duplicates and redelivery use earliest receipt in either order',()=>{
+  const f=fixture(), duplicate={...f.events[0],received_at:'2026-01-06T00:00:00Z'};
+  assert.deepEqual(run([...f.events,f.events[0]]),run(f.events));
+  assert.deepEqual(run([...f.events,duplicate]),run(f.events));
+  assert.deepEqual(run([duplicate,...f.events]),run(f.events));
+});
+test('transport conflicts fail closed',()=>assert.throws(()=>run([...fixture().events,{...fixture().events[0],task_id:'other'}]),/Conflicting duplicate/));
+test('retry and cross-feed semantic duplicate never add tasks',()=>{
+  const f=fixture();
+  assert.equal(run([...f.events,event('retry','accepted','attempt.started',2),event('retry-fail','accepted','attempt.failed',2),{...f.events[0],producer:'mirror',event_id:'mirror-start'}]).denominator,4);
+});
+test('immature task and half-open end excluded',()=>{
+  const r=run([...fixture().events,event('boundary','boundary','task.started',5,{horizon_hours:0})]);
+  assert.equal(r.excluded_start_count,2);
+  assert.equal(r.denominator,4);
+});
+test('all implemented zero denominator values are null',()=>{
+  const f=fixture();
+  for (const k of ['events','selection','deployments','changes','defects','attempts','costs','associations']) f[k]=[];
+  f.survey={invited:0,responses:[]};
+  for (const r of Object.values(api.calculate(f).kpis)) assert.equal(r.value_or_null,null);
+});
+test('orphan terminal does not increase accepted count',()=>{
+  const r=run([...fixture().events,event('orphan','absent','task.accepted',2,{independent_evidence:true})]);
+  assert.equal(r.orphan_terminal_count,1); assert.equal(r.numerator,1);
+});
+test('late arrival restates only when received',()=>{
+  const events=[...fixture().events,event('late','unknown','task.accepted',3,{independent_evidence:true,received_at:'2026-01-06T00:00:00Z'})];
+  assert.equal(run(events).numerator,1);
+  assert.equal(run(events,'2026-01-06T00:00:00Z').numerator,2);
+});
+test('unknown, absent and mixed versions retained without latest inference',()=>{
+  const rows=['a','b','a',null].map(revision=>({task_id:'t',skill_id:'s',revision,client:'Cline'}));
+  rows.push({task_id:'t',skill_id:'s',client:'Cline'});
+  const r=api.association(rows).t;
+  assert.equal(r.length,4);
+  assert.equal(r.filter(x=>x.version_status==='known').length,2);
+  assert.deepEqual(new Set(r.filter(x=>x.revision===null).map(x=>x.version_status)),new Set(['missing','unknown']));
+});
+test('invalid timestamps, UTC offsets, receipt order and terminal order rejected',()=>{
+  for(const t of ['no','2026-02-30T00:00:00Z','2026-01-01T00:00:00+01:00']) assert.throws(()=>api.time(t));
+  assert.throws(()=>run([event('s','t','task.started',2,{horizon_hours:24}),event('a','t','task.accepted',1,{independent_evidence:true})]),/Terminal before start/);
+  assert.throws(()=>api.dedup([event('s','t','task.started',2,{received_at:'2026-01-01T00:00:00Z'})]),/Receipt before/);
+});
+test('missing horizon is not silently mature',()=>assert.throws(()=>run([event('s','t','task.started')]),/horizon/));
+test('conflicting terminal and semantic start require reconciliation',()=>{
+  assert.throws(()=>run([...fixture().events,event('conflict','accepted','task.failed',3)]),/Conflicting task terminal/);
+  assert.throws(()=>run([...fixture().events,event('conflict','accepted','task.started',2,{horizon_hours:48})]),/semantic task start/);
+});
+test('no independent acceptance evidence means unknown, not accepted',()=>{
+  const r=run([event('s','t','task.started',1,{horizon_hours:24}),event('a','t','task.accepted',2)]);
+  assert.equal(r.numerator,0); assert.equal(r.unknown_count,1);
+});
+test('pre-start cancellation excluded; post-start cancellation remains denominator',()=>{
+  const r=run([event('pre','never','task.cancelled',1,{before_start:true}),event('s','started','task.started',1,{horizon_hours:24}),event('post','started','task.cancelled',2,{before_start:false})]);
+  assert.deepEqual([r.numerator,r.denominator,r.unknown_count],[0,1,0]);
+});
+test('deployment retries collapse; unknown rework not treated as planned',()=>{
+  const row=fixture().deployments[0];
+  assert.deepEqual(api.deployments([row,{...row,producer:'mirror',event_id:'2'}]),{effects:1,successful:1,change_fail_rate:100,rework_rate:100});
+  assert.equal(api.deployments([{...row,planned:null}]).rework_rate,0);
+  const f=fixture(); f.deployments[0].planned=null;
+  const r=api.calculate(f).kpis['deployment-rework-rate'];
+  assert.equal(r.denominator,1); assert.equal(r.unknown_count,1);
+  assert.throws(()=>api.deployments([row,{...row,planned:true}]),/Semantic conflict/);
+});
+test('mature deployment denominator retains unsuccessful production effects',()=>{
+  const f=fixture(); f.deployments[0].succeeded=false;
+  assert.equal(api.calculate(f).kpis['change-fail-rate'].denominator,1);
+  f.deployments[0].followup_hours=1000;
+  assert.equal(api.calculate(f).kpis['change-fail-rate'].denominator,0);
+});
+test('mature defect followup is linked, bounded and deduplicated',()=>{
+  const f=fixture();
+  f.changes.push({id:'new',accepted_at:'2026-01-04T00:00:00Z',followup_hours:48});
+  f.defects.push({...f.defects[0],id:'new-defect',change_id:'new'});
+  assert.deepEqual(api.matureDefects(f.changes,[...f.defects,f.defects[0]],f.as_of),[1,1]);
+  f.defects[0].detected_at='2026-01-04T00:00:00Z';
+  assert.deepEqual(api.matureDefects(f.changes,f.defects,f.as_of),[0,1]);
+});
+test('cost includes failed attempts, flags partial buckets and rejects mixed currencies',()=>{
+  const f=fixture(); let r=api.calculate(f).kpis['cost-per-accepted-outcome'];
+  assert.equal(r.numerator,60); assert.equal(r.partial_estimate,true);
+  f.costs.push({...f.costs[0]});
+  assert.equal(api.calculate(f).kpis['cost-per-accepted-outcome'].numerator,60);
+  f.costs.pop(); // Currency validation is separate from conflicting duplicate validation.
+  f.costs[0].currency='USD'; assert.throws(()=>api.calculate(f),/mixed currency/);
+});
+test('blocked attempts are not prohibited effects; unknown audits remain denominator',()=>{
+  const f=fixture(); f.attempts.push({id:'unknown'});
+  const r=api.calculate(f).kpis['policy-effects'];
+  assert.deepEqual([r.numerator,r.denominator,r.blocked_count,r.unknown_count],[1,3,1,1]);
+});
+test('survey suppresses small groups including sum and distribution',()=>{
+  const f=fixture(), r=api.survey(f.survey.responses.slice(0,4),10,f.as_of);
+  assert.equal(r.value_or_null,null); assert.equal(r.numerator,null); assert.equal(r.distribution,null);
+});
+test('required output fields accompany every implemented KPI',()=>{
+  const required=['label','as_of','calculation_version','numerator','denominator','unit','value_or_null','unknown_count','exclusions','coverage','warnings'];
+  for (const r of Object.values(api.calculate(fixture()).kpis)) for(const key of required) assert.ok(Object.hasOwn(r,key),key);
+});
+test('non-synthetic and unknown fixture schemas rejected',()=>{
+  assert.throws(()=>api.calculate({...fixture(),synthetic:false}),/synthetic/);
+  assert.throws(()=>api.calculate({...fixture(),schema_version:'future'}),/schema/);
+});
+test('CLI executes default and explicit fixture and fails visibly for missing input',()=>{
+  for(const args of [[],[new URL('./fixtures/ai-kpi-synthetic.json',import.meta.url).pathname]]) {
+    const r=spawnSync(process.execPath,[moduleUrl.pathname,...args],{encoding:'utf8'});
+    assert.equal(r.status,0,r.stderr); assert.equal(JSON.parse(r.stdout).kpis['validated-task-success'].value_or_null,25);
+  }
+  const r=spawnSync(process.execPath,[moduleUrl.pathname,'/nonexistent/synthetic-fixture.json'],{encoding:'utf8'});
+  assert.equal(r.status,1); assert.equal(r.stdout,''); assert.match(r.stderr,/failed/);
+});
+test('synthetic task calculator exists and retains failed, abandoned, unknown tasks', async () => {
+  assert.ok(existsSync(moduleUrl), 'calculator implementation is required');
+  const { success } = await import(moduleUrl);
+  const f = JSON.parse(readFileSync(new URL('./fixtures/ai-kpi-synthetic.json', import.meta.url)));
+  const r = success(f.events, f.start, f.end, f.as_of);
+  assert.deepEqual([r.numerator, r.denominator, r.unknown_count, r.value_or_null, r.known_outcome_coverage], [1,4,1,25,75]);
+});

scripts/assignment.test.mjs

@@ -0,0 +1,61 @@
+import test from 'node:test';
+import assert from 'node:assert/strict';
+import {readFileSync} from 'node:fs';
+import {targetCaption} from './target-caption.mjs';
+const read = p => readFileSync(p,'utf8');
+const matrix = JSON.parse(read('research/ai-adoption/assignment-evidence.json'));
+test('PDF assignment and audit matrix map to actual page evidence',()=>{
+ assert.deepEqual(matrix.requirements.map(r=>r.id),['format','context','q1','q2','q3','q4','assumptions','F1','F2-F3']);
+ for(const row of matrix.requirements){
+  const text=row.pages.map(p=>read(`docs/strategy/${p}.mdx`)).join('\n').toLowerCase();
+  for(const marker of row.markers) assert(text.includes(marker.toLowerCase()),`${row.id}: ${marker}`);
+ }
+ for(const p of matrix.verification_sources)assert(read(p));
+ assert.equal(35+15,50);
+});
+test('six-month reading path does not promise skills rollout or autonomous delivery',()=>{
+ const main=read('docs/strategy/six-months-target.mdx').split('<details>')[0];
+ assert(main.indexOf('strategy-six-months')<main.indexOf('Choose the smallest intervention'));
+ for(const stale of ['The first investment is a governed skills system','An autonomous agent executes and governs every phase','foundation for Stage 2'])assert(!main.includes(stale));
+ const roadmap=read('docs/strategy/six-months-roadmap.mdx');
+ for(const month of [1,2,3,4,5,6]){
+  const block=roadmap.split(`**Month ${month} — `)[1].split('\n\n')[0];
+  for(const word of ['Output:','Dependency:'])assert(block.includes(word),`${month}: ${word}`);
+ }
+});
+test('proposed diagram preserves months and explicit mobile feedback legend',()=>{
+ const pair=['','-mobile'].map(s=>JSON.parse(read(`diagrams/strategy-six-months${s}.architecture.json`)));
+ const nodes=d=>d.components.map(({pos,size,...n})=>n);
+ assert.deepEqual(nodes(pair[0]),nodes(pair[1]));
+ for(const d of pair){
+  for(let m=1;m<=6;m++)assert(d.components.some(n=>n.label.startsWith(`Month ${m}:`)));
+  const legend=d.components.find(n=>n.id==='reference');
+  assert(legend.sublabel.includes('Month 6 → 2:'));assert(legend.sublabel.includes('Month 5 → 1:'));
+  assert(legend.sublabel.includes('not company commitments'));
+ }
+});
+test('first-revision recovery and diagram decisions cannot disappear',()=>{
+ for(const id of ['skills-quality','skills-governance','skills-maintenance']){
+  const text=read(`docs/strategy/${id}.mdx`);
+  for(const term of ['N/A','pinned clean','current'])assert(text.includes(term),id);
+ }
+ for(const s of ['','-mobile']){
+  const g=JSON.parse(read(`diagrams/strategy-governance${s}.architecture.json`));
+  assert(g.components.find(n=>n.id==='canary').sublabel.includes('pilot'));
+  assert(g.components.find(n=>n.id==='approve').sublabel.includes('approve / hold'));
+  const a=JSON.parse(read(`diagrams/strategy-adoption${s}.architecture.json`));
+  assert(a.components.find(n=>n.id==='expand').sublabel.includes('Retain / improve / hold / stop'));
+ }
+ const mobile=JSON.parse(read('diagrams/strategy-maintenance-mobile.architecture.json'));
+ const order=[...mobile.components].sort((a,b)=>a.pos[1]-b.pos[1]).map(n=>n.id);
+ assert.deepEqual(order.slice(0,2),['observe','triage']);
+});
+test('target caption is inside SVG, expands canvas and fails closed',()=>{
+ const svg='<svg role="img" viewBox="0 0 1200 1000"><g data-node-id="agent"/></svg>';
+ const out=targetCaption(svg);
+ for(const term of ['Long-term Target','Solid: lifecycle','Dotted: execution','Dashed: human-controlled'])assert(out.includes(term));
+ assert(out.includes('viewBox="0 0 1200 1130"'));
+ assert(out.indexOf('eldorado-target-caption')<out.indexOf('</svg>'));
+ assert.equal((out.match(/data-node-id=/g)||[]).length,1);
+ assert.throws(()=>targetCaption('<svg/>'));
+});

scripts/baseline.test.mjs

@@ -0,0 +1,34 @@
+import test from 'node:test';
+import assert from 'node:assert/strict';
+import {readFileSync} from 'node:fs';
+const read = path => readFileSync(path, 'utf8');
+
+test('Baseline is workflow-scoped, evidence-bound and distinct from the optional registry', () => {
+  const page = read('docs/strategy/baseline.mdx');
+  for (const heading of ['Understand the current workflow','Select relevant metrics, with reasons','Agree feasible evidence','Record the starting position','Keep later evaluation comparable']) assert(page.includes(`## ${heading}`));
+  for (const text of ['not a mandatory company-wide baseline','no actual baseline values or approved thresholds','lawful basis','privacy','retention','source coverage','**Available:**','**Unavailable:**','not causal ROI','selected-but-unavailable']) assert(page.includes(text), text);
+  assert(page.indexOf('<ArchifyDiagram') < page.indexOf('## Understand'));
+  assert(!page.includes('25%'));
+  for (const doc of ['measurement/index','measurement/collection-and-safeguards','skills-adoption','skills-maintenance','skills-governance']) assert(page.includes(`./${doc}.mdx`));
+  const registry = read('docs/strategy/measurement/index.mdx');
+  assert(registry.includes('pagination_next: baseline'));
+  assert(page.includes('pagination_prev: measurement/index'));
+  assert(page.includes('pagination_next: skills-governance'));
+});
+
+test('workflow application has one home and shared safety remains explicit', () => {
+  const registry = read('docs/strategy/measurement/index.mdx');
+  const shared = read('docs/strategy/measurement/collection-and-safeguards.mdx');
+  const adoption = read('docs/strategy/skills-adoption.mdx');
+  const maintenance = read('docs/strategy/skills-maintenance.mdx');
+  assert(!registry.includes('Measure the pilot'));
+  assert(!shared.includes('Track all five'));
+  assert(!shared.includes('Before a pilot, freeze'));
+  assert(shared.includes('id') && shared.includes('{#baseline-and-interpretation}')); // Existing inbound anchor survives relocation.
+  for (const marker of ['transport retries','quarantined','Late arrivals','Unknown version stays null','30 days','12 months','below five people','No raw prompts','Consent is not presumed']) assert(shared.includes(marker),marker);
+  assert(adoption.includes('not a mandatory pilot bundle'));
+  assert(adoption.includes('What a pilot report looks like'));
+  assert(maintenance.includes('Keep selected evidence useful'));
+  assert(maintenance.includes('versioned corrections'));
+  assert(adoption.includes('**Next:** [Maintain skills using the agreed evidence →](./skills-maintenance.mdx)'));
+});

scripts/browser/connected-journey.cjs

@@ -0,0 +1,8 @@
+const {chromium}=require('playwright');
+const fs=require('node:fs');const assert=require('node:assert/strict');
+(async()=>{
+ const base=process.argv[2]||'http://127.0.0.1:4173';const out=`.cache/journey-${process.argv[3]||'candidate'}`;fs.mkdirSync(out,{recursive:true});
+ const b=await chromium.launch({executablePath:process.env.PLAYWRIGHT_CHROMIUM_EXECUTABLE,args:['--no-sandbox']});const results=[];
+ const steps=[['target-operating-model','roadmap'],['roadmap','six-months-target'],['six-months-target','six-months-roadmap'],['six-months-roadmap','stage-02-autonomous-agent'],['six-months-roadmap','stage-01-skills-adoption'],['stage-01-skills-adoption','baseline'],['baseline','measurement'],['measurement','skills-quality'],['skills-quality','skills-governance'],['skills-governance','skills-quality'],['skills-quality','skills-adoption'],['skills-adoption','skills-maintenance'],['skills-maintenance','skills-quality'],['skills-quality','measurement/validated-task-success'],['measurement/validated-task-success','skills-quality'],['skills-maintenance','stage-02-autonomous-agent'],['stage-02-autonomous-agent','stage-01-skills-adoption']];
+ try{for(const width of [1440,390]){const p=await b.newPage({viewport:{width,height:900}});for(const [from,to]of steps){await p.goto(`${base}/eldorado-v1/documentation/strategy/${from}/`,{waitUntil:'networkidle'});const href=`/eldorado-v1/documentation/strategy/${to}/`;const link=p.locator(`article a[href="${href}"]`).filter({visible:true}).first();assert(await link.count(),`${from} → ${to}`);await link.scrollIntoViewIfNeeded();await p.waitForLoadState('networkidle');await link.click();await p.waitForURL(`${base}${href}`);await p.locator('article h1').waitFor();results.push({width,from,to,clicked:true});fs.writeFileSync(`${out}/results.json`,JSON.stringify(results,null,2))}await p.close()}console.log(`PASS ${results.length} real reader handoffs and feedback links`)}finally{await b.close()}
+})().catch(e=>{console.error(e);process.exitCode=1});

scripts/browser/department-pages.cjs

@@ -0,0 +1,49 @@
+const {chromium}=require('playwright');
+const assert=require('node:assert/strict');
+const fs=require('node:fs');
+(async()=>{
+ const base=process.argv[2]||'http://127.0.0.1:4187';
+ const prefix='/eldorado-v1/documentation/organization/';
+ const departments=JSON.parse(fs.readFileSync('research/organization/department-migration.json')).departments;
+ const ids=['structure',...departments.map(d=>'structure/'+d.slug)];
+ const titles=['Structure',...departments.map(d=>d.label)];
+ const browser=await chromium.launch({headless:true,args:['--no-sandbox'],executablePath:process.env.PLAYWRIGHT_CHROMIUM_EXECUTABLE});
+ const results=[]; fs.mkdirSync('.cache/departments',{recursive:true});
+ try{
+ for(const width of [1440,390]){
+ const page=await browser.newPage({viewport:{width,height:900}}); const errors=[]; page.on('pageerror',e=>errors.push(e.message));
+ for(const [i,id] of ids.entries()){
+ assert.equal((await page.goto(base+prefix+id+'/',{waitUntil:'networkidle'})).status(),200);
+ assert.equal(await page.locator('h1').innerText(),titles[i]);
+ if(i){
+ assert.equal(await page.locator('.breadcrumbs a').filter({hasText:'Structure'}).getAttribute('href'),prefix+'structure/');
+ assert.equal(await page.locator('.pagination-nav__link--prev').getAttribute('href'),prefix+ids[i-1]+'/');
+ await page.getByRole('link',{name:'Return to Structure overview',exact:true}).click();
+ await page.waitForURL(base+prefix+'structure/');
+ await page.locator('article').getByRole('link',{name:titles[i],exact:true}).click();
+ await page.waitForURL(base+prefix+id+'/');
+ }
+ assert.equal(await page.locator('.pagination-nav__link--next').getAttribute('href'),prefix+(ids[i+1]||'collaboration')+'/');
+ assert(!await page.evaluate(()=>document.documentElement.scrollWidth>innerWidth));
+ await page.screenshot({path:`.cache/departments/${width}-${id.replaceAll('/','-')}.png`,fullPage:true});
+ if(width<997)await page.getByRole('button',{name:'Toggle navigation bar'}).click();
+ const menu=page.locator('.theme-doc-sidebar-menu').filter({visible:true});
+ await menu.getByRole('link',{name:'Structure',exact:true}).waitFor({state:'visible'});
+ const category=menu.locator('.theme-doc-sidebar-item-category');
+ await category.getByRole('link',{name:'Product',exact:true}).waitFor({state:'visible'});
+ assert.deepEqual(await category.locator(':scope > ul > li > a').allTextContents(),titles.slice(1));
+ assert.deepEqual(await menu.locator(':scope > li > a').allTextContents(),['Collaboration','SDLC']);
+ const caret=category.locator(':scope > .menu__list-item-collapsible > button');
+ await caret.click(); await category.getByRole('link',{name:'Product',exact:true}).waitFor({state:'hidden'});
+ await caret.click(); await category.getByRole('link',{name:'Product',exact:true}).waitFor({state:'visible'});
+ const next=(i+1)%ids.length;
+ await menu.getByRole('link',{name:titles[next],exact:true}).click(); await page.waitForURL(base+prefix+ids[next]+'/');
+ await page.locator('h1').filter({hasText:titles[next]}).waitFor();
+ results.push({width,id,navigation:true});
+ }
+ assert.deepEqual(errors,[]);await page.close();
+ }
+ fs.writeFileSync('.cache/departments/results.json',JSON.stringify(results,null,2));
+ console.log('PASS: '+results.length+' desktop/mobile department contexts, real sidebar/return/list navigation, breadcrumbs, pagination and overflow');
+ }finally{await browser.close();}
+})().catch(e=>{console.error(e);process.exit(1)});

scripts/browser/homepage-embed.cjs

@@ -0,0 +1,60 @@
+const {chromium}=require('playwright');
+const staircaseFits=require('./presentation-staircase.cjs');
+const assert=require('node:assert/strict');const fs=require('node:fs');
+(async()=>{
+ const base=process.argv[2]||'http://127.0.0.1:43853';const root=base+'/eldorado-v1/documentation/';
+ const out='.cache/homepage-embed';fs.mkdirSync(out,{recursive:true});
+ const browser=await chromium.launch({headless:true,executablePath:process.env.PLAYWRIGHT_CHROMIUM_EXECUTABLE,args:['--no-sandbox']});const results=[];
+ try{
+ for(const viewport of [{width:1440,height:900},{width:390,height:844},{width:320,height:720},{width:844,height:390}]){
+ const context=await browser.newContext({viewport,hasTouch:true,reducedMotion:'reduce'});const p=await context.newPage();const errors=[];
+ p.on('pageerror',e=>errors.push(e.message));p.on('response',r=>{if(r.status()>=400)errors.push(`${r.status()} ${r.url()}`)});
+ await p.goto(root,{waitUntil:'networkidle'});const section=p.locator('section[aria-labelledby="presentation-title"]');await section.scrollIntoViewIfNeeded();
+ const iframe=p.locator('iframe[title="Less Prompting, More Shipping — interactive presentation"]');const f=await iframe.elementHandle().then(e=>e.contentFrame());await f.waitForFunction(()=>window.Reveal?.isReady());await f.evaluate(()=>document.fonts.ready);
+ assert.deepEqual(await p.locator('#start-title,#presentation-title').evaluateAll(es=>es.map(e=>{const s=getComputedStyle(e);return [s.fontFamily,s.fontSize,s.fontWeight,s.letterSpacing,s.lineHeight]})).then(a=>a[0]),await p.locator('#presentation-title').evaluate(e=>{const s=getComputedStyle(e);return [s.fontFamily,s.fontSize,s.fontWeight,s.letterSpacing,s.lineHeight]}));
+ assert.equal(await f.locator('.toolbar').isVisible(),false);assert.equal(await f.evaluate(()=>Reveal.getConfig().hash),false);assert.equal(await f.evaluate(()=>Reveal.getConfig().transition),'none');assert.equal(await f.evaluate(()=>Reveal.getTotalSlides()),23);
+ assert(await p.evaluate(()=>document.documentElement.scrollWidth<=innerWidth));
+ if(viewport.width<=390)assert(await iframe.evaluate(e=>e.clientHeight>e.clientWidth),'phone stage must recompose rather than shrink landscape text');
+ await p.getByRole('button',{name:'Fullscreen',exact:true}).focus();await p.keyboard.press('ArrowRight');assert.equal(await f.evaluate(()=>Reveal.getIndices().h),0);
+ await f.locator('.controls .navigate-right').click();assert.equal(await f.evaluate(()=>Reveal.getIndices().h),1);
+ const scroll=await p.evaluate(()=>scrollY);await p.keyboard.press('ArrowRight');assert.equal(await f.evaluate(()=>Reveal.getIndices().h),2);assert.equal(await p.evaluate(()=>scrollY),scroll);assert.equal(p.url(),root);
+ await f.evaluate(()=>Reveal.slide(0));
+ const visited=[];
+ for(let i=0;i<23;i++){
+  assert.equal(await f.evaluate(()=>Reveal.getIndices().h),i);visited.push(await f.evaluate(()=>Reveal.getCurrentSlide().id));
+  const bad=await f.evaluate(()=>{const r=Reveal.getCurrentSlide().getBoundingClientRect();return [...Reveal.getCurrentSlide().querySelectorAll('svg,text,.journey,.learning-loop,.contribution-grid,h1,h2,p,li,table,.flow,.roles,.timeline')].filter(e=>!e.closest('.notes')&&e.getBoundingClientRect().width>0).filter(e=>{const b=e.getBoundingClientRect();return b.bottom>r.bottom+1||b.right>r.right+1||b.left<r.left-1}).map(e=>e.textContent)});assert.deepEqual(bad,[]);
+  if(i===6)assert(await f.evaluate(staircaseFits),'staircase aligns each arrow with its intended steps');
+   if(i===4)assert(await f.evaluate(()=>[...document.querySelectorAll('#contributors .contribution-grid>div')].every(e=>{const a=e.querySelector('span').getBoundingClientRect(), arrow=e.querySelector('i').getBoundingClientRect(), b=e.querySelector('b').getBoundingClientRect();return a.bottom<=arrow.top+2&&arrow.bottom<=b.top+2&&Math.abs((a.left+a.right-b.left-b.right)/2)<2&&getComputedStyle(e.querySelector('i')).transform==='matrix(0, 1, -1, 0, 0, 0)'})),'contribution arrows must point down to their own phase');
+   await iframe.screenshot({path:`${out}/${viewport.width}-${i+1}.png`});
+  if(i<22)await p.keyboard.press('ArrowRight');
+ }
+ assert.equal(new Set(visited).size,23);assert.equal(p.url(),root);assert.equal(new URL(f.url()).hash,'');
+ await f.evaluate(()=>Reveal.slide(0));await section.screenshot({path:`${out}/${viewport.width}-light.png`});
+ await p.evaluate(()=>document.documentElement.setAttribute('data-theme','dark'));await section.screenshot({path:`${out}/${viewport.width}-dark.png`});
+ await p.getByRole('button',{name:'Fullscreen',exact:true}).click();await p.waitForFunction(()=>!!document.fullscreenElement);await f.waitForTimeout(100);
+ await p.screenshot({path:`${out}/${viewport.width}-fullscreen.png`});
+ await p.getByRole('button',{name:'Exit fullscreen',exact:true}).click();await p.waitForFunction(()=>!document.fullscreenElement);await p.waitForFunction(()=>document.activeElement?.textContent==='Fullscreen');
+ // Native touch swipe inside the stage, not a programmatic Reveal.next().
+ await iframe.scrollIntoViewIfNeeded();const b=await iframe.boundingBox();const cdp=await context.newCDPSession(p);
+ await cdp.send('Input.dispatchTouchEvent',{type:'touchStart',touchPoints:[{x:b.x+b.width*.8,y:b.y+b.height*.4}]});
+ await cdp.send('Input.dispatchTouchEvent',{type:'touchMove',touchPoints:[{x:b.x+b.width*.2,y:b.y+b.height*.4}]});await cdp.send('Input.dispatchTouchEvent',{type:'touchEnd',touchPoints:[]});assert.equal(await f.evaluate(()=>Reveal.getIndices().h),1);
+ await p.emulateMedia({reducedMotion:'no-preference'});await f.waitForFunction(()=>Reveal.getConfig().transition==='fade');await p.emulateMedia({reducedMotion:'reduce'});await f.waitForFunction(()=>Reveal.getConfig().transition==='none');
+ await f.locator('.navigate-right').focus();await p.keyboard.press('f');await p.keyboard.press('s');assert.equal(context.pages().length,1);assert.equal(await p.evaluate(()=>!!document.fullscreenElement),false);
+ if(viewport.width<=390){
+  await p.setViewportSize({width:844,height:390});await f.waitForFunction(()=>Reveal.getConfig().width===1200);assert.equal(await f.evaluate(()=>Reveal.getIndices().h),1);
+  await p.setViewportSize(viewport);await f.waitForFunction(()=>Reveal.getConfig().width===600);
+ }
+ // Unsupported fullscreen is non-destructive and keeps a working standalone escape.
+ await p.evaluate(()=>{window.savedFullscreen=Element.prototype.requestFullscreen;Element.prototype.requestFullscreen=undefined});
+ await p.getByRole('button',{name:'Fullscreen',exact:true}).click();await p.getByRole('status').filter({hasText:'Fullscreen is unavailable'}).waitFor();assert.equal(p.url(),root);
+ await p.evaluate(()=>{Element.prototype.requestFullscreen=window.savedFullscreen});
+ // No keyboard trap: browser Tab can leave the frame for the standalone affordance.
+ await f.locator('.navigate-right').focus();for(let i=0;i<12&&!(await p.getByRole('link',{name:/Open presentation/}).evaluate(e=>e===document.activeElement));i++)await p.keyboard.press('Tab');
+ assert(await p.getByRole('link',{name:/Open presentation/}).evaluate(e=>e===document.activeElement));
+ for(const href of await p.locator('.start-card').evaluateAll(es=>es.map(e=>e.href)))assert.equal((await p.request.get(href)).status(),200);
+ await p.getByRole('link',{name:/Open presentation/}).click();await p.waitForFunction(()=>window.Reveal?.isReady());assert(!p.url().includes('embed'));assert(await p.locator('.toolbar').isVisible());
+ assert.deepEqual(errors,[]);results.push({viewport,visited,headingParity:true,keyboardIsolation:true,scrollIsolation:true,touch:true,fullscreen:true,tabExit:true,errors});await context.close();
+ }
+ fs.writeFileSync(`${out}/results.json`,JSON.stringify(results,null,2));console.log('PASS: 92 inline slides, heading parity, URLs, focus/scroll isolation, touch, fullscreen, Tab exit, themes, reduced motion and standalone handoff');
+ }finally{await browser.close()}
+})().catch(e=>{console.error(e);process.exitCode=1});

scripts/browser/inline-controls.cjs

@@ -0,0 +1,152 @@
+const {chromium} = require('playwright');
+const assert = require('node:assert/strict');
+const fs = require('node:fs');
+(async () => {
+  const base = process.argv[2] || 'http://127.0.0.1:4173';
+  const output = `.cache/inline-${process.argv[3] || 'local'}`;
+  fs.mkdirSync(output, {recursive: true});
+  const browser = await chromium.launch({headless: true, executablePath: process.env.PLAYWRIGHT_CHROMIUM_EXECUTABLE, args: ['--no-sandbox']});
+  const results = [];
+  try {
+    for (const width of [1440, 390, 320]) {
+      const context = await browser.newContext({viewport: {width, height: 1000}, colorScheme: 'light'});
+      const page = await context.newPage();
+      await page.goto(`${base}/eldorado-v1/documentation/strategy/`, {waitUntil: 'networkidle'});
+      await page.addStyleTag({content:'html {scroll-behavior:auto !important;}'});
+      const panel = page.locator('.archify-panel--story[data-diagram="strategy-target"]');
+      const iframe = panel.locator(width > 700 ? '.story-desktop' : '.story-mobile');
+      await iframe.scrollIntoViewIfNeeded();
+      const frame = await (await iframe.elementHandle()).contentFrame();
+      const showControls = () => iframe.evaluate(n => {
+        scrollTo({top:n.getBoundingClientRect().top+scrollY-120,behavior:'instant'});
+        return new Promise(resolve=>requestAnimationFrame(()=>requestAnimationFrame(resolve)));
+      });
+      await showControls();
+      const activate = async selector => {await frame.locator(selector).focus(); await page.keyboard.press('Enter');};
+      const theme = async value => {
+        await page.waitForFunction(t => document.documentElement.dataset.theme === t, value);
+        await frame.waitForFunction(t => document.documentElement.dataset.theme === t, value);
+      };
+      await theme('light');
+      for (const id of ['btn-theme', 'btn-preset', 'btn-export']) {
+        const box = await frame.locator(`#${id}`).boundingBox();
+        assert(box && box.width >= 40 && box.height >= 44, id);
+      }
+      const toolbar = await frame.locator('.toolbar').boundingBox();
+      const exportButton = await frame.locator('#btn-export').boundingBox();
+      const diagram = await frame.locator('.diagram-container > svg').boundingBox();
+      const rightGap = toolbar.x + toolbar.width - exportButton.x - exportButton.width;
+      assert(Math.abs(rightGap - 8) < 1, `toolbar right padding at ${width}: ${rightGap}`);
+      assert(diagram.y >= toolbar.y + toolbar.height, 'toolbar must stay above nodes');
+      const checkMenu = async selector => {
+        await frame.locator(selector).evaluate(n => Promise.all(n.getAnimations().map(a => a.finished)));
+        const menu = await frame.locator(selector).boundingBox();
+        const viewport = await iframe.boundingBox();
+        const currentToolbar = await frame.locator('.toolbar').boundingBox();
+        assert(menu && menu.x >= viewport.x - 1 && menu.y >= currentToolbar.y + currentToolbar.height - 1, selector);
+        assert(menu.x + menu.width <= viewport.x + viewport.width + 1, `${selector} clips horizontally`);
+        assert(menu.y + menu.height <= viewport.y + viewport.height + 1, `${selector} clips vertically`);
+      };
+      const light = await frame.locator('body').evaluate(n => getComputedStyle(n).backgroundColor);
+      await activate('#btn-theme'); await theme('dark');
+      assert.notEqual(await frame.locator('body').evaluate(n => getComputedStyle(n).backgroundColor), light);
+      await activate('#btn-theme'); await theme('light');
+      // Mobile portal theme control lives in the navigation drawer.
+      const portalTheme = async target => {
+        if (width <= 700) await page.getByRole('button', {name: 'Toggle navigation bar'}).click();
+        for (let attempt = 0; attempt < 3; attempt++) {
+          await page.getByRole('button', {name: /Switch between dark and light mode/}).filter({visible: true}).click();
+          if (await page.locator('html').getAttribute('data-theme') === target) break;
+        }
+        if (width <= 700) await page.getByRole('button', {name: 'Close navigation bar'}).click();
+        await showControls();
+      };
+      await portalTheme('dark'); await theme('dark');
+      await portalTheme('light'); await theme('light');
+      for (const preset of ['signal-flow', 'blueprint', 'editorial', 'classic']) {
+        await activate('#btn-preset');
+        await checkMenu('.preset-menu');
+        await activate(`[data-preset-value="${preset}"]`);
+        assert.equal(await frame.locator('html').getAttribute('data-preset'), preset);
+      }
+      // A theme change must not reload the iframe or lose the selected visual preset.
+      await activate('#btn-preset');
+      await activate('[data-preset-value="blueprint"]');
+      await portalTheme('dark'); await theme('dark');
+      assert.equal(await frame.locator('html').getAttribute('data-preset'), 'blueprint');
+      const exports = [];
+      for (const format of ['png', 'jpeg', 'webp', 'svg', 'svg-light', 'svg-dark', 'webm']) {
+        await activate('#btn-export');
+        await checkMenu('.export-menu');
+        if (format === 'webm' && await frame.locator('[data-format="webm"]').isDisabled()) {
+          exports.push({format, unsupported: true});
+          await activate('#btn-export');
+          continue;
+        }
+        console.log(`Export ${width} ${format}`);
+        const [download] = await Promise.all([
+          page.waitForEvent('download', {timeout: 60000}),
+          activate(`[data-format="${format}"]`),
+        ]);
+        assert.equal(await download.failure(), null);
+        const path = `${output}/${width}-${format}-${download.suggestedFilename()}`;
+        await download.saveAs(path);
+        const bytes = fs.readFileSync(path);
+        assert(bytes.length > 1000);
+        if (format.startsWith('svg')) {
+          const valid = await page.evaluate(xml => {
+            const doc = new DOMParser().parseFromString(xml, 'image/svg+xml');
+            if (doc.querySelector('[data-node-id="humans"], [data-edge-id="human-direction"]')) return false;
+            if (![...doc.querySelectorAll('[data-node-id="agent"] text')].some(n => n.textContent === 'Human Controlled')) return false;
+            if (doc.querySelectorAll('[data-node-id]').length !== 17 || doc.querySelectorAll('path[data-edge-id]').length !== 24) return false;
+            return !doc.querySelector('parsererror') && doc.documentElement.localName === 'svg' && doc.querySelectorAll('text').length > 0 && doc.querySelector('#eldorado-cycle-export')?.textContent.includes('stroke-dasharray: 3 9');
+          }, bytes.toString());
+          assert(valid, format);
+        } else {
+          const mime = {png:'image/png', jpeg:'image/jpeg', webp:'image/webp', webm:'video/webm'}[format];
+          const dimensions = await page.evaluate(async ({data, mime}) => {
+            const media = document.createElement(mime.startsWith('video') ? 'video' : 'img');
+            const loaded = new Promise((resolve, reject) => {media[mime.startsWith('video') ? 'onloadedmetadata' : 'onload'] = resolve; media.onerror = reject;});
+            media.src = `data:${mime};base64,${data}`; await loaded;
+            return [media.videoWidth || media.naturalWidth, media.videoHeight || media.naturalHeight];
+          }, {data: bytes.toString('base64'), mime});
+          assert(dimensions.every(n => n > 0), format);
+        }
+        exports.push({format, path, bytes:bytes.length});
+      }
+      const opener = panel.getByRole('button', {name:/^Expand /});
+      await opener.click();
+      let full = await (await panel.locator('dialog iframe').elementHandle()).contentFrame();
+      await full.waitForFunction(() => document.documentElement.dataset.theme === 'dark');
+      await full.locator('#btn-theme').click(); await theme('light');
+      const close = panel.getByRole('button', {name:'Close full-screen diagram'});
+      assert.equal(await close.innerText(), '×');
+      await close.click(); assert(await opener.evaluate(n => n === document.activeElement));
+      await opener.click();
+      full = await (await panel.locator('dialog iframe').elementHandle()).contentFrame();
+      await full.waitForFunction(() => document.documentElement.dataset.theme === 'light');
+      await close.focus(); await page.keyboard.press('Escape');
+      assert(await opener.evaluate(n => n === document.activeElement));
+      await iframe.scrollIntoViewIfNeeded();
+      await page.evaluate(() => scrollTo({top: 0, behavior: 'instant'}));
+      await page.evaluate(() => new Promise(resolve => requestAnimationFrame(() => requestAnimationFrame(resolve))));
+      await page.screenshot({path:`${output}/${width}.png`, fullPage:true});
+      await frame.locator('#btn-theme').focus(); await page.keyboard.press('Enter'); await theme('dark');
+      // Exercise keyboard navigation without racing the portal's smooth scroll.
+      await page.locator('.strategy-content a[href$="/strategy/roadmap/"]').filter({visible:true}).first().focus();
+      await page.keyboard.press('Enter');
+      await page.waitForURL('**/strategy/roadmap/');
+      await page.goBack({waitUntil:'domcontentloaded'});
+      await page.waitForURL('**/strategy/target-operating-model/');
+      await page.getByRole('heading', {name:'Target', exact:true, level:1}).waitFor();
+      const next = page.locator(`.archify-panel--story[data-diagram="strategy-target"] > .story-${width > 700 ? 'desktop' : 'mobile'}`);
+      await next.scrollIntoViewIfNeeded();
+      await (await (await next.elementHandle()).contentFrame()).waitForFunction(() => document.documentElement.dataset.theme === 'dark');
+      assert(!await page.evaluate(() => document.documentElement.scrollWidth > innerWidth));
+      results.push({width, toolbar, rightGap, dropdownsUnclipped:true, themeSync:true, presets:4, exports, fullscreen:true, routeTheme:true});
+      fs.writeFileSync(`${output}/results.json`, JSON.stringify(results,null,2));
+      await context.close();
+    }
+    console.log(`PASS ${results.length} viewports: bidirectional themes, 4 presets, all supported exports decoded, fullscreen and route persistence`);
+  } finally {await browser.close();}
+})().catch(error => {console.error(error); process.exitCode = 1;});