// Domain data for the Proshore AI Adoption Method page.
// Kept here so copy edits don't require touching component logic.

const CONVICTIONS = [
  {
    num: "01",
    short: "System thinking",
    headline: "We fix the <b class=\"t-pos\">whole system</b>, not the parts.",
    body: "AI that speeds up coding while leaving <b class=\"t-neg\">requirements ambiguity</b> untouched doesn't improve the system. It just <b class=\"t-neg\">shifts the bottleneck</b> downstream.",
  },
  {
    num: "02",
    short: "Bottleneck-first",
    headline: "AI goes where <b class=\"t-pos\">friction</b> is, not where AI is <b class=\"t-neg\">attractive</b>.",
    body: "If refinement is the team's <b class=\"t-neg\">bottleneck</b>, that's where AI belongs, even if the louder conversation in the industry is about <b class=\"t-neu\">coding agents</b>.",
  },
  {
    num: "03",
    short: "Guardrails before freedom",
    headline: "Design the <b class=\"t-pos\">guardrails</b> first, then give real <b class=\"t-pos\">autonomy</b>.",
    body: "<b class=\"t-pos\">Freedom inside clear boundaries</b> produces better outcomes while implementing AI.",
  },
  {
    num: "04",
    short: "Amplification, not replacement",
    headline: "AI <b class=\"t-neu\">amplifies</b> the system it enters \u2014 including its <b class=\"t-neg\">weaknesses</b>.",
    body: "A team with <b class=\"t-neg\">poor refinement</b> produces worse requirements faster. A team with <b class=\"t-pos\">good refinement</b> produces excellent requirements faster. AI doesn't fix broken systems; it <b class=\"t-neu\">accelerates whatever is already there</b>.",
    emphasis: true,
  },
];

const STAGES = [
  {
    id: "idea",
    label: "Idea",
    produces: "A problem worth solving",
    typicalFriction: "<b class=\"t-neg\">Unclear roadmap</b> and lots of <b class=\"t-neg\">scope change</b>",
    aiIntervention: {
      title: "Unclear vision",
      what: "Chat interface loaded with <b class=\"t-neu\">product context</b>, past tickets, customer calls.",
      human: "<b class=\"t-pos\">Product Owner decides</b> which ideas to proceed with.",
      output: "A brief of stated assumption with <b class=\"t-pos\">commitment</b> and ready to be refined.",
    },
  },
  {
    id: "refine",
    label: "Refine",
    produces: "Stories a team can commit to",
    typicalFriction: "<b class=\"t-neg\">Ambiguous acceptance criteria</b> cause <b class=\"t-neg\">mid-sprint scope changes</b>.",
    aiIntervention: {
      title: "Refinement co-pilot",
      what: "AI drafts <b class=\"t-pos\">acceptance criteria</b>, <b class=\"t-pos\">edge cases</b>, and open questions using <b class=\"t-neu\">MCP</b> or knowledge chatbot.",
      human: "PM + tech lead <b class=\"t-pos\">validates the draft</b> in a 30-min session.",
      output: "Stories with <b class=\"t-pos\">clear assumptions</b> and <b class=\"t-pos\">explicit unknowns</b>.",
    },
    commonBottleneck: true,
  },
  {
    id: "plan",
    label: "Plan",
    produces: "A sprint commitment the team believes",
    typicalFriction: "<b class=\"t-neg\">Estimates not matching</b>; commitments <b class=\"t-neg\">miss repeatedly</b>.",
    aiIntervention: {
      title: "Historically-grounded estimation",
      what: "AI surfaces <b class=\"t-neu\">similar past stories</b> + their actual <b class=\"t-neu\">cycle time</b>.",
      human: "The team still estimates but with <b class=\"t-pos\">data on the table</b>.",
      output: "Estimates with <b class=\"t-pos\">confidence</b>, not based on <b class=\"t-neg\">gut feeling</b> only.",
    },
  },
  {
    id: "develop",
    label: "Develop",
    produces: "Working software, under review",
    typicalFriction: "<b class=\"t-neg\">Context-switching</b> between ticket, codebase, and docs.",
    aiIntervention: {
      title: "IDE + CLI agents with project context",
      what: "In-editor completions and multi-file agents wired to the repo via <b class=\"t-neu\">MCP</b>.",
      human: "Every line shipped is <b class=\"t-pos\">read, understood, and owned</b> by an engineer.",
      output: "PRs authored <b class=\"t-pos\">faster</b>, reviewed with the <b class=\"t-pos\">same rigour</b>.",
    },
  },
  {
    id: "test",
    label: "Test",
    produces: "Confidence the change is safe",
    typicalFriction: "Tests written <b class=\"t-neg\">after code</b>; <b class=\"t-neg\">edge cases missed</b>.",
    aiIntervention: {
      title: "Test strategy, AI execution",
      what: "<b class=\"t-pos\">QA designs</b> what to test and why; AI generates the cases and data.",
      human: "QA <b class=\"t-pos\">reviews coverage</b> and signs off on risk.",
      output: "Coverage that matches the <b class=\"t-pos\">risk profile</b> of the change.",
    },
  },
  {
    id: "deploy",
    label: "Deploy",
    produces: "Change safely in production",
    typicalFriction: "<b class=\"t-neg\">Runbooks drift</b>; <b class=\"t-neg\">release anxiety</b> lingers.",
    aiIntervention: {
      title: "AI-augmented release",
      what: "<b class=\"t-neu\">Release notes</b>, <b class=\"t-neu\">risk summaries</b>, and <b class=\"t-pos\">rollback drafts</b> generated from the diff.",
      human: "DevOps <b class=\"t-pos\">approves the release</b>; the rollback is <b class=\"t-pos\">pre-staged</b>.",
      output: "<b class=\"t-pos\">Faster, calmer releases</b> with the same safety net.",
    },
  },
  {
    id: "monitor",
    label: "Monitor",
    produces: "A signal, not just an alert",
    typicalFriction: "<b class=\"t-neg\">Alert fatigue</b>; real incidents <b class=\"t-neg\">hide in noise</b>.",
    aiIntervention: {
      title: "Observability with an AI layer",
      what: "AI <b class=\"t-pos\">clusters alerts</b>, proposes <b class=\"t-pos\">probable cause</b>, drafts the incident note.",
      human: "On-call still <b class=\"t-pos\">triages</b> \u2014 but starts from a <b class=\"t-pos\">hypothesis</b>.",
      output: "<b class=\"t-pos\">Faster recognition</b>, <b class=\"t-pos\">less fatigue</b>, better post-mortems.",
    },
  },
  {
    id: "iterate",
    label: "Iterate",
    produces: "Learning that feeds the next cycle",
    typicalFriction: "Retros produce <b class=\"t-neg\">lists</b>; lists <b class=\"t-neg\">don't change behaviour</b>.",
    aiIntervention: {
      title: "Context that closes the loop",
      what: "Retro notes and incidents <b class=\"t-pos\">feed back</b> into the project's <b class=\"t-neu\">shared context</b>.",
      human: "The team decides <b class=\"t-pos\">what's worth remembering</b>.",
      output: "Next sprint starts with <b class=\"t-pos\">last sprint's lessons</b> already on the table.",
    },
  },
];

