@thebackstoryis/engineering-with-ai 0.2.9

package/skills-src/ewai-context/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: ewai-context
+description: Prepare minimum-sufficient, fidelity-checked context for EWAI companion, intent, plan, build-task, fresh-context-review, phase-contribution-review, and design-system application work; inspect active persona lenses and exact deltas; and run the committed engineering-performance benchmark. Use when a host needs bounded project evidence without weakening standards, tests, security, privacy, or human authority.
+---
+
+# EWAI Governed Context
+
+Use the project-local context assembler. Do not improvise a smaller prompt by dropping evidence manually.
+
+## Choose one governed profile
+
+Use exactly one of the seven governed profiles for the current moment:
+
+- `companion` for current state, route and recovery;
+- `intent` for outcomes, users, constraints and acceptance;
+- `plan` for architecture, standards, repository truth and tests;
+- `build-task` for one exact leased task and its permitted write set;
+- `fresh-context-review` for tests-first independent review of one task diff;
+- `phase-contribution-review` for attributed evidence and disagreement in one phase thread.
+- `design-system-apply` for resolved, scope-relevant UI Design and Prototype guidance.
+
+Run:
+
+```bash
+ewai context prepare <profile> --slug <intent-slug> --focus "<current concern>" --project . --json
+```
+
+For `build-task` and `fresh-context-review`, also pass `--task <task-id>`. Design-system application is prepared through `ewai design-system apply <delivery-slug>` and `$ewai-design-system-apply`, which supply validated pack candidates to the same assembler. Use `--previous <digest>` only when it is the exact predecessor manifest.
+
+## Preserve fidelity before reducing demand
+
+Require `status: ready`, `fidelity.status: pass`, and 100% mandatory recall before giving a context payload to a model. Mandatory evidence includes the applicable task boundary, standards, tests, security and privacy constraints, contradictions, and human authority relevant to that profile.
+
+If the result is `non-ready` with `mandatory-overflow`, stop. Do not truncate, summarise away, or bypass mandatory evidence. Narrow the focus, increase the bounded budget, or split the operation, then prepare again.
+
+Treat the cache as disposable acceleration. Project truth remains in canonical SPECS and repository files. Use exact content and policy digests for reuse; never infer freshness from a familiar filename or a partial digest.
+
+## Engage and show the current persona ensemble
+
+Before semantic work, show every active persona's name, tier, matched signals, and engagement reason. The standard host model plus installed core and project personas form the baseline. Personal and installed premium personas may replace or enrich a lens when they are relevant. When the profile or focus changes, prepare again and swap the ensemble; do not accumulate stale personas.
+
+Use premium personas only when they are already installed and reported by the project. Do not fetch, imitate, or expose missing or raw persona definitions during context preparation.
+
+Personas are advisory lenses. They are not user evidence, specialist validation, acceptance, risk ownership, or approval.
+
+## Keep host boundaries intact
+
+- Trusted CLI and MCP hosts may receive transient `modelContext` and `deltaContext` for the immediate operation.
+- The loopback dashboard receives only a body-free safe manifest.
+- Never accept a browser-supplied project root, file path, provider command, executable, or credential.
+- Keep estimated input usage clearly separate from optional provider-reported usage.
+- Context preparation cannot approve Build or Manual QA, certify quality, accept security risk, deploy, or release.
+
+## Verify engineering performance
+
+Run the committed equal-input benchmark after changing selection, rendering, persona routing, provider adapters, cache behaviour, or profiles:
+
+```bash
+ewai context benchmark --json
+```
+
+The result must cover all seven profiles, retain 100% mandatory recall for each, achieve at least 40% median estimated input-demand reduction, prepare within 75 ms median local time, and add no more than 32 MiB peak RSS on the committed fixture corpus. A failed benchmark blocks the change; never relax a fidelity threshold to recover a performance number.
+
+Run the focused context tests and the full repository suite as well. A local benchmark is regression evidence for the measured environment, not proof of provider quality or universal latency.
+
+## Stop conditions
+
+Stop and escalate when mandatory evidence cannot fit, the predecessor digest is unavailable or mismatched, a source is outside the configured project, a task is outside its write set, a safe projection would expose source bodies, persona content is unavailable, the benchmark fails, or anyone asks context preparation to grant delivery authority.

package/skills-src/ewai-context/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "EWAI Governed Context"
+  short_description: "Prepare minimum-sufficient context without weakening engineering fidelity"
+  default_prompt: "Use $ewai-context to prepare and inspect the governed context for this EWAI operation."

