@thebackstoryis/engineering-with-ai 0.2.9

package/Docs/examples/prototype-review-inputs.md

@@ -0,0 +1,175 @@
+# Complete prototype-review inputs
+
+These are the four **CLI input shapes** for a prototype plan and one design cycle. They aren't ready-made approval records. Use them with an existing UI delivery whose intent and design-system guidance you've reviewed.
+
+The host normally prepares these files through `ewai-prototype-iteration`; a person reviews the resulting plan and design. Direct CLI use is useful for repeatability and integrations.
+
+## Before copying the examples
+
+Use your delivery's actual slug instead of `customer-portal`. Replace every capitalised value below with the result from your project:
+
+| Value | Source |
+| --- | --- |
+| `INTENT_DIGEST` | The reviewed intent content used for this delivery. |
+| `DESIGN_SYSTEM_DIGEST` | The effective digest in this delivery's design-system application receipt. |
+| `PLAN_PREPARATION_DIGEST` | `preparation.preparationDigest` returned by plan preparation. |
+| `PLAN_REVIEW_DIGEST` | `review.contentDigest` returned by plan recording. |
+| `PROTOTYPE_MANIFEST_DIGEST` | The digest of the actual prototype manifest being reviewed. |
+| `CYCLE_PREPARATION_DIGEST` | `preparation.preparationDigest` returned by cycle preparation. |
+| `ACTIVE_PERSONA_ID` | A persona in the active ensemble for **that** preparation. Recheck it for the design cycle. |
+
+Keep the complete `sha256:` prefix on digests. These references tie the review to particular inputs; syntactically valid hashes alone don't prove a correct design or grant approval.
+
+The [versioned domain schema](../../config/prototype-iteration.schema.json) describes saved contracts. The CLI preparation requests below are intentionally smaller: EWAI adds the schema, slug and selected persona engagement. Don't paste a saved domain object into a CLI request that accepts different fields. [Review semantics](../../skills-src/ewai-prototype-iteration/references/review-contract.md) explains findings, assessments and evidence channels.
+
+## 1. plan-prepare.json
+
+<!-- example: prototype-plan -->
+```json
+{
+  "intentDigest": "INTENT_DIGEST",
+  "designSystem": {
+    "id": "ewai.design-system.default",
+    "effectiveDigest": "DESIGN_SYSTEM_DIGEST"
+  },
+  "plan": {
+    "summary": "Let a customer review the status of their request.",
+    "screens": [{
+      "id": "request-status",
+      "title": "Request status",
+      "purpose": "Explain the current state and next action.",
+      "userOutcomes": ["Understand whether a response is needed"],
+      "evidenceRefs": ["intent:request-status"]
+    }],
+    "journeys": [{
+      "id": "check-request",
+      "actor": "customer",
+      "outcome": "Find out whether to respond or wait.",
+      "screenRefs": ["request-status"]
+    }]
+  },
+  "signals": ["user journey", "usability", "recovery"],
+  "predecessorDigest": ""
+}
+```
+
+Use the actual selected pack ID when it isn't the bundled fallback. Replace the fictional intent reference with the accepted source supporting your screen.
+
+```bash
+ewai prototype-review plan-prepare customer-portal --input plan-prepare.json --project . --json
+```
+
+Read the returned active personas. Preparation hasn't reviewed or selected the design.
+
+## 2. plan-review.json
+
+After reviewing the plan, record each actual finding and one assessment per finding. This example incorporates a missing explanation:
+
+<!-- example: prototype-plan-review -->
+```json
+{
+  "schema": "ewai.prototype-plan-review-submission/v1",
+  "expectedPreparationDigest": "PLAN_PREPARATION_DIGEST",
+  "reviewedBy": "Example reviewer",
+  "findings": [{
+    "personaId": "ACTIVE_PERSONA_ID",
+    "concernCode": "next-action",
+    "severity": "advisory",
+    "observation": "The plan names a status but doesn't explain whether the customer needs to act.",
+    "recommendation": "Describe the next action and who is responsible.",
+    "evidenceRefs": ["screen:request-status"]
+  }],
+  "assessments": [{
+    "findingRef": {
+      "personaId": "ACTIVE_PERSONA_ID",
+      "concernCode": "next-action",
+      "evidenceRefs": ["screen:request-status"]
+    },
+    "disposition": "incorporate",
+    "rationale": "A status is useful only when the customer can tell what to do next."
+  }]
+}
+```
+
+`findingRef` lets the CLI derive the stable finding ID from persona, concern and references. Saved records use `findingId`.
+
+```bash
+ewai prototype-review plan-record customer-portal --input plan-review.json --project . --json
+```
+
+Keep the returned `review.contentDigest`. Incorporate the accepted feedback; don't call the plan approved merely because recording succeeded.
+
+## 3. cycle-prepare.json
+
+Produce the runnable prototype under `SPECS/6.Build/customer-portal/ui-design-assets/prototypes/`. Capture the source and rendered viewport evidence before design review. For example, `selected.html` and the evidence labelled `render:desktop` below must correspond to actual files/captures you've inspected.
+
+<!-- example: prototype-cycle -->
+```json
+{
+  "planReviewDigest": "PLAN_REVIEW_DIGEST",
+  "cycleNumber": 1,
+  "maxCycles": 2,
+  "predecessorDigest": "",
+  "prototype": {
+    "manifestDigest": "PROTOTYPE_MANIFEST_DIGEST",
+    "entryPath": "ui-design-assets/prototypes/selected.html"
+  },
+  "evidenceChannels": [
+    {"channel": "source", "status": "available", "evidenceRefs": ["prototype:selected.html"], "note": "Source inspected for this example design."},
+    {"channel": "rendered-viewport", "status": "available", "evidenceRefs": ["render:desktop"], "note": "Desktop capture inspected for this example design."},
+    {"channel": "interaction", "status": "not-collected", "evidenceRefs": [], "note": "Not exercised in this cycle."},
+    {"channel": "assistive-technology", "status": "not-collected", "evidenceRefs": [], "note": "Not exercised."},
+    {"channel": "user-research", "status": "not-collected", "evidenceRefs": [], "note": "No representative users involved."},
+    {"channel": "manual-qa", "status": "pending-human", "evidenceRefs": [], "note": "Separate human gate."},
+    {"channel": "release", "status": "not-collected", "evidenceRefs": [], "note": "No release decision."}
+  ],
+  "signals": ["visual hierarchy", "usability", "responsive"]
+}
+```
+
+**Don't copy the two available states unless you've collected that evidence.** Source and rendered-viewport evidence are prerequisites; if missing, collect them before proceeding. Other channels remain honestly absent.
+
+```bash
+ewai prototype-review cycle-prepare customer-portal --input cycle-prepare.json --project . --json
+```
+
+The active design personas can differ from the plan's. Use the current ensemble for the next review.
+
+## 4. cycle-review.json
+
+This fictional finding illustrates how to record a needed change, not an already-observed fault in your product:
+
+<!-- example: prototype-cycle-review -->
+```json
+{
+  "schema": "ewai.prototype-cycle-review-submission/v1",
+  "expectedPreparationDigest": "CYCLE_PREPARATION_DIGEST",
+  "reviewedBy": "Example reviewer",
+  "findings": [{
+    "personaId": "ACTIVE_PERSONA_ID",
+    "concernCode": "action-hierarchy",
+    "severity": "advisory",
+    "observation": "The next action is visually weaker than supporting information.",
+    "recommendation": "Give the next action a clearer position and emphasis.",
+    "evidenceRefs": ["render:desktop"]
+  }],
+  "assessments": [{
+    "findingRef": {
+      "personaId": "ACTIVE_PERSONA_ID",
+      "concernCode": "action-hierarchy",
+      "evidenceRefs": ["render:desktop"]
+    },
+    "disposition": "incorporate",
+    "rationale": "The main action needs to be easy to find before supporting detail."
+  }]
+}
+```
+
+```bash
+ewai prototype-review cycle-record customer-portal --input cycle-review.json --project . --json
+ewai prototype-review status customer-portal --project . --json
+```
+
+Expect `iterate` when incorporated feedback requires another cycle and capacity remains. The next cycle names the preceding cycle's content digest. At the limit, unresolved work needs a human decision; it doesn't become accepted automatically.
+
+Plan and cycle records are saved under the delivery's `ui-design-assets/prototype-iterations/`. Follow the [iteration guide](../persona-guided-prototype-iteration.md) to link the reviewed plan and final cycle in the v3 manifest. Human prototype selection, implemented-feature Manual QA and release remain separate.