const METHOD_STEPS = [
  {
    n: 1,
    name: "Map",
    sub: { team: "your current delivery system", client: "your current delivery workflow" },
    body: "Visualize how work <b class=\"t-pos\">actually flows today</b> \u2014 <b class=\"t-neg\">not the idealised version</b>. Real blockers, real rework loops, real waiting stages.",
    output: { team: "A <b class=\"t-pos\">visual map</b> of the team's delivery system, stage by stage.", client: "A <b class=\"t-pos\">visual map</b> of the team's delivery workflow, stage by stage." },
    dora: [],
  },
  {
    n: 2,
    name: "Diagnose",
    sub: { team: "where the real bottlenecks are", client: "where work actually slows down" },
    body: {
      team: "Use three lenses: <b class=\"t-neu\">time</b> (where does work wait?), <b class=\"t-neu\">quality</b> (where do defects originate?), <b class=\"t-neu\">effort</b> (where is energy drained?). A bottleneck scores <b class=\"t-neg\">badly on at least two</b>.",
      client: "Look at the workflow through three lenses: <b class=\"t-neu\">time</b> (where does work wait?), <b class=\"t-neu\">quality</b> (where do issues originate?), <b class=\"t-neu\">effort</b> (where is energy drained?). The slowdown to start with scores <b class=\"t-neg\">badly on at least two</b>.",
    },
    output: "<b class=\"t-pos\">1\u20132 named bottlenecks</b>, with evidence and a hypothesis.",
    dora: [],
  },
  {
    n: 3,
    name: "Design",
    sub: { team: "the AI intervention for that bottleneck", client: "the workflow improvement for that slowdown" },
    body: {
      team: "Describe the intervention as a small system: what <b class=\"t-neu\">AI does</b>, what <b class=\"t-neu\">context it needs</b>, what the <b class=\"t-pos\">human still does</b>, what output it produces. <b class=\"t-pos\">Tool choice comes last</b>.",
      client: "Describe the change as a small piece of workflow: what <b class=\"t-neu\">AI does</b>, what <b class=\"t-neu\">context it draws on</b>, what the <b class=\"t-pos\">person still does</b>, what gets produced. <b class=\"t-pos\">The specific tool comes last</b>.",
    },
    output: "A <b class=\"t-pos\">one-page design</b> with roles, context sources, and outputs.",
    dora: ["internal-data", "data", "platform", "batches"],
  },
  {
    n: 4,
    name: "Guardrail",
    sub: "who reviews, when, and how",
    body: "Name the <b class=\"t-pos\">review point</b>, the <b class=\"t-pos\">decision boundary</b>, and the <b class=\"t-pos\">escape hatch</b>. Guardrails are <b class=\"t-pos\">designed in</b> \u2014 <b class=\"t-neg\">not added after the intervention breaks</b>.",
    output: "A <b class=\"t-pos\">guardrails statement</b> every team member signs up to.",
    dora: ["stance", "vcs", "user"],
  },
  {
    n: 5,
    name: "Measure",
    sub: { team: "and iterate, on a rhythm", client: "and improve, on a rhythm" },
    body: "Run the intervention for <b class=\"t-neu\">2\u20134 sprints</b>. Watch the <b class=\"t-neu\">bottleneck signal</b> and the <b class=\"t-neu\">system signal</b>. Expect the system to rebalance \u2014 that's <b class=\"t-pos\">not failure, it's feedback</b>.",
    output: "A written review, then a decision: <b class=\"t-pos\">deepen</b>, <b class=\"t-neu\">adjust</b>, or <b class=\"t-neg\">move on</b>.",
    dora: ["user", "batches"],
  },
];

// Placeholder worked example: marked clearly as illustrative.
const WORKED_EXAMPLE = {
  teamName: "Team Alpha",
  context: "A 2–3 person delivery team on a client SaaS product. AI coding tools like <b class=\"t-neu\">Cursor</b> were introduced to boost individual output. Developers used AI but more like a chatbot, so <b class=\"t-neg\">team coordination didn't improve</b>. Velocity remained slow because the bottleneck wasn't writing code. It was everything around it.",
  map: "Idea → Refine → Plan → Develop → Test → Deploy → Monitor → Iterate. Two feedback loops: <b class=\"t-neu\">Test → Develop</b> (defects & rework), <b class=\"t-neu\">PO Sign-off → Plan</b> (stories piling up waiting for approval).",
  diagnosis: {
    bottleneck: "Refine + PO Sign-off",
    evidence: "Requirements are unclear at multiple points: <b class=\"t-neg\">developers guess mid-sprint</b>, <b class=\"t-neg\">back-and-forth with PM causes delays</b>, and gaps surface at demos, too late to fix cheaply. Separately, <b class=\"t-neg\">PO is too busy to test on time</b>, creating a sign-off queue that stalls stories from closing.",
    hypothesis: "Stories enter the sprint without enough definition. Developers fill the gaps themselves, inconsistently. The PO then inherits ambiguous work to test and approve, compressing their time further and creating a <b class=\"t-neg\">slow, leaky feedback loop</b> that AI coding speed cannot fix.",
  },
  design: {
    headline: "A story-readiness co-pilot and a lightweight PO testing assist.",
    what: "AI drafts <b class=\"t-pos\">acceptance criteria</b>, <b class=\"t-pos\">edge cases</b>, and open questions from the feature brief before refinement. Separately, AI generates a <b class=\"t-pos\">test checklist</b> from the acceptance criteria so the PO can sign off faster.",
    context: "<b class=\"t-neu\">Feature brief or ticket description</b>, similar past stories, any known edge cases from previous sprints.",
    human: "PM and dev lead <b class=\"t-pos\">pressure-test the AI draft</b> in refinement rather than writing from scratch. PO uses the AI checklist as a starting point, <b class=\"t-pos\">not a replacement for judgment</b>.",
    output: "Stories with <b class=\"t-pos\">explicit acceptance criteria</b>, <b class=\"t-pos\">named unknowns resolved before dev starts</b>, and a PO test checklist ready at handoff.",
  },
  guardrails: {
    review: "Dev lead <b class=\"t-pos\">reviews every AI-drafted story</b> before it enters the sprint.",
    boundary: "AI <b class=\"t-pos\">drafts and proposes</b>; it <b class=\"t-neg\">never estimates, commits, or closes stories</b>.",
    escape: "Any team member can flag a story as <b class=\"t-neg\">'needs re-refine'</b> during planning and <b class=\"t-pos\">block it from entering the sprint</b>.",
  },
  measure: {
    bottleneckSignal: "Track mid-sprint clarification requests and stories blocked at PO sign-off. Target: clarifications down by half within three sprints.",
    systemSignal: "If sign-off queue clears but <b class=\"t-neg\">new friction appears at Deploy or Monitor</b>, that's the next cycle to investigate.",
    decision: "<b class=\"t-pos\">Deepen</b> the refinement and sign-off intervention for two cycles, then reassess velocity and escaped defects.",
  },
};