package/skills-src/ewai-context-import/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: ewai-context-import
+description: Register and interpret a user-supplied folder of emails, meeting transcripts, documents, research, requirements, presentations, spreadsheets, images, recordings, and other project material as evidence-backed EWAI context. Use during new-project setup, before or during Archaeology, when importing discovery material, when reconstructing decisions and rationale, or when project actors and suitable analysis personas need to be identified from source evidence.
+---
+
+# EWAI Context Import
+
+Enrich project understanding without turning raw correspondence into unreviewed project truth. Keep supplied material in place, preserve provenance, and route only reviewed knowledge into SPECS.
+
+## Offer context enrichment naturally
+
+During setup, after the initial human project briefing and before detailed discovery or Archaeology, ask:
+
+> Do you have a folder of emails, meeting transcripts, documents, research, requirements, or other project material you would like EWAI to learn from?
+
+Make the import optional. Do not imply that a project is incomplete without one. Existing projects may add or refresh context sources at any time.
+
+## Establish permission and boundaries
+
+Ask one focused question at a time and establish:
+
+1. the folder path and a human-readable label;
+2. whether the user is authorised to let EWAI read it;
+3. exclusions such as private correspondence, HR, legal privilege, credentials, unrelated clients, or personal material;
+4. classification: `public`, `internal`, `confidential`, or `restricted`;
+5. whether content may be processed by the current AI provider: `allowed`, `denied`, or `unknown`;
+6. whether OCR or transcription may be used when required.
+
+If cloud processing is denied or unknown, do not open source content in a hosted AI session. A local inventory may still be registered, but explain the limitation and ask the user to select an approved local-processing route. Never weaken the classification to make the import convenient.
+
+After explicit consent, register the folder with the internal control-plane command:
+
+```bash
+ewai context register <folder> --project <path> --label <label> --classification <classification> --cloud-processing <policy> --yes --json
+```
+
+Add `--exclude <relative-path>` for each approved exclusion. Keep the command and JSON internal unless registration fails. Registration inventories supported material without copying raw content into SPECS. Absolute paths and filenames remain in the gitignored `.ewai-pipeline/` manifest; the committed registry contains sanitized counts, types, policy, and an inventory fingerprint. This fingerprint detects inventory drift; it is not represented as a hash of every file's content.
+
+## Perform bounded reconnaissance
+
+Read [the context import contract](references/context-import-contract.md) before opening content.
+
+Start with filenames, dates, formats, headings, participants, thread structure, and a small representative sample. Report what kinds of context appear to exist and ask before expanding into unexpectedly sensitive or out-of-scope material. Do not execute attachments, macros, links, scripts, or embedded active content.
+
+Work in bounded batches. Keep progress human:
+
+- `Reviewing the material you supplied…`
+- `I found three decision-heavy meeting threads and two requirement documents.`
+- `I found four recurring project roles · two need your clarification.`
+- `There are conflicting accounts of the delivery approach.`
+
+## Route personas before deep interpretation
+
+After initial reconnaissance, run `ewai persona index --project <path> --json`. Use its compact metadata—identifier, description, category, tier, tags, and capabilities—to compare the perspectives required by the material with the core, premium, personal, and project personas actually available.
+
+Prepare a small ensemble rather than loading every persona:
+
+- one lead suited to the dominant question;
+- domain or functional perspectives evidenced by the material;
+- user or operator perspectives;
+- assurance, security, accessibility, data, or adversarial reviewers where relevant;
+- the SPECS Knowledge Curator for final routing.
+
+Tell the user:
+
+- which available personas would materially improve the import and why;
+- which will lead or review each pass;
+- where the current library has a meaningful perspective gap;
+- whether a project-specific persona should be created from evidenced actors.
+
+Switch persona lenses between bounded passes as the evidence changes. Do not blend every persona into one generic answer. Record routing in `persona-routing.yaml`, including the persona, purpose, evidence that made it relevant, pass, contribution, and unresolved gap.
+
+An installed advisory persona is a reasoning aid, not evidence about this project's users. When source material reveals a real role, actor, environment, responsibility, frustration, goal, or decision authority, propose a project persona under the import bundle's `proposals/SPECS/1.Scope/personas/project/`. Attribute it to evidence, avoid unnecessary personal identifiers, distinguish role from individual, and obtain human approval before promotion.
+
+## Extract evidence, not just summaries
+
+Classify each candidate finding as:
+
+- `stated`: a source says it, without evidence of agreement;
+- `proposed`: someone suggested an option or action;
+- `agreed`: participants explicitly reached agreement;
+- `decided`: an accountable decision and outcome are recorded;
+- `implemented`: repository or operational evidence shows the outcome exists;
+- `superseded`: later evidence replaced it;
+- `contradicted`: credible sources disagree;
+- `inferred`: interpretation still requires confirmation;
+- `unknown`: evidence is insufficient.
+
+Extract project language, actors, intents, journeys, workflows, requirements, constraints, options, decisions, rationale, risks, incidents, dependencies, actions, unresolved questions, and success measures. Cite a source identifier plus page, paragraph, timestamp, message, slide, sheet, or other stable locator for every material claim.
+
+## Create the review bundle
+
+Build on the registration bundle at `SPECS/3.Evidence/context-imports/<date>-<slug>/`:
+
+```text
+├── source-registration.yaml
+├── report.md
+├── evidence-ledger.yaml
+├── persona-routing.yaml
+├── actors-and-persona-candidates.md
+├── decisions-and-options.md
+├── open-questions.md
+└── proposals/SPECS/
+```
+
+Mirror proposed records into their eventual SPECS destination. Keep raw source content outside SPECS. Use short necessary excerpts only when permitted; prefer paraphrase plus a precise locator.
+
+## Review and curate
+
+Present related findings in small groups. Ask the accountable human to accept, correct, reject, or defer them. Use the SPECS Knowledge Curator to promote accepted records, preserve links back to the context-import evidence, and reconcile conflicts with existing project knowledge.
+
+Do not claim that a discussion was a decision, that a participant represented all users, or that a repeated practice was an approved standard. Do not create a persona from protected characteristics or private correspondence without an appropriate and explicit purpose.
+
+## Completion boundary
+
+Complete the import only when registered sources and exclusions are visible, processing policy was honoured, material findings are traceable, persona routing and gaps are recorded, project-actor candidates are reviewed, contradictions remain visible, and accepted knowledge has been curated into SPECS.
+
+Stop before implementation. Create or enrich an intent for work discovered by the import.

