@jterrats/open-orchestra 1.0.1 → 1.0.3

package/docs/backlog/docs-public-internal-package-hygiene-story.md

@@ -0,0 +1,62 @@
+# Story: Classify docs and tighten package documentation contents
+
+Backlog Item ID: DOCS-PUBLIC-INTERNAL-PACKAGE-HYGIENE
+
+## User Story
+
+As a release manager, I want documentation classified as public, internal,
+backlog, experiment, or package-required so that the public site and npm package
+ship only the documentation intended for users while internal planning artifacts
+remain available in the repository.
+
+## Background
+
+The public site does not currently render all files under `docs/`; it links to a
+small subset and serves its own `site/public/architecture.mmd`. The npm package,
+however, includes the full `docs/` tree through `package.json.files`. As
+backlog, prompt-bank experiments, diagram experiments, and internal dogfooding
+notes grow, package contents can become noisy.
+
+Before final release, Open Orchestra should define which docs are:
+
+- public user documentation;
+- public package documentation;
+- internal product/backlog material;
+- experiment/provenance artifacts;
+- site-only assets.
+
+## Acceptance Criteria
+
+- Inventory all files under `docs/` and classify each as public, internal,
+  backlog, experiment, diagram artifact, or package-required.
+- Identify which docs are linked from README.
+- Identify which docs are linked from the public site.
+- Identify which docs are required by runtime/package behavior.
+- Decide whether `package.json.files` should include all docs or a narrower
+  allowlist.
+- If narrowing package contents, update `package.json.files` and validate with
+  `npm pack --dry-run`.
+- Preserve repository traceability for internal/backlog/experiment docs even if
+  they are excluded from npm.
+- Document the classification policy so future docs land in the right location.
+
+## Non-Goals
+
+- Redesigning the public site.
+- Deleting historical evidence or backlog without an explicit archive decision.
+- Moving docs into a SaaS registry.
+
+## Suggested Implementation
+
+- Add a docs classification manifest or policy document.
+- Optionally reorganize directories only when links can be updated safely.
+- Update `package.json.files` if package hygiene requires it.
+- Run `npm pack --dry-run` and verify expected docs are included/excluded.
+
+## T-Shirt Size
+
+S
+
+## Suggested Owners
+
+Technical Writer, Release Manager, Product Owner.

package/docs/backlog/prompt-bank-registry-epic.md