const SEVERITY_LEVELS = [
  { key: "flowing",    label: "No Bottleneck", color: "#16A34A" },
  { key: "friction",   label: "Noticeable",    color: "#CA8A04" },
  { key: "slowdown",   label: "Recurring",     color: "#EA580C" },
  { key: "bottleneck", label: "Blocking",      color: "#DC2626" },
  { key: "chaotic",    label: "Critical",      color: "#991B1B" },
];

const DORA_CAPABILITIES = [
  {
    id: "stance",
    num: "01",
    name: "Clear & communicated AI stance",
    owner: "client",
    summary: {
      team: "Your organisation\u2019s official position on AI tool use. It must be <b class=\"t-neu\">comprehensible</b> and <b class=\"t-neu\">communicated</b> \u2014 not buried in a policy doc nobody reads.",
      client: "A simple, organisation-wide answer to <b class=\"t-neu\">'can we use AI for this?'</b> that everyone can find \u2014 <b class=\"t-neg\">not buried</b> in a policy doc.",
    },
    doraSays: [
      { title: "Why it matters", desc: "\u2022 Provides psychological safety, giving developers the confidence to experiment without fear of breaking rules.<br>\u2022 Decreases friction and builds developer trust.<br>\u2022 Amplifies AI\u2019s positive influence on individual effectiveness and organizational performance." },
      { title: "How to improve it", desc: "\u2022 Form a cross-functional group (legal, security, engineering, product) to write the rules.<br>\u2022 Create a simple framework sorting tools into three buckets: <b class=\"t-neg\">Prohibited</b>, <b class=\"t-neu\">Permitted with guardrails</b>, and <b class=\"t-pos\">Allowed</b>.<br>\u2022 Publish the policy in a central, living document and socialize it through town halls and training." },
      { title: "Common obstacles", desc: "\u2022 Changing the rules too frequently, causing confusion.<br>\u2022 Creating a policy that only serves one group (like legal) rather than balancing developer reality.<br>\u2022 Treating the policy as a static document that never evolves." },
      { title: "How to measure it", desc: "\u2022 Survey teams on whether it is clear which tools are allowed and if the organization supports AI experimentation.<br>\u2022 Track page views on your AI policy document.<br>\u2022 Monitor the frequency of clarifying questions asked in public channels." },
    ],
    teamDoes: [
      { step: "Create a wiki page called \u2018AI Stance\u2019", desc: "Add three sections: <b class=\"t-neg\">Prohibited</b> (e.g. \u2018Never paste client data into public AI models\u2019), <b class=\"t-neu\">Permitted with guardrails</b> (e.g. \u2018AI code generation requires human review before merge\u2019), <b class=\"t-pos\">Allowed</b> (e.g. \u2018Brainstorming, learning, generating boilerplate\u2019)." },
      { step: "Pin the link everywhere", desc: "Add it to your <b class=\"t-neu\">repo README</b>, <b class=\"t-neu\">team channel topic</b>, and <b class=\"t-neu\">onboarding checklist</b>. If someone has to search for it, it\u2019s <b class=\"t-neg\">not communicated</b>." },
      { step: "Add a feedback channel", desc: "Create a dedicated thread or form where anyone can ask \u2018Can I use AI for X?\u2019 and get an answer within <b class=\"t-pos\">24 hours</b>. Log Q&As \u2014 they reveal gaps." },
      { step: "Review quarterly", desc: "Cross-functional owner revisits every quarter. Are Q&As revealing <b class=\"t-neg\">new grey areas</b>? Has a tool moved from <b class=\"t-neu\">permitted</b> to <b class=\"t-pos\">allowed</b>?" },
    ],
    signals: [
      "Any team member can answer \u2018Can I use AI for X?\u2019 <b class=\"t-pos\">without asking leadership</b>.",
      "<b class=\"t-pos\">Zero shadow-AI incidents</b> in the last quarter.",
      "The feedback channel has <b class=\"t-pos\">recent entries</b> \u2014 people are asking, not ignoring.",
    ],
  },
  {
    id: "data",
    num: "02",
    name: "Healthy data ecosystem",
    owner: "client",
    summary: {
      team: "Internal data must be <b class=\"t-pos\">high-quality</b>, <b class=\"t-pos\">accessible</b>, and <b class=\"t-pos\">unified</b>. AI is only as good as its context \u2014 <b class=\"t-neg\">fragmented</b> or <b class=\"t-neg\">stale</b> data produces confidently wrong outputs.",
      client: "Internal knowledge that's <b class=\"t-pos\">accurate</b>, <b class=\"t-pos\">accessible</b>, and lives in <b class=\"t-pos\">one place</b>. AI's outputs are only as good as the data behind them \u2014 <b class=\"t-neg\">stale or fragmented</b> data produces confidently wrong answers.",
    },
    doraSays: [
      { title: "Why it matters", desc: "• AI tools act as amplifiers; bad data leads to bad AI answers.<br>• A healthy ecosystem ensures internal data is high-quality, easily accessible, and unified rather than siloed.<br>• It significantly amplifies AI's positive impact on organizational performance." },
      { title: "How to improve it", desc: "• Establish clear data governance by assigning owners for critical data.<br>• Break down silos to prioritize a unified 'single source of truth'.<br>• Implement automated checks for data accuracy and completeness.<br>• Document data locally, like adding a 'data' section to your application's README.md." },
      { title: "Common obstacles", desc: "• Treating data as a by-product of transactions rather than as a product with real consumers.<br>• Allowing specific tools to create inaccessible data silos." },
      { title: "How to measure it", desc: "• Measure the elapsed time it takes a developer to get access to a necessary dataset.<br>• Track data incidents and bugs caused by poor data quality.<br>• Survey developers on how easily they can access and trust internal data." },
    ],
    teamDoes: [
      { step: "Run a data audit", desc: "List top 5 knowledge sources. For each: <b class=\"t-pos\">Is it current?</b> <b class=\"t-neu\">Who owns it?</b> <b class=\"t-neg\">Can AI access it?</b>" },
      { step: "Consolidate to a single source of truth", desc: "Create one hub page linking: <b class=\"t-neu\">product vision</b>, <b class=\"t-neu\">domain glossary</b>, <b class=\"t-neu\">architecture decisions</b>, <b class=\"t-neu\">sprint goals</b>. If info lives in two places, <b class=\"t-neg\">pick one</b>." },
      { step: "Assign data stewards", desc: "Each data source gets a <b class=\"t-pos\">named owner</b> \u2014 the person who answers \u2018Is this still accurate?\u2019" },
      { step: "Schedule a freshness check", desc: "Every retro, spend 2 minutes: \u2018Did anyone hit <b class=\"t-neg\">stale docs</b> this sprint?\u2019 <b class=\"t-pos\">Flag and fix immediately</b>." },
    ],
    signals: [
      "A new member traces AI output to its source in <b class=\"t-pos\">under 10 minutes</b>.",
      "<b class=\"t-pos\">Zero incidents</b> caused by AI acting on stale data.",
      "Project hub page updated within <b class=\"t-pos\">the last 2 weeks</b>.",
    ],
  },
  {
    id: "internal-data",
    num: "03",
    name: "AI-accessible internal data",
    owner: "shared",
    summary: {
      team: "Connecting AI to your actual codebase, wikis, and project history. DORA calls this <b class=\"t-neu\">context engineering</b> \u2014 it matters more than prompt engineering.",
      client: "AI plugged into your actual <b class=\"t-pos\">codebase, docs, and tickets</b> \u2014 so its answers are about <b class=\"t-pos\">your work</b>, not generic advice.",
    },
    doraSays: [
      { title: "Why it matters", desc: "\u2022 Connecting AI to your specific codebase and wikis turns it from a generic assistant into a specialized expert.<br>\u2022 Boosts individual effectiveness and improves code quality.<br>\u2022 Speeds up onboarding and reduces time spent searching for information." },
      { title: "How to improve it", desc: "\u2022 Start manually: create shared, version-controlled templates of context that developers can paste into prompts.<br>\u2022 Pilot an automated retrieval system (like RAG or a Model Context Protocol server) for a single, high-impact workflow.<br>\u2022 Scale up by building secure internal APIs to make more data automatically available." },
      { title: "Common obstacles", desc: "\u2022 Connecting AI to messy, inaccurate, or outdated documentation.<br>\u2022 Polluting the AI by indexing bad code or deprecated projects.<br>\u2022 \u2018Context rot\u2019 from overwhelming the AI with too much irrelevant information.<br>\u2022 Security and access control concerns." },
      { title: "How to measure it", desc: "\u2022 Track the frequency of successful RAG queries and retrieval latency.<br>\u2022 Monitor the ratio of context-rich prompts versus simple prompts.<br>\u2022 Survey developers on how often AI responses successfully use internal company data." },
    ],
    teamDoes: [
      { step: "Create context templates", desc: "Build shared <b class=\"t-neu\">briefing packets</b>: project-context file, domain-glossary file, coding-conventions file. Paste into AI sessions." },
      { step: "Pick one pilot for automation", desc: "Choose the most repeated context task and set up <b class=\"t-pos\">RAG</b> or <b class=\"t-pos\">MCP server</b> connecting AI to your repo and ticket system." },
      { step: "Maintain a connection inventory", desc: "Table: data source | <b class=\"t-pos\">connected?</b> | reason. Include <b class=\"t-neg\">deliberately disconnected</b> sources (e.g. HR data \u2014 PII)." },
      { step: "Review what\u2019s indexed monthly", desc: "Remove <b class=\"t-neg\">deprecated projects</b>, <b class=\"t-neg\">archived repos</b>, and <b class=\"t-neg\">outdated wiki sections</b> from AI\u2019s reach." },
    ],
    signals: [
      "AI answers reference <b class=\"t-pos\">your codebase and stories</b> \u2014 not generic advice.",
      "Context setup takes <b class=\"t-pos\">under 5 minutes</b> (down from 15+).",
      "Context templates updated within <b class=\"t-pos\">the last month</b>.",
    ],
  },
  {
    id: "vcs",
    num: "04",
    name: "Strong version control practice",
    owner: "proshore",
    summary: {
      team: "Version control for <b class=\"t-neu\">everything</b> \u2014 code, configs, tests, infra, AI prompts, agent config files. AI makes this a <b class=\"t-pos\">critical safety net</b>.",
      client: "Every change <b class=\"t-pos\">tracked and revertible</b>. AI moves quickly; version control is the <b class=\"t-pos\">safety net</b> that lets it move safely.",
    },
    doraSays: [
      { title: "Why it matters", desc: "\u2022 AI generates code quickly, which can increase instability; version control acts as the critical safety net for quick rollbacks.<br>\u2022 Boosts throughput by easily recreating test environments.<br>\u2022 Amplifies AI's positive influence on individual effectiveness and team performance." },
      { title: "How to improve it", desc: "\u2022 Store everything in version control (code, configs, test scripts, and AI prompts).<br>\u2022 Make small, frequent commits so changes are easy to track or revert.<br>\u2022 Agree on team rules for AI code review and commit message formats.<br>\u2022 Promote trunk-based development to minimize long-lived branches." },
      { title: "Common obstacles", desc: "\u2022 Limited use (only storing application code, but not system configs).<br>\u2022 Frequent or complex merge conflicts." },
      { title: "How to measure it", desc: "\u2022 Measure the time it takes to rebuild an environment from scratch.<br>\u2022 Track the number of active branches and your merge conflict rate.<br>\u2022 Survey teams on commit frequency and reliance on rollback features." },
    ],
    teamDoes: [
      { step: "Extend VCS beyond code", desc: "Audit what\u2019s <b class=\"t-neg\">not versioned</b> today: deployment scripts, env configs, infra. Move them in. Add <b class=\"t-neu\">AI prompt libraries</b> and <b class=\"t-neu\">agent config files</b>." },
      { step: "Agree on AI commit conventions", desc: "How are AI-assisted commits <b class=\"t-neu\">labelled</b>? (e.g. <b class=\"t-neu\">[ai-assisted]</b> tag). Who reviews? Max diff size before <b class=\"t-neg\">must split</b>?" },
      { step: "Enforce small, frequent commits", desc: "Commit at every <b class=\"t-pos\">clean, functional state</b>. <b class=\"t-neg\">No end-of-day mega-commits</b>. AI large change? Break into logical units." },
      { step: "Practice rollbacks monthly", desc: "Pick a recent commit, <b class=\"t-pos\">revert it</b> in staging. Verify clean rollback. <b class=\"t-neg\">No broken</b> unrelated work." },
    ],
    signals: [
      "Average commit size <b class=\"t-pos\">under 200 lines</b> (including AI-assisted).",
      "Any recent commit can be <b class=\"t-pos\">reverted cleanly</b>.",
      "AI prompts and configs are <b class=\"t-pos\">versioned alongside code</b>.",
    ],
  },
  {
    id: "batches",
    num: "05",
    name: "Working in small batches",
    owner: "proshore",
    summary: {
      team: "Smallest possible chunks completed independently. DORA uses the <b class=\"t-neu\">INVEST</b> principle: Independent, Negotiable, Valuable, Estimable, Small, Testable.",
      client: "Work shipped in <b class=\"t-pos\">small, independent slices</b>. AI can generate <b class=\"t-neg\">large changes fast</b>, so small batches keep them <b class=\"t-pos\">reviewable</b> and <b class=\"t-pos\">low risk</b>.",
    },
    doraSays: [
      { title: "Why it matters", desc: "\u2022 AI can generate massive, unstable code changes; small batches make review and testing safe and manageable.<br>\u2022 Creates faster feedback loops and builds quality into the process.<br>\u2022 Amplifies product performance and decreases friction." },
      { title: "How to improve it", desc: "\u2022 Break large user stories into small, vertical slices of value that can be completed in hours.<br>\u2022 Commit and merge work to the main branch daily.<br>\u2022 Use feature flags to hide unfinished work so it can be merged safely.<br>\u2022 Set Work-In-Process (WIP) limits so developers focus on finishing tasks rather than juggling them." },
      { title: "Common obstacles", desc: "\u2022 The false belief that a feature is 'too big' to be broken down.<br>\u2022 Product managers wanting to see an entire feature before releasing it." },
      { title: "How to measure it", desc: "\u2022 Measure your lead time for changes and how often branches are merged to trunk.<br>\u2022 Track the percentage of changes deployed but hidden via feature flags.<br>\u2022 Survey teams on the average lines of code changed per commit." },
    ],
    teamDoes: [
      { step: "Train story-slicing", desc: "30-min session: practice splitting one <b class=\"t-neg\">large story</b> into 3\u20135 <b class=\"t-pos\">small vertical slices</b> of user value." },
      { step: "Set a PR size cap", desc: "Agree on max PR size (e.g. <b class=\"t-neu\">300 lines</b>). AI PRs follow the same cap. <b class=\"t-neg\">No exception</b> for \u2018because AI wrote it.\u2019" },
      { step: "Use feature flags", desc: "Ship <b class=\"t-pos\">small increments</b> behind flags. Code reaches production continuously. Feature stays <b class=\"t-neu\">invisible to users</b> until complete." },
      { step: "Set WIP limits", desc: "Limit WIP to <b class=\"t-neu\">1\u20132 items per developer</b>. AI makes starting many things tempting \u2014 WIP limits force <b class=\"t-pos\">finishing first</b>." },
    ],
    signals: [
      "Average story completion <b class=\"t-pos\">under 3 days</b>.",
      "<b class=\"t-pos\">No PR</b> exceeded the agreed size cap last sprint.",
      "Feature flags <b class=\"t-pos\">actively used</b> \u2014 at least one live at any time.",
    ],
  },
  {
    id: "user",
    num: "06",
    name: "User-centric focus",
    owner: "shared",
    summary: {
      team: "User needs as the North Star. The <b class=\"t-neg\">only capability</b> where low levels <b class=\"t-neg\">actively harm</b> teams using AI \u2014 you ship the wrong thing faster.",
      client: "AI improvements measured against <b class=\"t-pos\">what users actually experience</b>, not just what's faster internally. Without this, AI just helps the team <b class=\"t-neg\">ship the wrong thing faster</b>.",
    },
    doraSays: [
      { title: "Why it matters", desc: "\u2022 AI helps you move faster, but user focus ensures you are actually moving in the right direction.<br>\u2022 If your team lacks user focus, AI will just amplify that dysfunction.<br>\u2022 High user-centricity leads to increased team performance and lower burnout." },
      { title: "How to improve it", desc: "\u2022 Put user feedback and product success metrics directly on developer dashboards.<br>\u2022 Invite engineers to directly observe user testing sessions to build empathy.<br>\u2022 Try spec-driven development to force AI to meet user constraints before writing code." },
      { title: "Common obstacles", desc: "\u2022 The 'feature factory' mindset: focusing only on shipping more features rather than valuable outcomes.<br>\u2022 Adopting AI just for the sake of the technology ('solutionism').<br>\u2022 Organizational silos that hide user feedback from developers." },
      { title: "How to measure it", desc: "\u2022 Track product metrics like adoption rate, retention, and customer satisfaction.<br>\u2022 Check if user goals are clearly represented in project milestones and designs.<br>\u2022 Survey teams on whether user experience is their top priority." },
    ],
    teamDoes: [
      { step: "Add \u2018user outcome\u2019 field to every story", desc: "Required field: \u2018Which user need does this serve?\u2019 If team <b class=\"t-neg\">cannot fill it in</b>, story is <b class=\"t-neg\">not ready</b> for refinement." },
      { step: "Display user metrics in sprint reviews", desc: "Standing dashboard: <b class=\"t-neu\">CSAT</b>, <b class=\"t-neu\">task completion rate</b>, <b class=\"t-neu\">support volume</b>, <b class=\"t-neu\">adoption rate</b>. Visible to <b class=\"t-pos\">developers</b>, not just PMs." },
      { step: "Quarterly user research for devs", desc: "Every developer observes at least one <b class=\"t-pos\">usability test</b> or <b class=\"t-pos\">user interview</b> per quarter. <b class=\"t-neg\">No second-hand summaries</b>." },
      { step: "Kill interventions that miss the user", desc: "Each review: \u2018Did this improve a <b class=\"t-pos\">user metric</b> or only an <b class=\"t-neg\">internal one</b>?\u2019 If only velocity, <b class=\"t-neg\">reconsider</b>." },
    ],
    signals: [
      "Every story has a <b class=\"t-pos\">named user outcome</b> \u2014 not just a technical description.",
      "At least one developer attended <b class=\"t-pos\">user research</b> last quarter.",
      "Team can say how an AI intervention <b class=\"t-pos\">changed a real user\u2019s experience</b>.",
    ],
  },
  {
    id: "platform",
    num: "07",
    name: "Quality internal platform",
    owner: "proshore",
    summary: {
      team: "Shared tools and <b class=\"t-pos\">paved roads</b> for build, test, deploy. AI amplifies org performance <b class=\"t-pos\">only when platform quality is high</b>.",
      client: "A <b class=\"t-pos\">platform layer</b> that gives every team the same AI-ready foundation (context, tools, guardrails), without each team rebuilding it. AI's effect is only <b class=\"t-pos\">strong and positive</b> when this is in place.",
    },
    doraSays: [
      { title: "Why it matters", desc: "\u2022 It acts as the automated safety layer so individual AI coding speed isn't lost to slow deployment or testing bottlenecks.<br>\u2022 Abstracts complexity, making it cheap to fail and fast to recover.<br>\u2022 Amplifies AI's positive influence on organizational performance." },
      { title: "How to improve it", desc: "\u2022 Treat your platform like an internal product and developers as your customers.<br>\u2022 Start by automating the single most painful developer workflow first (a 'minimum viable platform').<br>\u2022 Proactively 'shift down' cognitive load by creating self-service workflows.<br>\u2022 Design the platform so other teams can contribute tools to it." },
      { title: "Common obstacles", desc: "\u2022 Building without user research (the 'build it and they will come' trap).<br>\u2022 The 'ivory tower' approach where a central team dictates tools without collaboration.<br>\u2022 The 'ticket-ops trap' where the platform team just acts as an IT helpdesk.<br>\u2022 Failing to secure long-term executive sponsorship." },
      { title: "How to measure it", desc: "\u2022 Track developer satisfaction using the H.E.A.R.T. framework (Happiness, Engagement, Adoption, Retention, Task success).<br>\u2022 Measure the rate of new teams onboarding to the platform.<br>\u2022 Use DORA metrics (lead time, deployment frequency) for the platform itself and the apps using it." },
    ],
    teamDoes: [
      { step: "Measure environment setup time", desc: "Time from zero to running local env. If <b class=\"t-neg\">more than 1 hour</b>, fix this <b class=\"t-pos\">before any AI investment</b>." },
      { step: "Create golden-path templates", desc: "Starter templates with <b class=\"t-pos\">CI/CD</b>, <b class=\"t-pos\">test setup</b>, <b class=\"t-pos\">linting</b>, and <b class=\"t-pos\">AI tool integration</b> pre-configured." },
      { step: "Enable self-service environments", desc: "Developers spin up, run, tear down <b class=\"t-pos\">without filing a ticket</b>. If AI experiments need <b class=\"t-neg\">permission each time</b>, adoption <b class=\"t-neg\">stalls</b>." },
      { step: "Run a platform feedback loop", desc: "Monthly: \u2018What <b class=\"t-neg\">slowed you down</b> that the platform could handle?\u2019 Prioritise backlog from <b class=\"t-pos\">real answers</b>, not assumptions." },
    ],
    signals: [
      "New developer: zero to deployed in <b class=\"t-pos\">under 2 hours</b>.",
      "New AI intervention trialled in <b class=\"t-pos\">a day, not a sprint</b>.",
      "Platform backlog has <b class=\"t-pos\">delivery team feedback</b> from last month.",
    ],
  },
];