package/skills-src/ewai-context-import/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "EWAI Context Import"
+  short_description: "Enrich projects from supplied source material"
+  default_prompt: "Use $ewai-context-import to register and interpret a folder of project materials as evidence-backed SPECS context."

package/skills-src/ewai-context-import/references/context-import-contract.md

@@ -0,0 +1,106 @@
+# EWAI context import contract
+
+Use this contract when registering, interpreting, citing, and promoting user-supplied project material.
+
+## Source boundary
+
+- Treat the supplied folder as read-only.
+- Keep absolute paths, filenames, and the detailed inventory in `.ewai-pipeline/context/sources/`.
+- Keep raw documents, messages, attachments, recordings, and extracted full text outside committed SPECS.
+- Put sanitized source metadata and reviewed derived knowledge in SPECS.
+- Do not follow symbolic links or traverse into a project contained by the supplied folder.
+- Do not execute files, macros, scripts, links, installers, or embedded active content.
+
+Registration recognises common text, Markdown, email, calendar, PDF, office-document, presentation, spreadsheet, structured-data, image, audio, and video extensions. Recognition means inventory eligibility, not guaranteed extraction. Record unsupported, encrypted, corrupt, inaccessible, or tool-dependent material as a visible limitation.
+
+## Processing policy
+
+| Policy | Hosted AI may open content? | Permitted action |
+|---|---:|---|
+| `allowed` | Yes, within approved scope | Register, inspect, interpret, and cite |
+| `denied` | No | Register local metadata only; require approved local processing for content |
+| `unknown` | No | Clarify policy before content access |
+
+OCR, transcription, email parsing, archive expansion, or conversion can disclose more content than filenames suggest. Ask before using them. Do not upload source material to a third-party conversion service without separate explicit approval.
+
+## Evidence locator
+
+Use the most stable locator available:
+
+```yaml
+- id: CTX-001
+  claim: Operational alerts require an acknowledgement path.
+  state: agreed
+  confidence: high
+  sources:
+    - source_id: context.early-material.abc123
+      document: SRC-007
+      locator: "meeting 2025-04-12, 00:18:42-00:20:10"
+      speaker_role: Operations lead
+  contradictions: []
+  review_owner: Product owner
+  review_status: pending
+```
+
+Use source-local aliases such as `SRC-007` when filenames are sensitive. Keep the alias-to-path mapping only in the private manifest or another gitignored index.
+
+## Decision semantics
+
+| State | Minimum evidence |
+|---|---|
+| `stated` | A source contains the claim |
+| `proposed` | A participant or document presents an option |
+| `agreed` | Explicit agreement is recorded, but accountable authority may still be unclear |
+| `decided` | The decision, accountable authority, and selected outcome are evidenced |
+| `implemented` | Live repository or operational evidence corroborates the outcome |
+| `superseded` | Later evidence explicitly replaces the earlier position |
+| `contradicted` | Credible sources support incompatible accounts |
+| `inferred` | Interpretation joins evidence not explicit in a source |
+| `unknown` | Available evidence cannot support a stronger state |
+
+An action item is not necessarily a decision. Silence is not agreement. Meeting attendance is not approval. A later implementation can corroborate the outcome but may not prove the original rationale.
+
+## Persona routing record
+
+Record the selected analysis ensemble:
+
+```yaml
+schema: ewai.context-persona-routing/v1
+passes:
+  - id: decisions
+    question: Which architectural choices and trade-offs are evidenced?
+    lead: premium.architecture-decision-mentor
+    reviewers: [ewai.core.archaeologist]
+    selection_evidence: [CTX-004, CTX-009]
+    contribution: pending
+    gaps: []
+project_persona_candidates:
+  - id: incident-commander
+    evidence: [CTX-012, CTX-018]
+    status: proposed
+```
+
+Use the installed persona index for selection. Metadata may be used to choose a persona; do not copy premium persona content into project records. Record a missing perspective rather than inventing an unavailable persona's expertise.
+
+## Project actor and persona rules
+
+- Prefer a role or context archetype over a named individual.
+- Separate observed responsibilities from inferred goals or personality.
+- Attribute frustrations, needs, and workarounds to source evidence.
+- Represent conflicting experiences rather than averaging them away.
+- Treat project personas as hypotheses until real stakeholders review them.
+- Keep protected characteristics out unless they are relevant, lawful, necessary, and appropriately governed.
+- Promote accepted candidates to `SPECS/1.Scope/personas/project/` and update the project persona registry.
+
+## Promotion destinations
+
+| Finding | Proposed destination |
+|---|---|
+| Actor, term, boundary, interface, research summary | `SPECS/1.Scope/` |
+| Intent, journey, workflow, requirement, discussion | `SPECS/2.Purpose/` |
+| Source evidence, risk, incident, contradiction | `SPECS/3.Evidence/` |
+| Confirmed non-negotiable rule | `SPECS/4.Constraints/` |
+| ADR, option, architecture, pattern, SOP, runbook | `SPECS/5.Strategy/` |
+| Historical or active delivery evidence | `SPECS/6.Build/` |
+
+Require human review before promotion. Require a qualified owner for legal, regulatory, security, privacy, accessibility, employment, or other specialist claims.