package/Docs/examples/reproducible-archaeology-depth-example.md

@@ -0,0 +1,144 @@
+# Worked example: reproducible Archaeology and Discovery depth
+
+This example shows how two sessions can produce different explanatory wording
+while reaching the same material investigation boundary. The project, people,
+IDs, and digests are illustrative; they are not a claim about a real system.
+
+Use this alongside the
+[Reproducible Archaeology and Discovery Depth guide](../reproducible-archaeology-and-discovery-depth.md).
+
+## What you can reproduce
+
+This is a worked interpretation, not a bundled runnable Northstar application. Its IDs and digests won't resolve in your project. To try the workflow, initialise a disposable project with a small codebase, agree its purpose and processing permissions, refresh the Source Map, then follow the [prepare/review/compare guide](../reproducible-archaeology-and-discovery-depth.md). Use the IDs and templates actually returned.
+
+You can reproduce how stable evidence and gap identity are compared. Exact explanatory wording, persona availability and coverage depend on your inputs; this example doesn't guarantee matching output.
+
+## Scenario
+
+Northstar has inherited a small internal case-triage service. It has one web
+application, one API, an SQL database, and an overnight export to a reporting
+platform. The repository is available, but the operating model and data-handling
+decisions are incomplete.
+
+The named owner says the immediate outcome is to make a safe maintenance change,
+not to redesign the service. The team wants enough understanding to plan that
+change without turning Archaeology into an unbounded documentation exercise.
+
+## 1. Establish the evidence boundary
+
+The team refreshes the Source Map against revision `example-4f21a9` and records:
+
+| Evidence surface | Result |
+| --- | --- |
+| Regular files | 286 inventoried |
+| Analysed | 267 |
+| Inventory-only | 8 |
+| Analysis failed | 3 |
+| Sensitive | 2, retained as metadata-only evidence |
+| Oversized | 6, retained as explicit coverage limits |
+| Owner declarations | Service purpose, internal users, current hosting, recovery owner, and client-data classification |
+
+The eight inventory-only files and three analysis failures are not removed to
+make coverage appear healthier. They remain inputs to the depth recommendation.
+
+## 2. Review the depth profile
+
+EWAI recommends each dimension independently:
+
+| Dimension | Recommendation | Why | Named-owner selection |
+| --- | --- | --- | --- |
+| Architecture | `standard` | Component boundaries are visible, but the reporting integration has two competing implementations. | `standard` |
+| Data | `deep` | The service processes client identifiers and exports them across a system boundary. | `deep` |
+| Security | `deep` | Authorization is partly observed, while the reporting trust boundary is not confirmed. | `deep` |
+| Product | `bounded` | The requested maintenance outcome affects one existing internal journey. | `bounded` |
+| Delivery | `standard` | Unit tests exist, but release and rollback evidence is partial. | `standard` |
+| Governance | `deep` | Client-data policy applies and one retention decision has no named authority. | `deep` |
+| Operations | `standard` | Hosting is known, but recovery ownership and the overnight failure path need confirmation. | `standard` |
+
+This is more proportionate than selecting `deep` for the whole project. Repository
+size did not determine the result, and the number of proposed intents is not used
+as evidence of depth.
+
+## 3. Observe persona swapping
+
+The active ensemble changes with the concern:
+
+| Concern | Active perspectives | Reason shown to the reviewer |
+| --- | --- | --- |
+| Product journey | Archaeology lead, local Product Owner | Confirm the affected journey and resist inferring desired behaviour from code. |
+| Client-data export | Archaeology lead, local Data Owner, installed premium Privacy Specialist | Challenge classification, movement, retention, and evidence gaps. |
+| Reporting trust boundary | Archaeology lead, local Security Owner, installed premium Threat Modeller | Examine identity, authorization, exposure, and failure paths. |
+| Recovery | Archaeology lead, local Service Owner | Establish operational ownership and recovery evidence. |
+
+The premium specialists are used because they are already installed and relevant.
+Repeating the process without premium access still completes with the core and
+project personas plus the standard model. No persona can confirm an owner
+declaration or approve the selected depth.
+
+## 4. Record stable gaps
+
+The generated prose differs between two clean sessions:
+
+- session A says, “The export retention owner is not evidenced”;
+- session B says, “No accountable retention decision was found for reporting exports.”
+
+Both statements resolve to the same structured condition and therefore the same
+illustrative stable ID:
+
+| Stable gap | Structured meaning | Evidence references |
+| --- | --- | --- |
+| `GAP-GOV-8ab42c91d730` | Governance · retention owner missing · current state `unassigned` · intended state `named-owner` | Policy applicability and export configuration |
+| `GAP-SEC-27f061c35a9d` | Security · reporting trust boundary unresolved · current state `partial` · intended state `confirmed` | API client and owner declaration |
+| `GAP-OPS-d2e19b07c411` | Operations · overnight failure recovery untested · current state `unknown` · intended state `tested` | Scheduler configuration and runbook |
+
+The IDs above illustrate the real `GAP-<dimension>-<digest>` shape. A real ID is
+calculated by EWAI from the complete structured identity; do not invent or edit it.
+
+## 5. Keep grouping separate
+
+The first reviewer groups all three gaps under `safe-reporting-maintenance`. A
+second reviewer keeps the evidence and gaps unchanged but groups them by owner:
+
+- `data-governance` owns the retention gap;
+- `platform-security` owns the trust-boundary gap;
+- `service-operations` owns the recovery gap.
+
+That can produce three intents instead of one. The comparison reports a grouping
+change, not new discovery content. Stable gap identity is independent of how the
+organisation chooses to arrange the work.
+
+## 6. Compare two reviewed runs
+
+| Comparison layer | Run A versus run B | Interpretation |
+| --- | --- | --- |
+| Inputs | Same | Same project, revision, Source Map, packs, provider capability, and exclusions. |
+| Evidence | Same | Repository and bounded owner-evidence fingerprints agree. |
+| Personas | Same | The same named identities and tiers were engaged. |
+| Selected depth | Same | All seven named decisions agree. |
+| Coverage | Same | Failures and limited surfaces remain visible in both runs. |
+| Stable gaps | Same | The same three structured concerns were retained. |
+| Grouping | Different | The owner deliberately changed the work-organisation strategy. |
+| Unexplained variance | Empty | The only material difference has a recorded cause. |
+
+The two runs are reproducible despite different prose and grouping. They would
+not be reproducible if the security gap disappeared while all upstream evidence,
+coverage, personas, and depth remained unchanged.
+
+## 7. Decide whether the result is good enough
+
+The named owner still needs to assess content quality. They review the runs for:
+
+- missing material concerns;
+- duplicated or irrelevant questions;
+- evidence traceability;
+- proportionate depth;
+- useful next actions;
+- visibility of failures and contradictions.
+
+Only after that review may the owner approve Manual QA through the canonical EWAI
+operation. Reproducible structure is evidence of control, not proof that the
+investigation was complete or that the proposed change is safe to release.
+
+Use the
+[operator and Manual QA checklist](../quality/reproducible-archaeology-depth-review-checklist.md)
+to conduct and record that assessment.