@@ -0,0 +1,159 @@
+# Epic: Offline-first prompt bank registry and reference API
+
+Backlog Item ID: PROMPT-BANK-REGISTRY-EPIC
+
+## Epic Story
+
+As a platform owner, I want Open Orchestra to maintain a versioned prompt bank
+that works offline from the repository and can optionally sync categorized
+references from an external bucket/API, so that agents can retrieve high-quality
+prompt guidance on demand without bloating skills or requiring internet access
+for core operation.
+
+## Relationship
+
+Parent/related epic: #333 Advisory supervisor for local findings and guarded
+GitHub worker.
+
+This epic complements the advisory/SaaS direction. The advisory supervisor can
+produce findings that improve prompt bank entries, while the prompt bank
+registry provides curated guidance that agents can retrieve safely during local
+or SaaS-backed execution.
+
+## Problem
+
+Skills should stay compact and role-scoped. If every diagram, QA, security,
+architecture, or workflow reference is embedded directly into skills, agent
+context becomes expensive and hard to govern. If references live only in a SaaS
+or bucket, local/offline operation breaks.
+
+Open Orchestra needs a hybrid model:
+
+- a small canonical prompt bank in the repo for offline execution;
+- external categorized references for richer examples and reusable patterns;
+- an API/retrieval layer that returns only the minimum relevant guidance;
+- guardrails that prevent raw prompt injection, secrets, or source-specific
+  content from becoming reusable rules.
+
+## MVP Outcome
+
+- Local prompt bank manifest stored in the repo and packaged with the CLI.
+- Prompt bank entries categorized by role, phase, skill, artifact type, runtime,
+  safety level, and offline eligibility.
+- Retrieval command/API that resolves prompt entries by task intent, role, phase,
+  and runtime signals.
+- Skills load compact baseline rules first and request prompt bank references
+  only when task context needs them.
+- External bucket/API contract documented but optional.
+- Offline mode uses local prompt bank only and degrades clearly when an external
+  reference is unavailable.
+
+## To-Be Outcome
+
+- SaaS-backed prompt registry with tenant/project categorization, quality
+  scoring, usage telemetry, approval workflows, and API-based retrieval.
+- Bucket-backed prompt artifacts with signed manifests, checksums, versioning,
+  retention policy, and safe caching.
+- Advisory supervisor can propose prompt bank improvements as classified
+  findings, but human approval is required before promotion.
+- Registry supports cross-runtime references for Codex, Claude, Cursor, Copilot,
+  generic agents, and local model runners.
+
+## Proposed Child Stories
+
+### Story 1: Local Prompt Bank Manifest
+
+As an agent runtime, I want a local manifest of prompt bank entries so that I can
+retrieve approved guidance without internet access.
+
+Acceptance criteria:
+
+- Defines entry schema with id, title, category, role, phase, skill, runtime,
+  artifact type, tags, version, source-free flag, safety level, checksum, and
+  path.
+- Includes initial categories for diagrams, QA evidence, advisory findings,
+  security review, story mapping, and runtime coordination.
+- Excludes source-specific PDF text, business labels, secrets, and raw user
+  prompts from reusable entries.
+- Includes tests for schema validation and manifest loading.
+
+### Story 2: Prompt Bank Retrieval API
+
+As a skill loader, I want to retrieve prompt bank entries by runtime need so that
+skills stay small and context is loaded on demand.
+
+Acceptance criteria:
+
+- Provides CLI/API retrieval by role, phase, task intent, skill id, runtime, and
+  tags.
+- Returns summaries first and full content only when requested.
+- Enforces max entry count and max token/character budget.
+- Supports offline-only mode.
+- Emits evidence showing which entries were consulted.
+
+### Story 3: External Bucket/API Contract
+
+As a platform operator, I want an external prompt registry contract so that rich
+references can be stored outside the package without making the package depend
+on SaaS.
+
+Acceptance criteria:
+
+- Documents bucket layout, manifest format, checksums, signed URLs or equivalent
+  access strategy, cache policy, and fallback behavior.
+- Defines API endpoints for search, resolve, fetch, health, and version checks.
+- Requires tenant/project scoping for SaaS mode.
+- Requires redaction and prompt-injection checks before storing or serving
+  entries.
+
+### Story 4: Prompt Promotion Workflow
+
+As a maintainer, I want prompt bank changes to go through review so that weak or
+unsafe prompt guidance is not promoted automatically.
+
+Acceptance criteria:
+
+- Advisory findings can propose prompt entries but cannot promote them directly.
+- Promotion requires classification, safety review, owner approval, and
+  validation evidence.
+- Records provenance: source task, finding id, reviewer, reason, version, and
+  superseded entries.
+- Supports deprecation and rollback of prompt entries.
+
+## Acceptance Criteria
+
+- Epic documents offline-first and SaaS-ready architecture for prompt bank
+  retrieval.
+- Local prompt bank remains the source of truth for core operation.
+- External bucket/API is optional and never required for baseline skills.
+- Prompt entries are categorized and retrievable by role, phase, skill, runtime,
+  artifact type, tags, and safety level.
+- Retrieval is bounded to avoid context bloat.
+- Source-specific text, secrets, raw user prompts, and prompt-injection content
+  are excluded or blocked from reusable prompt entries.
+- Advisory supervisor integration is defined without allowing automatic
+  promotion.
+- Child stories are independently executable.
+
+## Non-Goals
+
+- Full SaaS implementation in the first story.
+- Storing raw prompts/responses by default.
+- Replacing existing skills with a remote-only prompt system.
+- Making internet access mandatory for local workflows.
+
+## Risks
+
+- Context bloat if retrieval is not aggressively bounded.
+- Prompt injection through external registry entries.
+- Secret leakage from raw prompts, lessons learned, or generated artifacts.
+- Drift between local prompt bank and external registry.
+- SaaS dependency creeping into offline workflows.
+
+## T-Shirt Size
+
+L
+
+## Suggested Owners
+
+Product Owner, Architect, Security, Developer, QA.

package/docs/backlog/site-docs-manifest-story.md