package/skills-src/ewai-dashboard-configuration/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: ewai-dashboard-configuration
+description: Inspect and change a project's optional EWAI dashboard views and sidebar preference through the shared validated configuration contract. Use when a user wants a simpler dashboard or needs specialist views.
+---
+
+# Configure your dashboard
+
+Start with `ewai dashboard preferences --project PROJECT --json`. Explain only the options relevant to the user's work, using the returned titles and descriptions. All nine specialist views are off unless selected; the core work views and Configuration remain available.
+
+Ask which changes they want when their request is unclear. Reading settings requires no save consent. For agreed changes use:
+
+`ewai dashboard configure --enable VIEW --disable OTHER_VIEW --expected-digest DIGEST --yes --project PROJECT --json`
+
+Repeat `--enable` or `--disable` for multiple views. Use `--collapse` or `--expand` for the sidebar. Omit options not being changed. Use the digest from the inspected settings; never invent one or silently retry a stale save. If the configuration changed, read it again, explain the difference and reconfirm the intended changes.
+
+Confirm what was saved and that the dashboard will pick it up on refresh. Do not edit YAML directly, change global settings or install anything. View preferences do not disable required standards, checks, policies, approvals, hooks or licence checks. Enabling a view does not authorise running scanners, syncing a team service, applying a starter or downloading personas.
+
+Premium learning and setup disappear from routine navigation only when access is available and the installed pack is verified. Licence management and recovery remain in Configuration. Use the existing private licence form if requested; never collect a licence key in chat.
+
+For a failed read or save, show the safe error and the relevant next step. Do not overwrite malformed configuration, break a lock, broaden the project path or suppress an assurance failure to make the dashboard look simpler.