package/Docs/examples/test-scenario-input.md

@@ -0,0 +1,68 @@
+# Record one reviewed test scenario
+
+Use this complete input shape after preparing scenarios for an existing intent. The fictional feature here is `customer-access`; it isn't a requirement your project inherits.
+
+## Prepare from accepted requirements
+
+Ask EWAI to challenge the intent's permissions and recovery paths, or run:
+
+```bash
+ewai test-scenarios prepare customer-access --focus "permission and recovery" --project . --json
+```
+
+Read `authoritativeSources`, `sourceDigest` and `activePersonas`. For this example, the accepted requirement is that an authenticated, authorised delegate can submit a valid access request and receive a clear outcome. If that isn't an accepted requirement in your project, don't record it as one.
+
+Save this as `scenario-input.json`. Substitute the returned digest, current persona ID and real source IDs. Set the slug, test file and owner for your project.
+
+<!-- example: test-scenario -->
+```json
+{
+  "schema": "ewai.persona-test-scenarios/v1",
+  "slug": "customer-access",
+  "focus": "permission and recovery",
+  "preparedSourceDigest": "SOURCE_DIGEST",
+  "scenarios": [{
+    "id": "PTS-001",
+    "title": "An authorised delegate can submit an access request",
+    "type": "happy-path",
+    "sourceRefs": ["JOURNEY_SOURCE_ID", "ACCEPTANCE_SOURCE_ID"],
+    "personaContributions": [{
+      "personaId": "ACTIVE_PERSONA_ID",
+      "concern": "Check the permission boundary as well as the successful outcome."
+    }],
+    "preconditions": ["The delegate is authenticated and authorised to request access."],
+    "actions": ["Submit a valid access request."],
+    "expectedResults": ["The request is accepted and a clear success outcome is displayed."],
+    "evidenceRoute": "automated",
+    "automation": "automated",
+    "plannedTest": {
+      "file": "tests/access.test.mjs",
+      "name": "authorised delegate completes access request"
+    },
+    "owner": "Delivery team",
+    "status": "accepted"
+  }],
+  "gaps": []
+}
+```
+
+The expected result is the test's **oracle**: the agreed behaviour against which the implementation will be checked. The persona suggests what to investigate; it can't invent that expectation.
+
+This one happy-path scenario isn't complete permission coverage. Consider denial and recovery separately, with their own accepted sources.
+
+## Review, record and inspect
+
+Only set `accepted` after the named reviewer has compared the expectation with its source. Then:
+
+```bash
+ewai test-scenarios record customer-access --input scenario-input.json --reviewed-by "Example reviewer" --project . --json
+ewai test-scenarios status customer-access --project . --json
+```
+
+The result should be `recorded`, with paired `test-scenarios.json` and `test-scenarios.md` under the intent's Build directory. Recording a scenario doesn't create its test file or run a test.
+
+Unknown source IDs, an unrecognised active persona or stale preparation require corrected input and review. Don't remove traceability fields merely to make validation pass.
+
+The [complete v1 candidate contract](../../skills-src/ewai-test-scenarios/references/scenario-contract.md#candidate-schema) lists all fields and enums. This contract is enforced by the [scenario validator](../../src/test-scenarios.mjs); there isn't a separate standalone JSON Schema file for it in this release.
+
+Return to [persona-driven test scenarios](../quality/persona-driven-test-scenarios.md).

package/Docs/examples/worked-examples.md

@@ -0,0 +1,147 @@
+# Worked examples
+
+These compact scenarios demonstrate how to apply EWAI proportionately. They're illustrative decision patterns, not specifications to copy unchanged or exhaustive phase checklists. A stage omitted from an example isn't waived; follow the current delivery's required gates.
+
+For a step-by-step exercise with observable results, try [your first session](../tutorials/first-session.md) and [first delivery](../tutorials/first-delivery.md).
+
+## 1. Start a new internal application
+
+**Situation:** An operations team needs a small case-triage tool.
+
+**Approach:**
+
+1. The Product Owner supplies the current process, users, desired response-time outcome, data classification, and non-goals.
+2. Guided Discovery engages product, operator, accessibility, and security perspectives as the sections change.
+3. If the organisation provides an applicable internal-application Blueprint, the team reviews it, accepts its required security and testing modules, and declines an irrelevant public-service module. Otherwise, Discovery continues without an Organisation Blueprint.
+4. Review shows the exact standards and project personas to be created.
+5. A named owner approves Discovery.
+6. The first intent delivers one journey: view and assign an untriaged case.
+7. Manual QA uses safe test records and checks keyboard access, permissions, exception handling, and operational visibility.
+
+**Key lesson:** Start with one useful journey and the evidence needed to operate it, not a generated backlog for the entire imagined product.
+
+## 2. Onboard a poorly documented legacy system
+
+**Situation:** A team inherits a service with sparse documentation and several years of history.
+
+**Approach:**
+
+1. The owner describes why the service exists, its users, known failures, and what must not be inferred from current code.
+2. After briefing and source permissions are agreed, the owner accepts the offer of Archaeology. It maps repositories, entry points, integrations, data, tests, and deployment.
+3. The inferred purpose conflicts with one current batch process. The discrepancy is presented before deep analysis.
+4. The owner confirms that the batch is a temporary workaround, not intended behaviour.
+5. Operations and data personas join the relevant deep passes; their output remains hypothesis until supported.
+6. Reviewed findings become canonical SPECS, while the workaround becomes a bounded migration intent.
+
+**Key lesson:** Repository behaviour is strong evidence of what exists, not automatic authority for what should continue.
+
+## 3. Deliver a user-visible feature
+
+**Situation:** Users need to export a filtered report.
+
+**Approach:**
+
+1. Intent records the user outcome, supported filters, data permissions, accessibility, performance expectation, and export retention.
+2. The repository index identifies the query, permission, UI, and audit-log blast radius.
+3. The plan creates one vertical slice through UI, service, authorization, export generation, and evidence.
+4. Build approval names that scope.
+5. Automated tests cover permissions, filters, empty results, volume, and formula-safe output.
+6. Standards review checks data handling and existing patterns.
+7. Manual QA exercises an authorised and unauthorised user, keyboard flow, a large report, and the downloaded result.
+
+**Key lesson:** User-visible acceptance and data-boundary testing belong in the same slice as implementation.
+
+## 4. Make a low-risk technical-debt change
+
+**Situation:** A duplicated parser should be consolidated without changing behaviour.
+
+**Approach:**
+
+1. The intent states the maintainability outcome and an explicit no-user-visible-change constraint.
+2. Index and tests identify callers and observable contracts.
+3. Reconcile confirms both copies currently behave the same—or records the differences.
+4. The plan uses characterization tests as the first failing or safety evidence.
+5. Build changes the smallest shared boundary.
+6. Manual QA is proportionate: a focused maintainer walkthrough plus one representative user journey.
+
+**Key lesson:** Low risk can reduce ceremony, but it does not justify inventing equivalence or skipping impact evidence.
+
+## 5. Apply a mandatory organisation Blueprint
+
+**Situation:** A regulated project must use the organisation's reviewed baseline.
+
+**Approach:**
+
+1. Guided Setup shows publisher, version, compatibility, required modules, dependencies, digest, and destinations.
+2. Required modules cannot be deselected. Optional modules are chosen from actual project applicability.
+3. A compliance persona surfaces questions, but a qualified owner confirms applicable obligations.
+4. Existing destination conflicts stop application.
+5. The team reconciles the existing standard rather than deleting it.
+6. Named approval materialises organisation standards, project personas, receipt, and pipeline pin.
+
+**Key lesson:** Mandatory organisational input still requires visible project consequences and accountable adoption.
+
+## 6. Use project and premium personas together
+
+**Situation:** A payments project has a local settlement-operations persona and access to managed specialist personas.
+
+**Approach:**
+
+1. Check-in reports entitlement and that the premium library is installed; no download occurs.
+2. In user-outcome sections, a product lens leads.
+3. In data and assurance sections, the relevant project payments persona and a matching premium specialist are deliberately considered.
+4. The UI displays both names, tiers, concerns, and engagement reasons.
+5. The project persona points to existing local operating evidence; it doesn't invent new facts. The premium persona challenges specialist gaps.
+6. A real payments owner resolves the decision.
+
+**Key lesson:** Mixed tiers improve perspective coverage, but relevance, evidence, and human authority remain separate.
+
+## 7. Deliver a security-sensitive capability
+
+**Situation:** A public feature processes sensitive personal data.
+
+**Approach:**
+
+1. Discovery records classification, purpose, access model, retention, jurisdictions, threat context, and operational ownership.
+2. Candidate compliance findings remain triage until qualified owners confirm them.
+3. Security and privacy standards become explicit Build constraints.
+4. Plan includes abuse cases, authorization boundaries, logging restrictions, dependency risk, incident visibility, and deletion behaviour.
+5. An independent security review is used when configured; if unavailable, the gap is recorded rather than marked passed.
+6. Manual QA uses non-production test data and verifies denial, recovery, and audit behaviour as well as the happy path.
+
+**Key lesson:** More AI review does not replace data governance, qualified interpretation, or operational readiness.
+
+## 8. Roll a Blueprint update across projects
+
+**Situation:** An organisation publishes a new major Blueprint version with a changed mandatory API standard.
+
+**Approach:**
+
+1. The publisher releases an immutable version with compatibility, affected modules, migration guidance, and deprecation dates.
+2. Catalogue owners identify projects pinned to the earlier version.
+3. Each project compares its receipt and materialised standards with the candidate release.
+4. One project adopts immediately, one records a time-bound exception, and one remains unaffected because the module does not apply.
+5. Each decision is approved and evidenced locally.
+6. The old source remains available long enough to interpret historical receipts.
+
+**Key lesson:** A shared release creates review work; it does not create permission to overwrite every consuming project.
+
+## Adapt an example safely
+
+For your own project, replace:
+
+- users and outcomes with direct evidence;
+- risk and data classifications with confirmed context;
+- personas with the installed relevant catalogue;
+- Blueprint and module choices with reviewed local packages;
+- tests and Manual QA with observable acceptance criteria;
+- approvers with people who have real authority.
+
+Retain the boundaries: personas advise, SPECS holds durable truth, reusable inputs require review, Build requires explicit scope approval, and Manual QA remains human.
+
+## Related guides
+
+- [All EWAI guides](../README.md)
+- [Product Owner guide](../product-owner-guide.md)
+- [Developer delivery guide](../developer-delivery-guide.md)
+- [Organisation rollout](../organisation-rollout-guide.md)