const ADOPTION_STAGES = [
  {
    id: "explore",
    num: "01",
    name: "Explore",
    duration: "e.g. 3 sprints",
    budget: "$50\u2013100",
    budgetNote: "per developer, no strings",
    intent: { team: "Build intuition. Not output.", client: "Build judgement. Not output yet." },
    body: {
      team: "Give every developer a <b class=\"t-pos\">credit budget</b> and a month of <b class=\"t-pos\">permission to play</b>. <b class=\"t-neg\">No deliverable, no demo, no ROI question</b>. Engineers try coding agents on hobby projects, use chat interfaces to explore the codebase, break things in a sandbox. The goal is to feel where AI is <b class=\"t-pos\">sharp</b> and where it <b class=\"t-neg\">bluffs</b>.",
      client: "Roughly <b class=\"t-pos\">3 sprints as a starting example</b>. The team sets the actual pace. Nothing changes externally yet. The team is building judgement about where AI helps and where it bluffs. The one thing this stage asks of you: a clear <b class=\"t-pos\">AI stance</b>. What data AI can touch, what stays off-limits, where the human review point is. Useful for: aligning legal and compliance early, before any pressure to ship is on the table.",
    },
    doList: [
      "Allocate <b class=\"t-pos\">credit budget</b>; <b class=\"t-pos\">no approval needed</b> to spend it.",
      "Weekly 20-min <b class=\"t-neu\">\"what surprised you\"</b> share-out. No slides.",
      "Keep a private <b class=\"t-neg\">\"things AI was confidently wrong about\"</b> list.",
    ],
    dontList: [
      "<b class=\"t-neg\">Don't measure velocity</b>. You'll measure a Hawthorne effect.",
      "<b class=\"t-neg\">Don't mandate a tool</b>. Different engineers will converge on different workflows.",
      "<b class=\"t-neg\">Don't ask for a retrospective</b>. It's too early to generalise.",
    ],
    dora: ["stance"],
    exit: "Every engineer has <b class=\"t-pos\">one concrete opinion</b> about where AI helps them, and one where it doesn't.",
  },
  {
    id: "experiment",
    num: "02",
    name: "Experiment",
    duration: "e.g. 4 sprints",
    budget: "$100\u2013200",
    budgetNote: "per developer, with a one-line intent",
    intent: { team: "Find personal 'ahas' on real work.", client: "Find what actually moves real work." },
    body: {
      team: "Credits now come with a <b class=\"t-pos\">one-line intent</b>. <b class=\"t-pos\">Small bets</b>, on real tickets, at individual scale. Some will <b class=\"t-neg\">fail</b> \u2014 that's the point. The team starts a <b class=\"t-pos\">shared journal</b>: what I tried, what I learned. This is where the team's <b class=\"t-pos\">taste for AI</b> forms.",
      client: "Roughly <b class=\"t-pos\">4 sprints as a starting example</b> \u2014 pace is the team's call. First glimpses of what's possible. The team runs <b class=\"t-pos\">small, low-stakes attempts</b> on real tickets and journals what worked vs what looked impressive but didn't move the work. What you see: an occasional 10-minute show-and-tell, <b class=\"t-neg\">not deliverables</b>. By the end the team can name 3\u20135 things worth investing in \u2014 and 3\u20135 worth stopping.",
    },
    doList: [
      "Run <b class=\"t-neu\">1\u20133 experiments</b> per developer, each <b class=\"t-neu\">\u2264 3 days</b>.",
      "Journal entries are <b class=\"t-pos\">two sentences</b>, not a report.",
      "<b class=\"t-pos\">Name both wins and disappointments</b> publicly.",
    ],
    dontList: [
      "<b class=\"t-neg\">Don't tie credits to outcomes</b>. You're funding learning.",
      "<b class=\"t-neg\">Don't let one engineer's workflow</b> become 'the way.'",
      "<b class=\"t-neg\">Don't skip to the bottleneck yet</b> \u2014 the team is still calibrating.",
    ],
    dora: ["data", "internal-data"],
    exit: "The team can list <b class=\"t-pos\">3\u20135 experiments that changed how they think</b>, and can separate them from experiments that <b class=\"t-neg\">felt impressive but didn't move the work</b>.",
  },
  {
    id: "embed",
    num: "03",
    name: "Embed",
    duration: "ongoing",
    budget: "$150\u2013250",
    budgetNote: "per developer, routed through one intervention",
    intent: "Change one workflow for good.",
    body: {
      team: "Now \u2014 and only now \u2014 the team runs the <b class=\"t-pos\">full five-step method</b> on itself. Map, diagnose, design, guardrail, measure. <b class=\"t-pos\">One bottleneck, one intervention, one cycle</b>. Credits flow mainly to the chosen intervention. Individual exploration doesn't stop, but the team has a <b class=\"t-pos\">shared bet</b> on the table.",
      client: "<b class=\"t-pos\">Ongoing</b> \u2014 each cycle is timeboxed by the team, not fixed up front. The change becomes visible. <b class=\"t-pos\">One specific delivery slowdown</b> gets addressed end-to-end using the 5-step method. What you see: a <b class=\"t-pos\">written before/after review</b> at the end of each cycle \u2014 the kind of evidence you'd show your stakeholders without flinching. The team commits to a decision at every cycle's close.",
    },
    doList: [
      "Run the <b class=\"t-pos\">5-step method end-to-end</b>; <b class=\"t-neg\">don't skip Guardrail</b>.",
      "Measure the <b class=\"t-neu\">bottleneck signal</b> AND the <b class=\"t-neu\">system signal</b>.",
      "Write the cycle review. <b class=\"t-pos\">One page. Honest</b>.",
    ],
    dontList: [
      "<b class=\"t-neg\">Don't chase velocity</b>. Chase the <b class=\"t-pos\">named bottleneck</b>.",
      "<b class=\"t-neg\">Don't let the intervention expand mid-cycle</b>. Finish it, then iterate.",
      "<b class=\"t-neg\">Don't hide failures</b>. The next team needs them.",
    ],
    dora: ["vcs", "batches", "user"],
    exit: "<b class=\"t-pos\">One workflow is measurably different</b>. The team has a written review they'd show leadership without flinching.",
  },
  {
    id: "evolve",
    num: "04",
    name: "Evolve",
    duration: "ongoing",
    budget: "settles by usage",
    budgetNote: "platform-priced once patterns emerge",
    intent: { team: "Make the method the default.", client: "Make this the default way of working." },
    body: {
      team: "AI adoption is now <b class=\"t-pos\">part of how the team works</b>, not a project with an end date. From here the loop runs: <b class=\"t-pos\">Experiment → Embed → Evolve</b>, picking the next bottleneck each pass. <b class=\"t-pos\">Cross-team share-outs</b> replace mandates. Budget settles into a <b class=\"t-pos\">predictable line item</b>, priced by actual use.",
      client: "<b class=\"t-pos\">Ongoing</b>. AI adoption stops being a project and becomes <b class=\"t-pos\">how the team works</b>. The team picks the next slowdown to address on a rhythm that fits them. From here the cycle continues: <b class=\"t-pos\">Experiment → Embed → Evolve</b>, repeated for each new bottleneck. What you see: a periodic review of what changed and what's next. Budget settles into a <b class=\"t-pos\">predictable line item</b> priced by actual use, with <b class=\"t-neg\">no separate AI initiative to fund</b>.",
    },
    doList: [
      "<b class=\"t-pos\">Re-run the method every quarter</b>. 15-minute bottleneck check per retro between.",
      "Feed <b class=\"t-pos\">cross-team learnings</b> into the platform \u2014 <b class=\"t-neg\">don't rebuild</b>.",
      "<b class=\"t-pos\">Retire interventions</b> that <b class=\"t-neg\">no longer earn their keep</b>.",
    ],
    dontList: [
      "<b class=\"t-neg\">Don't let the method become ceremony</b>. If the team isn't learning, stop.",
      "<b class=\"t-neg\">Don't centralise tool choice</b>. Centralise the <b class=\"t-pos\">thinking</b>, not the stack.",
      "<b class=\"t-neg\">Don't celebrate usage</b>. Celebrate <b class=\"t-pos\">outcomes</b>.",
    ],
    dora: ["platform", "stance"],
    exit: "This stage <b class=\"t-pos\">doesn't end</b>. It loops back into <b class=\"t-pos\">Experiment → Embed → Evolve</b> for the next bottleneck. The team is now an <b class=\"t-pos\">adopter</b>, not a project.",
  },
];