package/skills-src/ewai-deliver/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: ewai-deliver
+description: Deliver or resume an EWAI intent through the complete fourteen-stage Engineering With AI harness. Use whenever a user chooses work, asks to continue an intent, requests planning or implementation, resumes shelf-ready work, or asks to move a feature forward. Enforces durable Markdown, JSON and SQLite state, deterministic phase gates, FitCheck, Build approval, Manual QA, and Retro.
+---
+
+# EWAI Deliver
+
+This skill is the only supported route from an EWAI intent into planning, Build, delivery, and learning. A host AI's generic planning mode is not an EWAI Plan and cannot replace a pipeline phase.
+
+Resolve the workspace and SPECS root from `.ewai-pipeline/project.json`; all logical `SPECS/...` paths in this contract are relative to that configured root. Never assume the workspace itself or the repository being changed owns SPECS.
+
+## Delivery contract
+
+Before taking delivery action, read [Phase routing](references/phase-routing.md) and [Delivery evidence contracts](references/delivery-evidence.md) completely. They define the purpose, required evidence, and exit condition of every EWAI phase. The project-local contracts returned by `ewai_delivery_required_artefacts` and `ewai_delivery_gate_template` are the executable truth for the current run.
+
+Preserve all fourteen stages, the UI Design and FitCheck adjuncts, shelf/resume semantics, recovery, escalation, branch safety, evidence, Manual QA, and Retro. Never shorten the harness merely to finish within one agent turn. Persist the recovery point and continue in another turn when necessary.
+
+## Start and resume
+
+For new delivery, call `ewai_delivery_begin` (or `ewai delivery begin`) for an existing project-owned intent and identify the current host as `tool`/`--tool` (`claude`, `codex`, or `antigravity`). Antigravity is invoked through the `agy` CLI. That value defines the orchestrator exclusion boundary. For continuing work, call `ewai_delivery_continue` first. Never reconstruct the next phase from chat memory.
+
+Before substantial repository navigation or truth claims, call `ewai_index_status`; refresh with `ewai_index_refresh` when the index is missing or stale. Use `ewai_index_search` and `ewai_index_graph` for navigation and blast-radius evidence, then verify material claims against source files.
+
+Before phase work, require agreement among:
+
+- intent Markdown frontmatter;
+- the adjacent structured intent JSON record;
+- `SPECS/6.Build/<slug>/delivery-state.json`;
+- the SQLite operational projection.
+
+If they disagree, stop and reconcile from durable evidence. Do not silently pick a winner.
+
+Read the work item through `ewai_read_work_item` before choosing an action. Treat `item.execution.actions` as the shared decision surface used by the dashboard and MCP:
+
+- invoke only actions whose `permitted` value is true;
+- explain structured blockers when an action is false;
+- never infer permission from `item.lane`, intent `status`, or a phase label alone;
+- allow a draft intent to begin the harness when `beginHarness` is permitted; readiness is established inside Intent;
+- honour dependencies at their recorded `required_before` and `required_state`.
+
+At each phase entry, read its required artefacts and gate template. Produce every individual artefact at its specified project-local path. A summary document or passing-looking ledger cannot substitute for missing records.
+
+When the project policy baseline is enabled, use `$ewai-organisation-policy` at Intent and Plan to verify current confirmed design facts, the deterministic evaluation, required named reviews or bounded exceptions, and every control trace. Treat `not-configured` as non-blocking. Policy evidence never grants Build, Manual QA, certification, deployment, release, production-enforcement, or residual-risk authority.
+
+If Intent, Reconcile, Plan, Test Plan, or Pattern Validation exposes a consequential unresolved architecture choice, pause at that exact phase and use `$ewai-architecture` for the smallest useful boundary. Resume only after its relevant proposals are accepted and promoted, or the question is explicitly owned and deferred without violating the current gate. Do not let generic host planning invent architecture, and never postpone a material architecture decision until Build.
+
+## Validation routing and cycles
+
+Read the resolved `validation` snapshot in `SPECS/6.Build/<slug>/delivery-state.json`; do not infer reviewers from whichever CLIs happen to be installed.
+
+For external Plan, Test Plan, and Code validation:
+
+1. Use only providers listed on that phase under `validation.providers`.
+2. Never use the recorded orchestrator as its own independent validator.
+3. Give each validator the configured `breadth`, `depth`, and `output` boundary.
+4. Run no more than `maxCycles` review-and-fix cycles per provider.
+5. Save every response and resulting fix evidence under the phase directory.
+6. Record each cycle through `ewai_delivery_record_validation_cycle` or `ewai delivery validation-cycle`.
+7. Complete only when every selected provider's latest cycle passes. If findings remain at the cycle limit, report the block.
+
+An external phase marked `not-supported` honestly records that no independent reviewer was selected. It never weakens Standards Sweep: use `$ewai-standards-check`, produce `standards-sweep.md`, and confirm accepted SPECS standards regardless of provider availability. Standards compliance cannot be disabled or waived.
+
+## Phase boundaries
+
+Use guarded operations only:
+
+- `ewai_delivery_start_phase`
+- `ewai_delivery_record_gate`
+- `ewai_delivery_record_validation_cycle`
+- `ewai_delivery_complete_phase`
+- `ewai_delivery_approve_build`
+- `ewai_delivery_approve_manual_qa`
+
+Never mutate a raw phase or status. A phase completes only with its passing EWAI gate ledger and fresh, hashed project evidence. Record meaningful progress events for the dashboard.
+
+Plan must produce `build-plan.md`, `destination.md`, the Claim Ledger, Plan Contract, and complete `task-graph.json`. The deterministic task-graph validator checks source records, claim and slice coverage, dependencies, cycles, write-set isolation, branch uniqueness, task contracts, waves, evidence paths, and review/merge ownership. Do not author its passing output manually.
+
+## Persona-led test scenario integration
+
+During Test Plan, use `$ewai-test-scenarios` when personas can materially expand coverage of user journeys, permissions, accessibility, security or privacy, operations, recovery, misuse, adversarial behaviour, or other role-specific concerns. Preparation must show the active persona ensemble and keep authoritative sources, persona hypotheses, and human decisions distinct. Scenario evidence is conditional and additive: do not make `test-scenarios.json` or `test-scenarios.md` a retroactive phase requirement for historical or unrelated deliveries.
+
+During Build, use `$ewai-test-scenarios` when an accepted automated or hybrid scenario applies to the leased task. Build the failing test first, preserve the accepted scenario oracle, and retain traceability from scenario ID to test result. Manual QA, specialist assurance, and representative-user validation remain named human evidence routes and cannot be completed through persona simulation.
+
+For user-interface work, use `$ewai-design-system-apply` during UI Design, then `$ewai-prototype-iteration` to review the plan and produced design with independently selected relevant personas before selecting the runnable prototype. New deliveries must link the immutable application receipt, reviewed plan, and final design cycle through `ewai.prototype-manifest/v3`; historical v1/v2 manifests remain readable but cannot complete a newly stamped v3 UI Design contract. UI Design must include a selected runnable prototype and its project-local prototype manifest. Build cannot use a narrative design document, an unlinked design-system prompt, persona advice, or an unassessed persona finding as a substitute for a prototype decision.
+
+Build approval must be an explicit human decision in the current conversation and a durable approval record. Until then, stop before branch creation or code writing. Manual QA must likewise be explicitly approved before Retro.
+
+## Build task ownership and evidence
+
+After Build is approved and entered, read `item.execution.tasks`. Only a task listed under `item.execution.actions.acquireTask.candidates` may start.
+
+For every task agent:
+
+1. Acquire `ewai_acquire_execution_lease` with the exact task ID, stable owner ID, current tool, and run ID.
+2. Keep the private lease token within that worker context; never write it to SPECS, reports, chat, or source control.
+3. Work only inside the declared write set and task branch/worktree. The orchestrator remains the only writer for central delivery files, gate ledgers, and merges.
+4. Renew the lease at material checkpoints before expiry; do not publish empty heartbeat events.
+5. Follow the task's explicit red, green, and refactor contract.
+6. In interactive delivery, write both `tasks/<id>/report.md` and the task's `evidence_path` JSON. In AFK delivery, the worker changes only its repository write set and the conductor writes both records centrally from captured execution facts. The JSON must cite captured command outputs and hashes, changed files, declared and actual branch/commit, repository, review evidence, and every planned completion check.
+7. Release with the truthful outcome. EWAI will not accept `completed` from narrative alone; structured evidence must validate first.
+
+Execution leases are disposable coordination state. The task graph, report, structured evidence, delivery state, and gate evidence are the durable project record. Never use “claim” to mean task ownership; the Claim Ledger records implementation truth.
+
+Start the intent-level active session with a stable `ownerId`. A different orchestrator cannot silently replace it; finish or explicitly hand off first.
+
+## Unattended Build conductor
+
+When the user explicitly asks EWAI to continue approved Build work while they are away, use the AFK conductor instead of inventing a host-specific background loop:
+
+1. Call `ewai_afk_preflight` and explain every blocker. Never weaken the task graph to make preflight pass.
+2. Confirm the user has already approved Build and understands the bounded scope, provider choice, maximum parallel tasks, and timeout.
+3. Call `ewai_afk_start`. Report the durable run ID and how to pause, resume, cancel, and inspect it; do not expose lease tokens or raw prompts.
+4. Use `ewai_afk_status` for updates. Translate semantic run/task states into human language rather than streaming model internals.
+5. A blocked run requires attention; diagnose its preserved log/evidence before `ewai_afk_resume`. Never silently retry a stop condition, failed review, scope breach, merge conflict, or post-merge failure.
+
+The conductor is a local Build executor, not a replacement for the fourteen-stage harness. It detects simple and multi-repository topology from the configured `pipeline.yaml`; every task's `repo` must match a configured repository, and exactly one configured repository must contain the configured SPECS root to own durable evidence. The workspace root need not be a Git repository. It creates a missing integration branch from each selected repository's clean current branch, then creates a real task branch/worktree there, leases only ready AFK tasks, limits concurrency to the validated graph, requires a fresh-context review, merges into that repository's declared parent branch in graph order, and runs post-merge checks. It blocks detached heads and refuses to silently switch when the declared integration branch already exists elsewhere. Use `task-graph.json.repository_branches` when repositories have different parent branches. Completion means all eligible Build tasks were integrated; it does not complete the Build phase, Standards Sweep, Test Execute, external validation, Delivery, Manual QA, or Retro.
+
+## Human interaction
+
+Translate control-plane work into warm, semantic progress such as “Validating the plan against project standards” or “Checking what changed since this work was shelved.” Do not make the user learn the command surface. Ask only decisions the evidence cannot answer.
+
+When blocked, retain the exact phase, evidence, questions, and recovery point. When complete, Retro must capture learning and route accepted improvements into project-owned SPECS assets.