@@ -0,0 +1,56 @@
+# Story: Public site consumes documentation manifest instead of hardcoded copy
+
+Backlog Item ID: SITE-DOCS-MANIFEST
+
+Parent: #340
+
+## User Story
+
+As a documentation maintainer, I want the public site to render content from
+versioned documentation or a docs manifest instead of duplicating copy in React
+components, so that the site, README, and docs stay aligned with less manual
+maintenance.
+
+## Background
+
+The public site currently keeps much of its product copy and section metadata in
+`site/src/App.jsx`. That creates duplicate maintenance when docs change. The
+site should use documentation as the source of truth where possible, while React
+components own layout, interaction, and visual presentation.
+
+## Acceptance Criteria
+
+- Defines a public docs manifest or equivalent content source for site sections.
+- Site content for quickstart, command surface, runtime adapters, release
+  readiness, architecture, and docs links is derived from versioned docs or
+  manifest entries instead of duplicated hardcoded copy.
+- `site/src/App.jsx` keeps layout/component logic and no longer owns long-form
+  documentation copy.
+- Site build fails or reports a clear validation error when the manifest points
+  to a missing doc.
+- README/docs/site links stay consistent after the migration.
+- Public site still builds with `npm run site:build`.
+- The implementation avoids runtime network calls; content should be bundled at
+  build time or served from local static assets.
+
+## Non-Goals
+
+- Building a full CMS.
+- Rendering every internal or backlog doc on the public site.
+- Redesigning the whole landing page.
+
+## Suggested Implementation
+
+- Create a manifest such as `docs/site-manifest.json` or
+  `site/src/site-content.js` generated from docs.
+- Prefer Markdown/frontmatter or a small typed JSON schema for section metadata.
+- Add a validation script for manifest paths.
+- Keep public/internal classification aligned with #340.
+
+## T-Shirt Size
+
+S
+
+## Suggested Owners
+
+Technical Writer, UX/UI Designer, Developer.

package/docs/dev-team-specialist-role-profiles.md

@@ -159,7 +159,7 @@ Expected evidence:
 
 ## Prompt Registry Integration
 
-The setup-agents prompt registry pattern is now part of Open Orchestra as a stack-agnostic `.generated-prompts/` scaffold. Specialist roles should use it as follows:
+The prompt registry pattern is now part of Open Orchestra as a stack-agnostic `.generated-prompts/` scaffold. Specialist roles should use it as follows:
 
 - Tech Lead reads `code.md`, `services.md`, and `docs.md` before coordinating implementation plans.
 - SDET reads `tests.md` before adding Playwright or regression coverage.

package/docs/diagrams/diagram-master-prompt.md