// ---- Client-view data ----

const CLIENT_OUTCOMES = [
  {
    num: "01",
    title: "Faster delivery cycles",
    body: "Cycles complete in <b class=\"t-pos\">fewer days</b> because the repetitive work around them shrinks.",
  },
  {
    num: "02",
    title: "Predictable releases",
    body: "<b class=\"t-pos\">Less last-minute scrambling</b>: refinement, testing, and release notes are prepared in parallel, not at the end.",
  },
  {
    num: "03",
    title: "Reduced bottlenecks",
    body: "Whichever stage is <b class=\"t-pos\">slowing the team this quarter</b> is the one we improve next, <b class=\"t-neg\">not the loudest tool on the market</b>.",
  },
  {
    num: "04",
    title: "Faster onboarding",
    body: "New team members reach <b class=\"t-pos\">productive work in days, not weeks</b>, because project knowledge is captured and retrievable.",
  },
  {
    num: "05",
    title: "Quality stays consistent",
    body: "Documentation, QA prep, and code review <b class=\"t-pos\">keep up with delivery speed</b> instead of <b class=\"t-neg\">falling behind</b>.",
  },
  {
    num: "06",
    title: "Scales without re-staffing",
    body: "The same team handles <b class=\"t-pos\">more scope</b> as the work-around-the-work gets cheaper.",
  },
];