package/skills-src/ewai-deliver/references/delivery-evidence.md

@@ -0,0 +1,92 @@
+# EWAI delivery evidence contracts
+
+These are durable project records, not chat summaries. Paths are relative to `SPECS/6.Build/<slug>/` unless stated otherwise.
+
+## Task graph
+
+`task-graph.json` uses `schema_version: 1` and must contain:
+
+- `slug`, `status`, and `parent_branch`;
+- optionally, `repository_branches`, keyed by configured `SPECS/pipeline.yaml` repository name, when repositories use different integration branches;
+- `source.claim_ledger`, `source.plan_contract`, and `source.destination` pointing to real delivery artefacts;
+- `parallelism.allowed`, a positive `max_parallel_tasks`, and rationale;
+- one or more `afk_waves`, with ready tasks, parallel tasks, merge order, and rationale;
+- one or more tasks with unique IDs and branches.
+
+Every non-orchestration task requires:
+
+- `id`, `slice`, `name`, `issue_kind`, numeric `priority`, `parallel_wave`, `classification`, `repo`, and `branch`;
+- `depends_on` and Claim Ledger `claims`;
+- `user_visible_outcome`, `read_set`, `write_set`, and `central_writes_allowed`;
+- `module_interface_contract` containing `module`, `interface`, `behaviour_owned`, `caller_contract`, and `test_boundary`;
+- `first_failing_test` or an explicit rationale;
+- `red_green_refactor` containing `red_command`, `expected_red_failure`, `green_command`, and `refactor_boundary`;
+- bounded `allowed_commands`, `stop_conditions`, and named `completion_evidence`;
+- a bounded `ralph_loop` contract even when it is disabled;
+- `review.fresh_context_required: true`, `review.review_tests_first: true`, and binding `standards_pushed`;
+- `merge.orchestrator_owned: true` and `post_merge_checks`;
+- `report_path` and `evidence_path`, normally `tasks/T-###/report.md` and `tasks/T-###/evidence.json`.
+
+Every task `repo` must exactly match a configured repository name. Use branch names that are siblings of the integration branch, such as `ewai-afk-example-T-001-slice`; do not put a child ref below an existing branch such as `feature/example/T-001`, because Git cannot store both `feature/example` and `feature/example/T-001`. The AFK conductor preserves the declared task branch in evidence and records the actual safe branch it created.
+
+Every actionable Claim Ledger claim must be owned exactly once. Every task claim must exist in the ledger. Every non-orchestration slice must exist in both the Claim Ledger and Plan Contract. The validator rejects cycles, missing dependencies, unsafe central writes, overlapping parallel write sets, and incomplete nested contracts.
+
+## Task completion evidence
+
+The report remains the human-readable handoff. The evidence sidecar is the machine-verifiable completion record:
+
+```json
+{
+  "schema": "ewai.task-evidence/v1",
+  "task_id": "T-001",
+  "repository": "application",
+  "task_branch": "ewai-afk-example-T-001-slice",
+  "branch": "ewai-afk-example-T-001-slice",
+  "base_branch": "feature/example",
+  "commit": "full-or-short-commit-id",
+  "changed_files": ["src/example.js"],
+  "commands": [
+    {"stage":"red","command":"npm test -- example","expected_failure":"feature is not implemented","exit_code":1,"output_path":"tasks/T-001/evidence/red.txt","output_sha256":"..."},
+    {"stage":"green","command":"npm test -- example","exit_code":0,"output_path":"tasks/T-001/evidence/green.txt","output_sha256":"..."},
+    {"stage":"refactor","command":"npm test -- example","exit_code":0,"output_path":"tasks/T-001/evidence/refactor.txt","output_sha256":"..."}
+  ],
+  "review": {
+    "fresh_context": true,
+    "tests_reviewed_first": true,
+    "status": "pass",
+    "reviewer": "independent-session-id",
+    "evidence_path": "tasks/T-001/evidence/review.md",
+    "evidence_sha256": "..."
+  },
+  "completion_checks": [
+    {"name":"tests pass","status":"pass","evidence_path":"tasks/T-001/evidence/tests.txt","evidence_sha256":"..."}
+  ]
+}
+```
+
+Capture command output at execution time. Do not write a synthetic output file after the fact. In multi-repository delivery, implementation and checks run in the task's configured repository while the conductor writes this evidence into the project-root SPECS repository. Every changed file must remain within the task write set, command hashes must still match, all named completion obligations must pass, and review must be fresh and tests-first. Narrative alone never completes a task or unlocks its dependants.
+
+The AFK conductor may add `post_merge_checks` to the same evidence record. Each item carries the exact command, exit code, output path, and hash produced while the merge was pending. The conductor commits the merge only after these checks pass. This is additional integration evidence; it never substitutes for red, green, refactor, fresh-context review, or the named task completion checks.
+
+## Prototype manifest
+
+When UI Design applies, create `ui-design-assets/prototypes/manifest.json`:
+
+```json
+{
+  "schema": "ewai.prototype-manifest/v1",
+  "status": "selected",
+  "selected": {
+    "title": "Chosen interaction",
+    "path": "ui-design-assets/prototypes/selected.html",
+    "decision": "Why this option was selected"
+  },
+  "registration": {
+    "kind": "prototype",
+    "status": "active",
+    "path": "ui-design-assets/prototypes/selected.html"
+  }
+}
+```
+
+The selected file must be runnable and remain inside the prototypes directory. The registration path must match it so the project dashboard can expose the same approved prototype.