@@ -0,0 +1,207 @@
+# Diagram Master Prompt
+
+Use this prompt when generating, recreating, validating, or exporting diagrams.
+It is source-free and applies to architecture, workflow, state, sequence,
+infrastructure, timeline, roadmap, story map, swimlane, and integration
+diagrams.
+
+## Role
+
+You are producing a diagram artifact that must be useful to humans and safe to
+handoff. Prioritize semantic correctness, readable layout, editable sources,
+visual clarity, and validation evidence.
+
+## Classify The Work
+
+Before drawing, classify the request:
+
+- `semantic`: explain an idea or system. Mermaid is usually acceptable.
+- `inspired-by-reference`: borrow structure or style, but exact fidelity is not
+  required.
+- `recreation`: reproduce a source reference. Acceptance is pixel-perfect source
+  fidelity unless the user explicitly accepts an approximation.
+
+For `recreation`, inventory every visible source element before drawing:
+containers, labels, icons, connectors, arrowheads, line styles, colors, borders,
+spacing, rotations, z-order, and page/canvas bounds.
+
+For source-free diagrams, create a diagram contract before drawing:
+
+- purpose and audience;
+- required nodes, groups, containers, and annotations;
+- relationships and connector intent;
+- expected reading flow;
+- target format and validation criteria;
+- known constraints or non-goals.
+
+## Choose The Target
+
+Use Mermaid first when the goal is semantic documentation, markdown-native
+review, fast validation, or offline evidence.
+
+Use draw.io XML or equivalent editable geometry when the goal requires exact
+layout, controlled connector anchors, bend points, line jumps, rotated labels,
+manual label lanes, or SVG parity.
+
+Use a collaborative visual tool when the goal is stakeholder editing, live
+review, or a team-owned visual board.
+
+Do not treat Mermaid as a pixel-perfect recreation target when exact geometry,
+icons, connector paths, rotations, or reference styling are acceptance criteria.
+
+## Drafting Rules
+
+- Use domain language from the task, but keep labels short enough to remain
+  readable.
+- Group related elements in containers only when the group adds meaning.
+- Preserve clear reading flow from entry points to outcomes.
+- Give repeated shapes consistent sizing, padding, typography, and spacing.
+- Keep cards, groups, labels, and connector lanes visually balanced across the
+  canvas.
+- Avoid decorative complexity unless it supports the diagram's purpose.
+
+## Layout And Reflow
+
+After placing real text, subcards, chips, icons, labels, badges, and internal
+connectors, run a global layout reflow before accepting the render.
+
+For every composite container, validate actual rendered child bounds against
+parent bounds. Children include text labels, nested boxes, badges, icons,
+internal connectors, annotation anchors, metadata chips, and arrowheads.
+
+If any child touches a parent edge, clips, overflows, crowds another child, or
+reduces padding below the intended minimum, grow the parent container or move
+children before shrinking text.
+
+When a parent container grows, recalculate neighboring element positions,
+connector routes, connector labels, annotation labels, and page/canvas bounds.
+A local fix is incomplete until the whole canvas passes again.
+
+## Text And Bounded Labels
+
+Long text must be layout-managed. Re-evaluate wrapping, line count, width, and
+placement for every note, annotation, card title, legend item, badge, pill, and
+connector label.
+
+Text inside bounded elements must fit inside its own shape. If text grows beyond
+the available width, wraps poorly, overlaps another element, or visually escapes
+its shape, split it into multiple lines, grow the containing shape, or move the
+element.
+
+Treat text wrapping as a geometry change. After any bounded text wraps to more
+lines, recalculate the rendered bounding box and revalidate connector lanes,
+neighboring labels, parent boundaries, and page bounds. The expanded box must
+not cover a connector, border, arrowhead, or nearby element it previously
+cleared.
+
+Do not use label backgrounds as a visual patch. A label background must not
+hide, interrupt, or visually erase the connector it describes.
+
+## Connectors
+
+Every connector must have an explicit source, target, semantic intent, endpoint
+type, and preferred anchor side before final routing.
+
+Connector intent determines the endpoint:
+
+- a connector targeting a group or boundary stops at that boundary edge;
+- a connector targeting a child element visibly attaches to that child;
+- a connector must not drift inside a container unless the interior target is
+  intentional and unambiguous.
+
+Prefer the simplest readable connector route:
+
+- straight when source and target have clear line-of-sight;
+- one orthogonal bend when it improves readability;
+- curves, multi-bend paths, diagonals, or jumps only when they avoid a real
+  obstacle, crossing, or ambiguous relationship.
+
+Before accepting a curved or multi-bend connector, verify that a straight or
+orthogonal route would collide with an element, label, boundary, or reserved
+lane. If no collision exists, simplify the route.
+
+Reserve connector-label lanes after final element positions are known. A
+connector label must clear the whole connector stroke, arrowhead, crossing
+point, border, and adjacent labels after final wrapping and padding.
+
+If a connector label collides with a route, evaluate fixes in this order:
+
+1. move the label to a clear lane;
+2. reroute the connector;
+3. move one of the connected elements;
+4. grow or reflow the containing region.
+
+## Z-Order And Visual Integrity
+
+Connectors and arrowheads must remain visible and must not sit hidden behind the
+elements they connect. Labels must not obscure the target they describe.
+
+Avoid connector lines crossing over containers, labels, or important symbols
+whenever practical. If crossings are unavoidable, use clear spacing or line
+jumps where the target format supports them.
+
+Validate annotation target clarity: annotation arrows must visibly land on the
+element or line they describe, and annotation text must not obscure the target.
+
+## Validation Loop
+
+Before accepting any rendered diagram, run a whole-canvas acceptance matrix:
+
+- semantic completeness;
+- text fit;
+- parent containment;
+- connector endpoints;
+- connector route simplicity;
+- connector-label clearance;
+- label-to-label clearance;
+- z-order and arrowhead visibility;
+- whitespace balance;
+- page/canvas bounds;
+- editable-source/render parity when an editable source exists.
+
+After every correction, re-render and inspect the whole canvas again. A local
+fix is incomplete until no new collisions, hidden endpoints, containment
+failures, or whitespace problems appear elsewhere.
+
+A regenerated version must materially change geometry when it claims to fix a
+visual finding. If the same collision, overflow, endpoint gap, or unnecessary
+route persists across versions, stop re-rendering and change the layout
+strategy: move elements, grow containers, reserve a different lane, or reroute
+the connector.
+
+Do not deliver the first render of a source-free diagram unless the complete
+acceptance matrix passes.
+
+## Evidence To Record
+
+Record the following before handoff:
+
+- target classification: `semantic`, `inspired-by-reference`, or `recreation`;
+- chosen output target and reason;
+- final artifact paths;
+- final render pass number;
+- whether text wrapping changed geometry;
+- whether parent containment passed after final reflow;
+- whether connector endpoints match their semantic targets;
+- whether curved or multi-bend connectors have concrete obstacle reasons;
+- source-vs-output gaps for recreations;
+- residual visual risks, if any.
+
+## Final Artifact Hygiene
+
+Before final delivery, keep only:
+
+- accepted editable source;
+- accepted rendered output;
+- prompt master or final prompt when it adds traceability;
+- minimum QA evidence needed for review;
+- short handoff note with final paths and residual risks.
+
+Archive or exclude intermediate previews, failed renders, temporary prompts,
+superseded SVGs, one-off correction notes, and source-specific prompt fragments.
+Keep audit-relevant iterations in workflow evidence, an explicit archive folder,
+or an ignored output location.
+
+Do not promote source-specific text, raw user prompts, secrets, or one-off
+coordinates into reusable prompt guidance. Rewrite reusable learnings as
+source-free rules before adding them to the prompt bank.