const CLIENT_PERSPECTIVES = {
  client: [
    "Faster releases without quality slipping",
    "Predictable cycles, fewer surprise delays",
    "Bottlenecks named and fixed, not papered over",
    "A team that scales scope without growing headcount",
  ],
  team: [
    "Less repetitive busywork: drafting, reformatting, status updates",
    "Better collaboration: refinement sharpens ideas instead of writing them",
    "Less context-switching: the work-around-the-work shrinks",
    "More time on the high-judgement work that actually needs a human",
  ],
};

// Recognisable AI initiatives, grouped by the delivery stage where they fit.
// A team only runs the ones that match where their work currently slows down.
// This is an option list, not a checklist.
const CLIENT_EXAMPLES = [
  {
    stage: "Refine",
    note: "Make stories ready before the sprint starts",
    items: [
      {
        title: "AI backlog refinement",
        body: "Acceptance criteria and open questions drafted from the brief, so refinement meetings <b class=\"t-pos\">sharpen ideas</b> instead of writing them.",
      },
      {
        title: "AI knowledge retrieval",
        body: "One question, one answer, sourced from the team's <b class=\"t-pos\">actual docs and tickets</b>, not generic advice.",
      },
      {
        title: "AI-assisted brief drafting",
        body: "Raw ideas turned into <b class=\"t-pos\">structured briefs</b> with assumptions, risks, and open questions named upfront.",
      },
    ],
  },
  {
    stage: "Develop",
    note: "Keep delivery moving without quality slipping",
    items: [
      {
        title: "AI-supported code review",
        body: "Routine review noise (style, obvious bugs, missing tests) handled <b class=\"t-pos\">before</b> the human reviewer opens the PR.",
      },
      {
        title: "AI onboarding assistant",
        body: "A new joiner asks the project's own knowledge base (codebase, decisions, conventions) and gets answers <b class=\"t-pos\">in their first hour</b>.",
      },
      {
        title: "AI pair programming",
        body: "Engineers work with AI in their editor for the routine bits (boilerplate, refactors, repetitive edits) and keep <b class=\"t-pos\">judgement on the human</b>.",
      },
    ],
  },
  {
    stage: "Test",
    note: "Cut handover delay between dev and QA",
    items: [
      {
        title: "AI-assisted QA prep",
        body: "Test cases and edge-case checklists drafted from acceptance criteria, ready <b class=\"t-pos\">before</b> dev hands work over.",
      },
      {
        title: "AI test data generation",
        body: "Realistic, varied test fixtures generated on demand, covering the <b class=\"t-pos\">edge cases</b> humans tend to miss.",
      },
      {
        title: "AI flaky test triage",
        body: "Recurring red builds clustered and explained, so QA spends time on <b class=\"t-pos\">real failures</b>, not noise.",
      },
    ],
  },
  {
    stage: "Deploy",
    note: "Keep releases predictable and recoverable",
    items: [
      {
        title: "AI-generated documentation",
        body: "Release notes, runbooks, and API docs drafted from the diff and reviewed by the team, kept <b class=\"t-pos\">in sync with code</b>.",
      },
      {
        title: "AI release risk summary",
        body: "Each release ships with a <b class=\"t-pos\">plain-language summary</b> of what's risky, what's tested, and what to watch, generated from the diff.",
      },
      {
        title: "AI rollback drafts",
        body: "Rollback steps drafted alongside the release, so reverting is <b class=\"t-pos\">prepared, not improvised</b> at 2am.",
      },
    ],
  },
  {
    stage: "Monitor",
    note: "Reduce reporting and on-call overhead",
    items: [
      {
        title: "Ops reporting automation",
        body: "Status updates and stakeholder summaries assembled from <b class=\"t-pos\">real signals</b>, not retyped from Jira every Friday.",
      },
      {
        title: "AI support workflows",
        body: "Recurring support questions answered from <b class=\"t-pos\">resolved-ticket history</b>; humans handle the genuinely new ones.",
      },
      {
        title: "AI on-call assistant",
        body: "Alerts clustered and a <b class=\"t-pos\">probable cause</b> drafted before on-call opens their laptop, so triage starts from a hypothesis, not a blank page.",
      },
    ],
  },
];