package/skills-src/ewai-deliver/references/phase-routing.md

@@ -0,0 +1,31 @@
+# EWAI phase routing
+
+The sequence below is mandatory. At every entry, use the project-local required-artefact contract and gate template. At every exit, record the gate and complete the phase through guarded EWAI operations.
+
+| Stage | Purpose | Exit evidence |
+|---|---|---|
+| 1. Ideate | Turn a rough thought into an inspectable problem and candidate outcome. | Grill ledger and draft intent. |
+| 2. Intent | Establish purpose, scope, users, acceptance evidence, constraints, dependencies, and readiness. | Accepted intent summary and dependency checks. |
+| 3. Reconcile | Compare intent with existing repository behaviour and resolve disagreement. | Repository-grounded reconciliation. |
+| UI Design | For user-facing work, agree the interaction and visual outcome before planning code. | Design record plus selected runnable prototype manifest. |
+| 4. Plan | Define vertical slices, claims, interfaces, tasks, write sets, sequencing, and implementation flow. | Build Plan, Claim Ledger, Plan Contract, destination, and task graph. |
+| 5. Pattern Validation | Challenge the plan against local architecture, patterns, standards, and source truth. | Passing pattern and contract checks. |
+| 6. Test Plan | Design proportional tests and explicit red/green/refactor evidence for every task and claim. | Test Plan plus task/test traceability. |
+| 7. Validate External Plan | Where configured, independently challenge the implementation plan. | Provider reviews, findings matrix, actions, and final passes. |
+| 8. Validate External Test Plan | Where configured, independently challenge coverage and test design. | Provider reviews, findings matrix, actions, and final passes. |
+| FitCheck | On resume or immediately before Build, check drift in code, standards, dependencies, and plan assumptions. | FitCheck report and any repaired plan evidence. |
+| 9. Build | Implement task contracts after explicit human approval, using leases and red/green/refactor. | Per-task narrative reports and machine-verifiable evidence JSON. |
+| 10. Standards Sweep | Verify the actual change against every binding project standard. | Standards report with no unresolved mandatory failures. |
+| 11. Test Execute | Run the planned suites and preserve outcomes. | Test execution report and captured output. |
+| 12. Validate External Code | Where configured, independently review the final change. | Provider reviews, findings matrix, actions, and final passes. |
+| 13. Delivery | Integrate task branches, run post-merge checks, prepare human walkthrough, and prove done. | Delivery checklist, task completion, and QA walkthrough. |
+| Manual QA | Let a human validate the real outcome. | Explicit durable approval or a return to corrective work. |
+| 14. Retro | Learn from the whole cycle and improve project knowledge and pipeline assets. | Retrospective, metrics, curated knowledge, and owned improvements. |
+
+## Conditional paths
+
+- Use shelf mode to stop after validated planning; resume only through FitCheck.
+- Escalate when evidence cannot resolve a consequential choice. Persist the question and exact recovery point.
+- Recover interrupted work from intent Markdown, intent JSON, delivery state, task evidence, and SQLite; never from chat memory.
+- Route a new idea or discovered gap through Intent shaping before delivery.
+- Where several intents share a product outcome, preserve their dependency and sequencing relationships rather than collapsing them into one oversized intent.