package/docs/diagrams/enterprise-set/README.md

@@ -0,0 +1,22 @@
+# Enterprise Diagram Set
+
+Task: DIAGRAM-ENTERPRISE-PROCESS-TIMELINE-SET
+
+## Diagrams
+
+1. `salesforce-enterprise-architecture.svg`
+   - Salesforce enterprise solution architecture with web, mobile,
+     integrations, SAP, Oracle, AWS, and on-prem systems.
+2. `lead-to-account-swimlanes.svg`
+   - Swimlane process from lead prospecting through account conversion.
+3. `product-implementation-timeline.svg`
+   - Multi-year product implementation timeline from discovery to release.
+
+## Validation Focus
+
+- Text fits inside cards, chips, labels, swimlane cells, and milestone blocks.
+- Parent regions contain all child elements with padding.
+- Connector labels sit in lanes and do not hide connector strokes.
+- Long labels are wrapped instead of escaping their shapes.
+- The diagrams are source-free candidates and should be reviewed against their
+  stated intent, not against a visual reference.

package/docs/diagrams/enterprise-set/lead-to-account-swimlanes.svg

@@ -0,0 +1,38 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="1500" height="920" viewBox="0 0 1500 920" role="img" aria-labelledby="title desc">
+  <title id="title">Lead prospecting to account conversion swimlanes</title>
+  <desc id="desc">Swimlane process from lead prospecting through qualification, account conversion, and customer onboarding.</desc>
+  <defs><marker id="arrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="8" markerHeight="8" orient="auto"><path d="M0 0 L10 5 L0 10 z" fill="#475569"/></marker>
+  <style>.font{font-family:Arial,Helvetica,sans-serif}.title{font-size:28px;font-weight:700;fill:#172033}.sub{font-size:13px;fill:#4b596c}.laneLabel{font-size:13px;font-weight:700;fill:#526174;text-transform:uppercase}.laneA{fill:#f3f8ff}.laneB{fill:#f7fbf5}.laneC{fill:#fff7ed}.laneD{fill:#f8f5ff}.laneE{fill:#fff8f8}.border{fill:none;stroke:#94a3b8;stroke-width:1.5}.step{fill:#fff;stroke:#64748b;stroke-width:1.5}.stepTitle{font-size:14px;font-weight:700;fill:#1f2a3d}.small{font-size:12px;fill:#445267}.edge{fill:none;stroke:#475569;stroke-width:2;marker-end:url(#arrow)}.edgeSoft{fill:none;stroke:#64748b;stroke-width:2;stroke-dasharray:7 5;marker-end:url(#arrow)}.pill{fill:#fff;stroke:#d8dee8;stroke-width:1}.pillText{font-size:12px;fill:#263445}</style></defs>
+  <rect width="1500" height="920" fill="#fff"/>
+  <g class="font">
+    <text class="title" x="48" y="56">Lead Prospecting To Account Conversion</text>
+    <text class="sub" x="48" y="80">Source-free swimlane process candidate for lead lifecycle validation.</text>
+    <rect class="border" x="48" y="126" width="1404" height="724" rx="16"/>
+    <rect class="laneA" x="48" y="126" width="1404" height="126" rx="16"/><text class="laneLabel" x="72" y="172">Marketing</text>
+    <rect class="laneB" x="48" y="252" width="1404" height="126"/><text class="laneLabel" x="72" y="298">Sales Development</text>
+    <rect class="laneC" x="48" y="378" width="1404" height="126"/><text class="laneLabel" x="72" y="424">Account Executive</text>
+    <rect class="laneD" x="48" y="504" width="1404" height="168"/><text class="laneLabel" x="72" y="550">Sales Operations</text>
+    <rect class="laneE" x="48" y="672" width="1404" height="178" rx="16"/><text class="laneLabel" x="72" y="718">Customer Success</text>
+    <path class="border" d="M48 252 H1452 M48 378 H1452 M48 504 H1452 M48 672 H1452"/>
+
+    <rect class="step" x="212" y="158" width="150" height="62" rx="10"/><text class="stepTitle" x="232" y="184">Capture Lead</text><text class="small" x="232" y="206">campaign form</text>
+    <rect class="step" x="420" y="158" width="160" height="62" rx="10"/><text class="stepTitle" x="440" y="184">Score + Enrich</text><text class="small" x="440" y="206">fit and intent</text>
+    <rect class="step" x="640" y="284" width="166" height="62" rx="10"/><text class="stepTitle" x="660" y="310">SDR Qualification</text><text class="small" x="660" y="332">BANT / ICP</text>
+    <rect class="step" x="866" y="284" width="164" height="62" rx="10"/><text class="stepTitle" x="886" y="310">Create Meeting</text><text class="small" x="886" y="332">accepted handoff</text>
+    <rect class="step" x="866" y="410" width="164" height="70" rx="10"/><text class="stepTitle" x="886" y="436">Discovery</text><text class="small" x="886" y="458">pain, value,</text><text class="small" x="886" y="474">decision process</text>
+    <rect class="step" x="1090" y="410" width="166" height="70" rx="10"/><text class="stepTitle" x="1110" y="436">Opportunity</text><text class="small" x="1110" y="458">qualified pipeline</text><text class="small" x="1110" y="474">next step set</text>
+    <rect class="step" x="1090" y="546" width="166" height="82" rx="10"/><text class="stepTitle" x="1110" y="572">Convert Lead</text><text class="small" x="1110" y="594">account, contact,</text><text class="small" x="1110" y="612">opportunity</text>
+    <rect class="step" x="1282" y="546" width="132" height="82" rx="10"/><text class="stepTitle" x="1300" y="572">Data QA</text><text class="small" x="1300" y="594">dedupe and</text><text class="small" x="1300" y="612">ownership</text>
+    <rect class="step" x="1282" y="724" width="132" height="78" rx="10"/><text class="stepTitle" x="1300" y="750">Onboard</text><text class="small" x="1300" y="772">welcome plan</text><text class="small" x="1300" y="790">success owner</text>
+
+    <path class="edge" d="M362 189 H420"/><rect class="pill" x="370" y="162" width="42" height="20" rx="4"/><text class="pillText" x="378" y="176">raw</text>
+    <path class="edge" d="M580 189 H610 Q640 189 640 315"/><rect class="pill" x="592" y="214" width="82" height="20" rx="4"/><text class="pillText" x="600" y="228">MQL route</text>
+    <path class="edge" d="M806 315 H866"/><rect class="pill" x="820" y="288" width="34" height="20" rx="4"/><text class="pillText" x="828" y="302">SQL</text>
+    <path class="edge" d="M948 346 V410"/><rect class="pill" x="966" y="368" width="76" height="20" rx="4"/><text class="pillText" x="974" y="382">meeting held</text>
+    <path class="edge" d="M1030 445 H1090"/><rect class="pill" x="1040" y="418" width="38" height="20" rx="4"/><text class="pillText" x="1048" y="432">SAO</text>
+    <path class="edge" d="M1173 480 V546"/><rect class="pill" x="1192" y="508" width="92" height="20" rx="4"/><text class="pillText" x="1200" y="522">conversion</text>
+    <path class="edge" d="M1256 587 H1282"/><rect class="pill" x="1256" y="518" width="76" height="20" rx="4"/><text class="pillText" x="1264" y="532">validate</text>
+    <path class="edge" d="M1348 628 V724"/><rect class="pill" x="1364" y="660" width="76" height="38" rx="4"/><text class="pillText" x="1372" y="676">handoff</text><text class="pillText" x="1372" y="692">package</text>
+    <path class="edgeSoft" d="M640 330 H560 Q532 330 532 220"/><rect class="pill" x="514" y="280" width="106" height="38" rx="4"/><text class="pillText" x="522" y="296">recycle if not</text><text class="pillText" x="522" y="312">sales-ready</text>
+  </g>
+</svg>

package/docs/diagrams/enterprise-set/product-implementation-timeline.svg

@@ -0,0 +1,45 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="1500" height="860" viewBox="0 0 1500 860" role="img" aria-labelledby="title desc">
+  <title id="title">Product implementation timeline</title>
+  <desc id="desc">Two to three year product implementation timeline from discovery through release and scale.</desc>
+  <defs><marker id="arrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="8" markerHeight="8" orient="auto"><path d="M0 0 L10 5 L0 10 z" fill="#475569"/></marker>
+  <style>.font{font-family:Arial,Helvetica,sans-serif}.title{font-size:28px;font-weight:700;fill:#172033}.sub{font-size:13px;fill:#4b596c}.axis{stroke:#475569;stroke-width:3;marker-end:url(#arrow)}.tick{stroke:#64748b;stroke-width:1.5}.year{font-size:13px;font-weight:700;fill:#526174}.phase{fill:#fff;stroke:#64748b;stroke-width:1.5}.p1{fill:#f3f8ff}.p2{fill:#f7fbf5}.p3{fill:#fff7ed}.p4{fill:#f8f5ff}.p5{fill:#fff8f8}.phaseTitle{font-size:15px;font-weight:700;fill:#1f2a3d}.small{font-size:12px;fill:#445267}.label{font-size:13px;font-weight:700;fill:#526174;text-transform:uppercase}.milestone{fill:#fff;stroke:#64748b;stroke-width:1.5}.diamond{fill:#fff;stroke:#475569;stroke-width:1.5}.lane{fill:#f8fafc;stroke:#cbd5e1;stroke-width:1}.pill{fill:#fff;stroke:#d8dee8;stroke-width:1}.pillText{font-size:12px;fill:#263445}</style></defs>
+  <rect width="1500" height="860" fill="#fff"/>
+  <g class="font">
+    <text class="title" x="48" y="56">Product Implementation Timeline To Release</text>
+    <text class="sub" x="48" y="80">Source-free 30-month implementation plan with staged releases, gates, and adoption waves.</text>
+    <line class="axis" x1="100" y1="426" x2="1396" y2="426"/>
+    <g>
+      <line class="tick" x1="132" y1="406" x2="132" y2="446"/><text class="year" x="106" y="388">Q1 Y1</text>
+      <line class="tick" x1="300" y1="406" x2="300" y2="446"/><text class="year" x="274" y="388">Q2 Y1</text>
+      <line class="tick" x1="468" y1="406" x2="468" y2="446"/><text class="year" x="442" y="388">Q3 Y1</text>
+      <line class="tick" x1="636" y1="406" x2="636" y2="446"/><text class="year" x="610" y="388">Q4 Y1</text>
+      <line class="tick" x1="804" y1="406" x2="804" y2="446"/><text class="year" x="778" y="388">Q1 Y2</text>
+      <line class="tick" x1="972" y1="406" x2="972" y2="446"/><text class="year" x="946" y="388">Q2 Y2</text>
+      <line class="tick" x1="1140" y1="406" x2="1140" y2="446"/><text class="year" x="1114" y="388">Q3 Y2</text>
+      <line class="tick" x1="1308" y1="406" x2="1308" y2="446"/><text class="year" x="1282" y="388">Q4 Y2</text>
+    </g>
+
+    <rect class="lane" x="84" y="120" width="1334" height="112" rx="14"/><text class="label" x="112" y="154">Strategy And Discovery</text>
+    <rect class="phase p1" x="150" y="164" width="244" height="52" rx="10"/><text class="phaseTitle" x="170" y="186">Vision + Business Case</text><text class="small" x="170" y="206">funding, KPIs, roadmap</text>
+    <rect class="phase p1" x="428" y="164" width="244" height="52" rx="10"/><text class="phaseTitle" x="448" y="186">Domain Discovery</text><text class="small" x="448" y="206">journeys, risks, data</text>
+
+    <rect class="lane" x="84" y="250" width="1334" height="112" rx="14"/><text class="label" x="112" y="284">Foundation And MVP</text>
+    <rect class="phase p2" x="318" y="294" width="300" height="52" rx="10"/><text class="phaseTitle" x="338" y="316">Platform Foundation</text><text class="small" x="338" y="336">architecture, CI/CD, security</text>
+    <rect class="phase p2" x="666" y="294" width="300" height="52" rx="10"/><text class="phaseTitle" x="686" y="316">MVP Build</text><text class="small" x="686" y="336">core journeys and integrations</text>
+
+    <rect class="lane" x="84" y="490" width="1334" height="112" rx="14"/><text class="label" x="112" y="524">Scale And Hardening</text>
+    <rect class="phase p3" x="646" y="534" width="284" height="52" rx="10"/><text class="phaseTitle" x="666" y="556">Pilot Release</text><text class="small" x="666" y="576">limited users, feedback loop</text>
+    <rect class="phase p3" x="982" y="534" width="284" height="52" rx="10"/><text class="phaseTitle" x="1002" y="556">Enterprise Hardening</text><text class="small" x="1002" y="576">performance, DR, compliance</text>
+
+    <rect class="lane" x="84" y="626" width="1334" height="126" rx="14"/><text class="label" x="112" y="660">Launch And Adoption</text>
+    <rect class="phase p4" x="1102" y="674" width="216" height="58" rx="10"/><text class="phaseTitle" x="1122" y="696">GA Release</text><text class="small" x="1122" y="716">go-live, support readiness</text>
+    <rect class="phase p5" x="1328" y="674" width="72" height="58" rx="10"/><text class="phaseTitle" x="1344" y="696">Scale</text><text class="small" x="1342" y="716">waves</text>
+
+    <polygon class="diamond" points="636,410 652,426 636,442 620,426"/><rect class="pill" x="574" y="448" width="124" height="38" rx="5"/><text class="pillText" x="582" y="464">Architecture</text><text class="pillText" x="582" y="480">gate</text>
+    <polygon class="diamond" points="972,410 988,426 972,442 956,426"/><rect class="pill" x="912" y="448" width="120" height="38" rx="5"/><text class="pillText" x="920" y="464">Pilot go/no-go</text><text class="pillText" x="920" y="480">decision</text>
+    <polygon class="diamond" points="1140,410 1156,426 1140,442 1124,426"/><rect class="pill" x="1078" y="448" width="124" height="38" rx="5"/><text class="pillText" x="1086" y="464">Release</text><text class="pillText" x="1086" y="480">readiness</text>
+    <polygon class="diamond" points="1308,410 1324,426 1308,442 1292,426"/><rect class="pill" x="1250" y="448" width="116" height="38" rx="5"/><text class="pillText" x="1258" y="464">GA sign-off</text><text class="pillText" x="1258" y="480">and launch</text>
+
+    <rect class="pill" x="520" y="774" width="458" height="42" rx="8"/><text class="pillText" x="536" y="792">Timeline assumes a 24 to 30 month product journey with phased delivery,</text><text class="pillText" x="536" y="808">progressive release gates, adoption waves, and post-launch scaling.</text>
+  </g>
+</svg>