const CLIENT_INDICATORS = [
  {
    label: "Cycle time",
    body: "Days from refined story to release. <b class=\"t-neu\">Watched per sprint</b>.",
  },
  {
    label: "Onboarding time",
    body: "Days for a new joiner to ship their <b class=\"t-pos\">first reviewed change</b>.",
  },
  {
    label: "Repetitive-task share",
    body: "Percentage of a developer's week on tasks the method <b class=\"t-pos\">targets for automation</b>.",
  },
  {
    label: "QA cycle length",
    body: "Hours between dev handover and <b class=\"t-pos\">signed-off testing</b>.",
  },
  {
    label: "Doc freshness",
    body: "Percentage of project docs <b class=\"t-pos\">touched in the last sprint</b>.",
  },
  {
    label: "Coordination overhead",
    body: "Meeting hours per delivered story; expected to <b class=\"t-pos\">fall</b> as written context improves.",
  },
];

const CLIENT_SAFETY_PRINCIPLES = [
  {
    title: "A named human owns every shipped change",
    body: "AI drafts, <b class=\"t-pos\">humans decide</b>. Every line of code, every release note, every AI-drafted ticket has a person who can read it, defend it, and roll it back.",
  },
  {
    title: "Review point, decision boundary, escape hatch",
    body: "<b class=\"t-pos\">Designed in upfront</b>, not added after the first incident. Every AI use names: who reviews it, where it stops, and how to switch it off cleanly.",
  },
  {
    title: "AI never crosses the production line alone",
    body: "Anything touching customers, users, or production data has a <b class=\"t-pos\">human sign-off</b> before it ships. <b class=\"t-neg\">Non-negotiable</b>.",
  },
  {
    title: "Shadow-AI is a signal, not a problem",
    body: "When people work around governance, the governance is <b class=\"t-neg\">too narrow</b>. We review quarterly so the <b class=\"t-pos\">sanctioned path stays the easy path</b>.",
  },
];

Object.assign(window, {
  CONVICTIONS,
  STAGES,
  METHOD_STEPS,
  WORKED_EXAMPLE,
  SEVERITY_LEVELS,
  DORA_CAPABILITIES,
  ADOPTION_STAGES,
  CLIENT_OUTCOMES,
  CLIENT_PERSPECTIVES,
  CLIENT_EXAMPLES,
  CLIENT_INDICATORS,
  CLIENT_SAFETY_PRINCIPLES,
});