package/skills-src/ewai-design-system-apply/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: ewai-design-system-apply
+description: Apply a resolved EWAI design system to an existing UI-bearing delivery through bounded context, visible contextual personas, and an immutable delivery receipt. Use during UI Design or Prototype work before selecting a runnable prototype, or when an existing design application must be re-prepared after focus or source changes.
+---
+
+# EWAI Design System Apply
+
+Apply the project’s selected design system—or the clearly labelled bundled fallback—to one governed delivery. Read [the application contract](references/application-contract.md) before applying it.
+
+## Workflow
+
+1. Confirm the delivery exists and its UI Design adjunct is in scope. This skill does not create an intent, begin a delivery, or approve a phase.
+2. Inspect `ewai design-system status --project PROJECT --json`. Stop when a selected system is stale. A fallback is usable guidance but remains visibly unapproved.
+3. Describe the affected surface and current design focus. Keep it narrow enough for relevant context and personas to swap in.
+4. Run `ewai design-system apply DELIVERY_SLUG --focus TEXT --project PROJECT --json`. Add `--budget TOKENS` only when the default budget is unsuitable.
+5. Show the selected and deferred contributions and every active persona’s safe reference, name, tier, matched signals, and reason. Premium personas may enrich an installed catalogue, but the standard path must work without them and must never expose or persist their bodies.
+6. If the result is `non-ready`, do not construct a model prompt or a receipt. Narrow the focus, explicitly increase the budget, or split the operation and run it again.
+7. Use the returned digest-addressed receipt path, receipt digest, and effective design-system digest as the design-system section of `ewai.prototype-manifest/v3`.
+8. Use `$ewai-prototype-iteration` to review the plan and produced design with independently selected relevant personas, then link the reviewed plan and final cycle in v3.
+9. Select the runnable prototype only after the manifest validates. The receipt and persona review record influence and critique, not visual acceptance.
+
+## Boundaries
+
+- Never mutate the installed design-system pack while applying it.
+- Never conceal fallback mode, deferred mandatory guidance, stale source content, or an unavailable premium tier.
+- Never persist full contribution context, persona definitions, model prompts, credentials, or absolute source paths in a receipt.
+- Never treat application, persona participation, a valid manifest, or static conformance as Build approval, Manual QA, accessibility certification, deviation approval, publication, deployment, or release.

package/skills-src/ewai-design-system-apply/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "EWAI Design System Apply"
+  short_description: "Apply design systems to prototype work"
+  default_prompt: "Use $ewai-design-system-apply to apply the active design system to this UI delivery."