@thebackstoryis/engineering-with-ai 0.2.9

package/skills-src/ewai-knowledge-proposals/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: ewai-knowledge-proposals
+description: Turn promoted meeting evidence or a canonical EWAI retrospective into provenance-bound proposals for project personas, domain knowledge, journeys, requirements, feature candidates, risks, policies, constraints, standards, decisions, patterns, anti-patterns, runbooks or SOPs. Use when a user wants to extract durable learning from governed evidence, including after a meeting, retrospective, delivery or incident, without letting model output write directly into canonical SPECS.
+---
+
+# EWAI Knowledge Proposals
+
+Turn governed evidence into reviewable project knowledge. The workflow is **sources → prepare → record → named review → separate named materialisation**. Preparation and personas are advisory; deterministic EWAI code owns validation, destinations, digests and writes.
+
+Refined is a separate product and is out of scope. Do not add connectors, automatic downstream intents, provider-specific model clients or cross-project routing.
+
+## Check the source boundary
+
+Run the internal control-plane command:
+
+```bash
+ewai knowledge sources --project <path> --json
+```
+
+Use only a returned source reference. V1 accepts promoted meeting evidence and canonical retrospectives. Never substitute an arbitrary file path, private runtime record, draft meeting review or unpromoted transcript.
+
+If no eligible source exists, explain how to promote meeting evidence or complete a retrospective. Do not copy material into the evidence area to make it eligible.
+
+## Prepare the private host contract
+
+```bash
+ewai knowledge prepare <source-ref> --project <path> --json
+```
+
+Preparation writes nothing. It returns safe source facts, a digest, anchors, bounded `modelContext`, the strict proposal contract, authority notices and the active personas for this moment.
+
+The standard host model with relevant project and core personas is a complete baseline. Premium and personal personas are optional enrichment only when already installed and contextually selected. Never imitate a missing premium persona, fetch managed content, or change entitlement state.
+
+Before analysis, tell the user which active personas are engaged. Include each active persona's name, tier and engagement reason. Replace the ensemble when the source or focus changes rather than accumulating stale personas. Personas can challenge coverage and interpretation; they cannot establish truth, review their own proposals or approve materialisation.
+
+## Draft evidence-grounded proposals
+
+Read [the proposal contract](references/proposal-contract.md) before drafting.
+
+Separate observation from interpretation:
+
+- **Observation:** what the source and cited anchor support.
+- **Interpretation:** why that evidence may justify a particular kind of project knowledge.
+- **Proposal:** the bounded Markdown candidate, destination, rationale and uncertainty offered for human review.
+
+Use only kinds and destination roots returned by preparation. Cite the source reference and every evidence anchor in the proposal's `## Provenance` section. Keep uncertainty visible. Do not infer stakeholder acceptance, policy authority, legal meaning, security assurance or production readiness.
+
+Construct only `ewai.knowledge-proposal-bundle/v1`. Raw model output is never stored. Do not persist chain-of-thought, prompts, discarded drafts, source bodies or persona bodies. Submit only the final schema-valid bundle:
+
+```bash
+ewai knowledge record <source-ref> --input <project-relative-json> --project <path> --json
+```
+
+Recording writes under `SPECS/3.Evidence/knowledge-proposals/` only. It does not create canonical destination knowledge.
+
+## Facilitate complete named review
+
+Show each proposal with its kind, destination, evidence anchors, rationale, uncertainty and current destination state. Ask a named accountable person to choose exactly one disposition:
+
+- `accepted`;
+- `rejected`, with rationale;
+- `deferred`, with rationale; or
+- `amended`, with replacement title, complete replacement Markdown and rationale.
+
+Record the complete review:
+
+```bash
+ewai knowledge review <bundle-id> --input <project-relative-json> --reviewed-by <name> --project <path> --json
+```
+
+Named review and separate named materialisation are distinct decisions. Never infer either name from a persona, meeting participant or repository author.
+
+## Materialise only after a separate request
+
+First show the reviewed outcomes and explain the additive-only behavior: absent destinations are added, identical destinations are reported as current, and differing destinations are preserved as conflicts. There is no overwrite, model merge or deletion.
+
+Only after the user separately and explicitly asks to proceed, record the named approval:
+
+```bash
+ewai knowledge materialise <bundle-id> --project <path> --yes --approved-by <name> --json
+```
+
+Report added, current and conflict counts separately. A conflict remains unresolved and must not be described as successfully merged. Materialisation does not create a delivery intent, approve Build, accept risk, satisfy Manual QA or authorise release.
+
+If status reports `recovery-required`, explain what the transaction owns and ask before running:
+
+```bash
+ewai knowledge recover <bundle-id> --project <path> --yes --json
+```
+
+Recovery may remove only incomplete transaction-owned writes. It preserves changed and unrelated files. Inspect current state with `ewai knowledge status [<bundle-id>] --project <path> --json`.
+
+## Stop conditions
+
+Stop and ask the user when:
+
+- the source is not on the eligible list or its digest changed;
+- an anchor does not support the proposed interpretation;
+- the taxonomy or destination is uncertain;
+- review is unnamed or incomplete;
+- a proposal needs specialist, legal, security or stakeholder evidence not present in the source;
+- materialisation has not been separately requested and named; or
+- a destination is a conflict.
+
+Security validation is evidence, not certification or proof that this system is secure. Tools can miss vulnerabilities and produce false positives. A qualified human must review the scope, findings, limitations and residual risk before release.

package/skills-src/ewai-knowledge-proposals/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Knowledge Proposals"
+  short_description: "Turn governed evidence into reviewed SPECS proposals"
+  default_prompt: "Use $ewai-knowledge-proposals to prepare, review and materialise evidence-grounded project knowledge."

package/skills-src/ewai-knowledge-proposals/references/proposal-contract.md

@@ -0,0 +1,59 @@
+# Knowledge proposal contract
+
+## Bundle envelope
+
+Submit one `ewai.knowledge-proposal-bundle/v1` object:
+
+```json
+{
+  "schema": "ewai.knowledge-proposal-bundle/v1",
+  "sourceRef": "retrospective:sprint-24",
+  "sourceDigest": "64-lowercase-hex-characters",
+  "proposals": []
+}
+```
+
+Every proposal ID uses `KNP-###` with at least three digits. IDs and destinations are unique within the bundle. The source reference, digest and anchor IDs must exactly match preparation.
+
+## Proposal fields
+
+Each proposal contains only `id`, `kind`, `title`, `destination`, `evidenceAnchors`, `rationale`, `uncertainty`, `relationships` and `proposedMarkdown`. Use one to 30 prepared anchors. Begin Markdown with one H1 and include `## Provenance` with the exact source reference and every anchor.
+
+Do not include raw source excerpts, prompts, chain-of-thought, executable content, credentials, approval claims or extra fields.
+
+## Closed taxonomy and destination roots
+
+| Kind | Destination root below the configured SPECS root |
+| --- | --- |
+| `project-persona` | `1.Scope/personas/project/` |
+| `system` | `1.Scope/domain/systems/` |
+| `process` | `1.Scope/domain/processes/` |
+| `data-concept` | `1.Scope/domain/data/` |
+| `journey` | `2.Purpose/journeys/` |
+| `requirement` | `2.Purpose/requirements/pending/` |
+| `feature-candidate` | `2.Purpose/explorations/feature-candidates/` |
+| `risk` | `3.Evidence/risk/` |
+| `policy` | `4.Constraints/compliance/policies/` |
+| `constraint` | `4.Constraints/` |
+| `standard` | `4.Constraints/standards/` |
+| `decision` | `5.Strategy/decisions/` |
+| `pattern` | `5.Strategy/patterns/` |
+| `anti-pattern` | `5.Strategy/anti-patterns/` |
+| `runbook` | `5.Strategy/runbooks/` |
+| `sop` | `5.Strategy/sops/` |
+
+The filename is safe lowercase kebab-case Markdown. A model cannot nominate `6.Build`, runtime state, an absolute path or another project.
+
+## Review contract
+
+Every proposal receives exactly one `accepted`, `rejected`, `amended` or `deferred` disposition. Rejected and deferred decisions require rationale. Amended decisions require rationale, replacement title and complete replacement Markdown with source provenance.
+
+Review is stored beside the immutable bundle below `SPECS/3.Evidence/knowledge-proposals/<bundle-id>/`. It does not write the proposed destination.
+
+## Materialisation states
+
+- `additive`: destination is absent and may be created after separate named approval.
+- `already-current`: destination is byte-identical and no write is needed.
+- `conflict`: destination differs, is a symlink or is not a regular file; preserve it unchanged.
+
+Materialisation revalidates `sourceDigest`, bundle digest and review digest. The immutable ledger is persisted before `ewai.knowledge-proposals.materialised` is published. Lifecycle handlers receive identifiers, digests, counts and timestamps only and cannot alter canonical truth.

package/skills-src/ewai-meeting-evidence/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: ewai-meeting-evidence
+description: Register a local meeting transcript or minutes file, prepare a privacy-aware extraction contract with contextually selected personas, create source-anchored evidence candidates, record complete named review, and promote accepted evidence only. Use when a user asks EWAI to learn from meeting minutes, VTT or SRT captions, plain-text transcripts, call notes, or a supplied transcript while preserving provenance and human authority.
+---
+
+# EWAI Meeting Evidence
+
+Turn a registered meeting source into concise, reviewed project evidence. Read [the candidate contract](references/candidate-contract.md) before inspecting an allowed source or constructing a bundle.
+
+This skill does not transcribe recordings, connect to meeting platforms, copy raw material into SPECS, or author downstream project truth automatically. Refined is a separate product and is explicitly out of scope.
+
+## Register with explicit permission
+
+Establish the file, label, classification and cloud-processing policy. Confirm that the user is authorised to process the material and has considered privileged, HR, credential, unrelated-client and personal content.
+
+Register only after explicit confirmation:
+
+```bash
+ewai meeting register <file> \
+  --project . \
+  --label "Product sync" \
+  --classification internal \
+  --cloud-processing allowed \
+  --yes \
+  --json
+```
+
+Supported sources are Markdown, text, VTT and SRT files within the deterministic size and line limits. Registration stores the absolute path only in the gitignored private runtime record. Never reproduce that path, participant details or raw source text in public responses.
+
+If cloud processing is denied or unknown, do not open, inspect or read the source in a hosted session. Run preparation to report the `manual-local-handoff` route, then stop source inspection and help the user choose an approved local process. Do not weaken the policy.
+
+## Prepare before extraction
+
+Run:
+
+```bash
+ewai meeting prepare <source-id> --project . --json
+```
+
+Preparation verifies freshness and returns safe source facts, the processing decision, the exact candidate contract and the active persona ensemble. It does not invoke a model.
+
+The standard host model with project and core personas is the complete baseline. Premium personas participate only when installed and contextually relevant; installed personal personas can also add optional specialist depth. Never sync, download, update, imitate or expose a premium persona as part of this skill.
+
+Before semantic work, show every active persona name, tier, matched signal and engagement reason. Use only the returned ensemble. When the source or focus changes, prepare again and swap the ensemble; do not accumulate stale personas. Personas advise interpretation and coverage. They do not provide source evidence, stakeholder consent, review, approval or release authority.
+
+## Extract candidates in bounded passes
+
+Use the source only when `processing.permitted` is true. Work linearly or in bounded line ranges so anchors remain stable. Apply different returned persona lenses to relevant passes, keeping their concerns distinct.
+
+For every candidate:
+
+1. Assign a stable `MEC-###` ID and an allowed type.
+2. Put only a concise source-grounded paraphrase in `observedStatement`.
+3. Put analysis, consequence or uncertainty in `interpretation`.
+4. Cite one or more exact `lineAnchors` within the registered line count.
+5. Use only `low`, `medium` or `high` confidence.
+
+Do not include transcript excerpts, prompts, private paths, participant identifiers or raw model output. Do not infer consensus, authority or implementation merely because a topic was discussed.
+
+## Obtain complete named review
+
+Present manageable candidate groups to an accountable person. They must mark every candidate exactly once as `accepted`, `rejected`, `amended` or `deferred`. An amendment requires replacement text and a rationale.
+
+Create a project-relative JSON review input following the reference contract, then record it:
+
+```bash
+ewai meeting review <source-id> \
+  --input <project-relative-review.json> \
+  --reviewed-by "Named reviewer" \
+  --project . \
+  --json
+```
+
+A named review is durable but remains private runtime state until separately promoted. Never manufacture a reviewer name or treat persona agreement as review.
+
+## Promote evidence separately
+
+Inspect current status first:
+
+```bash
+ewai meeting status <source-id> --project . --json
+```
+
+After the person confirms the reviewed bundle and understands the authority boundary, promote accepted and amended candidates only:
+
+```bash
+ewai meeting promote <source-id> \
+  --project . \
+  --yes \
+  --approved-by "Named approver" \
+  --json
+```
+
+Promotion is evidence-only. It writes the paired `evidence.json` and `evidence.md` under the configured SPECS root at `3.Evidence/meeting-evidence/<source-id>/`. It does not create or change an intent, task, requirement, process, policy, persona, architecture decision, approval, accepted risk, Build state, Manual QA, deployment or release.
+
+## Recover and stop safely
+
+- If source freshness is not `current`, stop and register or review the current source.
+- If cloud processing is denied or unknown, use the manual local route and do not inspect content.
+- If bundle validation fails, fix the candidate file; do not bypass the schema.
+- If review is incomplete or conflicting, return it to the named reviewer.
+- If promotion finds drift, an incomplete pair or conflicting evidence, preserve the records and investigate.
+- An identical promotion retry is idempotent; do not edit promoted files to force a different result.
+- If evidence suggests downstream work, create or enrich an intent only through the normal separately approved workflow.
+
+Security validation is evidence, not certification or proof that this system is secure. Tools can miss vulnerabilities and produce false positives. A qualified human must review the scope, findings, limitations and residual risk before release.

package/skills-src/ewai-meeting-evidence/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Meeting Evidence"
+  short_description: "Extract and review meeting evidence safely"
+  default_prompt: "Use $ewai-meeting-evidence to extract, review and promote source-grounded meeting evidence."

package/skills-src/ewai-meeting-evidence/references/candidate-contract.md

@@ -0,0 +1,64 @@
+# Meeting evidence candidate contract
+
+Use the exact `candidateContract` returned by `ewai meeting prepare`. The current public bundle schema is `ewai.meeting-candidate-bundle/v1`.
+
+## Candidate bundle
+
+```json
+{
+  "schema": "ewai.meeting-candidate-bundle/v1",
+  "sourceId": "meeting.product-sync.0123456789ab",
+  "sourceDigest": "64-character source digest",
+  "candidates": [
+    {
+      "id": "MEC-001",
+      "type": "decision",
+      "observedStatement": "A named owner will review the release evidence.",
+      "interpretation": "Release remains a human decision rather than an automated consequence.",
+      "lineAnchors": [{ "start": 42, "end": 47 }],
+      "confidence": "high"
+    }
+  ]
+}
+```
+
+Allowed candidate types are `task`, `decision`, `process`, `risk`, `system`, `policy`, `requirement`, `assumption` and `open-question`. IDs use `MEC-###` with three or more digits. Anchors are inclusive, one-based line ranges inside the registered source line count.
+
+The fields are deliberately separate:
+
+- `observedStatement` is a concise paraphrase of what the source supports.
+- `interpretation` is analysis of what the observation may mean.
+- `confidence` communicates extraction certainty, not approval or truth.
+
+Raw source excerpts are not allowed. Raw model output, prompts, source paths, participant identifiers, credentials and unbounded summaries are not allowed. Unknown fields fail validation.
+
+## Named review input
+
+The CLI review file wraps the bundle and one complete disposition list:
+
+```json
+{
+  "bundle": {
+    "schema": "ewai.meeting-candidate-bundle/v1",
+    "sourceId": "meeting.product-sync.0123456789ab",
+    "sourceDigest": "64-character source digest",
+    "candidates": []
+  },
+  "dispositions": [
+    {
+      "candidateId": "MEC-001",
+      "decision": "amended",
+      "replacementText": "A product owner will review the release evidence.",
+      "rationale": "The original wording did not name the accountable role."
+    }
+  ]
+}
+```
+
+Every candidate appears exactly once. Decisions are `accepted`, `rejected`, `amended` or `deferred`. `amended` requires both `replacementText` and `rationale`; replacement text is forbidden for the other decisions. Rejected and deferred candidates remain in review history but are not promoted.
+
+## Freshness and authority
+
+The source digest binds extraction, review and promotion. Any source or review drift fails closed. Promotion requires a separate exact confirmation and named approver. It creates reviewed meeting evidence only and does not author downstream project records or grant delivery authority.
+
+Security validation is evidence, not certification or proof that this system is secure. Tools can miss vulnerabilities and produce false positives. A qualified human must review the scope, findings, limitations and residual risk before release.

package/skills-src/ewai-organisation-policy/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: ewai-organisation-policy
+description: Author, adopt, inspect and operate optional Organisation Policy Design Gates in an EWAI project. Use when creating data-only policy contributions in Organisation Blueprint Packs; selecting and approving a project policy baseline; proposing and confirming intent design facts; evaluating a design; tracing controls into Plan evidence; recording a named review or bounded exception; or recovering from policy, fact or evaluation drift.
+---
+
+# EWAI Organisation Policy
+
+Keep policy work at design time. Use the shared EWAI domain and adapter operations; never invent a second evaluator in a skill, prompt, UI, hook, or connector.
+
+Resolve the project and configured SPECS root from `.ewai-pipeline/project.json`. Read [the policy contract](references/policy-contract.md) before authoring, adopting, confirming, evaluating, reviewing, or excepting policy evidence.
+
+Organisation Policy Design Gates are design-time evidence only. They do not enforce production traffic, execute production code, certify compliance, approve Build or Manual QA, authorise release, or accept residual risk.
+
+## Choose the operation
+
+- **Author:** create or revise a strict data-only policy contribution in an Organisation Blueprint Pack.
+- **Adopt:** preview a resolved policy baseline and ask a named person to approve its exact digest through Guided Setup.
+- **Apply:** propose attributed facts, obtain complete named-human confirmation, then run the deterministic evaluator.
+- **Resolve:** route `review-required` to the named role or use a bounded exception only when the matched rule explicitly permits it.
+- **Recover:** re-evaluate after policy, intent, fact, Claim Ledger, task, test, or control-evidence drift.
+
+If no policy baseline is configured, report `not-configured` as explicitly non-blocking and stop policy work. Do not create a hidden default.
+
+## Engage personas without delegating authority
+
+Use standard model reasoning plus installed core and project personas as the complete baseline. Swap in relevant installed personal and premium personas when the policy stage, design dimensions, or uncertainty changes.
+
+Show every active persona's name, tier, matched signal, and engagement reason. Treat its output as a hypothesis or challenge. A named human must confirm every design fact and make every review or exception decision.
+
+Premium personas are optional enrichment and may participate only when reported as installed. Never sync, download, update, imitate, or expose premium persona bodies while using this skill.
+
+## Author and adopt
+
+1. Identify the accountable policy owner, provenance, sources, review roles, unmatched outcome, and closed conditions.
+2. Use only the closed condition dimensions and outcomes in the contract. Keep the pack inert: no scripts, commands, prompts, templates, expressions, remote sources, credentials, hooks, or endpoints.
+3. Give every control an explicit evidence route: Claim Ledger claim, task, automated test, named human, or specialist review.
+4. Add the policy contribution to the appropriate Blueprint module and validate the complete pack.
+5. Use Guided Setup to select the Blueprint and inspect its policy preview.
+6. Ask a named person to approve the exact effective digest. Upstream changes create drift; they never rewrite the accepted project baseline.
+
+## Apply to an intent
+
+1. Read the current intent, Impact evidence, accepted architecture, data and hosting decisions, and configured policy baseline.
+2. Prepare attributed candidate facts through the canonical `preparePolicyFacts` domain operation. Distinguish observed evidence, model proposals, and persona hypotheses.
+3. Present all candidates and active personas. Require one named person to confirm or reject every proposed fact.
+4. Record the complete confirmation with `ewai_policy_confirm_facts` or `ewai policy confirm-facts --input <project-relative.json>`.
+5. Evaluate the exact current intent revision, policy digest, and facts digest with `ewai_policy_evaluate` or `ewai policy evaluate --input <project-relative.json>`.
+6. Inspect the business and technical views with `ewai_policy_status` or `ewai policy status <domain/slug> --mode business|technical`.
+
+The evaluator is deterministic. Personas may discover missing facts and challenge consequences; they never choose the outcome.
+
+## Resolve reviews, exceptions, and controls
+
+- For `review-required`, ask the exact required role for a named decision, rationale, evidence, and any controls. Record it against the current evaluation digest.
+- For `deny`, do not soften the result. An exception is possible only when that exact matched rule permits one.
+- For an exception, require a named approver, accountable owner, exact bounded scope, rationale, compensating controls, evidence, and future expiry.
+- During Plan, trace every policy control to the allowed Claim Ledger, task, automated-test, named-human, or specialist-review evidence route.
+- Re-run the gate after relevant evidence changes. Never copy a previous pass forward.
+
+## Stop conditions
+
+Stop and escalate when a policy source is ambiguous, executable, remote, or untrusted; the baseline or facts are stale; confirmation is incomplete; the required reviewer is absent; an exception is prohibited or unbounded; control evidence is missing; a model is being asked to make a human decision; or anyone asks EWAI to enforce production behaviour, certify compliance, approve Build or Manual QA, deploy, release, or accept risk.

package/skills-src/ewai-organisation-policy/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "EWAI Organisation Policy"
+  short_description: "Design and review organisation policy gates"
+  default_prompt: "Use $ewai-organisation-policy to author or apply an optional organisation policy design gate."

package/skills-src/ewai-organisation-policy/references/policy-contract.md

@@ -0,0 +1,94 @@
+# Organisation Policy Design Gate contract
+
+## Permanent authority boundary
+
+Organisation Policy Design Gates are design-time evidence only. They do not enforce production traffic, execute production code, certify compliance, approve Build or Manual QA, authorise release, or accept residual risk.
+
+## Policy pack
+
+An organisation contribution uses `ewai.organisation-policy/v1`. It is strict, data-only, versioned, publisher-bound, provenance-bearing, and limited to this closed condition vocabulary:
+
+- `resource`
+- `operation`
+- `data_entity`
+- `data_classification`
+- `actor`
+- `environment`
+- `destination`
+- `model`
+- `ai_use`
+- `retention`
+
+Outcomes are `allow`, `deny`, `review-required`, `allow-with-controls`, and `unassessed`. Restrictive unresolved outcomes govern. `not-configured` is a workspace state, not a policy outcome, and is non-blocking.
+
+Policy objects cannot contain script, command, prompt, template, expression, executable, secret, credential, token, remote, URL, endpoint, handler, or hook fields. Values are bounded identifiers rather than executable expressions.
+
+Every control declares one or more evidence routes: `claim`, `task`, `automated-test`, `named-human`, or `specialist-review`. A review-required rule names a configured review role. A permitted exception names its review role; prohibited exceptions cannot name one.
+
+## Baseline and drift
+
+Organisation Blueprint resolution produces exact pack, contribution, Blueprint, policy, and effective digests. Guided Setup previews the result and materialises `SPECS/4.Constraints/organisation-policy/baseline.json` only after named approval of the exact digest.
+
+No contribution means `not-configured`, `enabled: false`, and `blocking: false`. A changed source pack makes the accepted baseline stale; it never silently changes the project record.
+
+## Facts and evaluation
+
+Candidate facts use the same closed dimensions and preserve one of three provenance types:
+
+- `observed`
+- `model-proposal`
+- `persona-hypothesis`, with safe persona ID, name, and tier
+
+The `preparePolicyFacts` domain operation creates the current digest-bound proposal. Confirmation requires `authority: human`, a named confirmer, the exact proposal revision and digest, and one disposition for every fact.
+
+Evaluation requires the current intent revision, effective policy digest, and confirmed-facts digest. It records every matched rule and the governing outcome. Reviews and exceptions are immutable decisions bound to that evaluation digest. Any relevant revision change makes them stale.
+
+## Interfaces
+
+CLI reads:
+
+```text
+ewai policy status [INTENT] --mode business|technical --project . --json
+```
+
+CLI writes accept a project-relative JSON file:
+
+```text
+ewai policy confirm-facts --input FILE --project . --json
+ewai policy evaluate --input FILE --project . --json
+ewai policy review --input FILE --project . --json
+ewai policy exception --input FILE --project . --json
+```
+
+MCP tools:
+
+- `ewai_policy_status`
+- `ewai_policy_confirm_facts`
+- `ewai_policy_evaluate`
+- `ewai_policy_record_review`
+- `ewai_policy_record_exception`
+
+Loopback HTTP routes:
+
+- `GET /api/policies?intent=<domain/slug>&mode=business|technical`
+- `POST /api/policies/facts/confirm`
+- `POST /api/policies/evaluate`
+- `POST /api/policies/reviews`
+- `POST /api/policies/exceptions`
+
+The dashboard **Policy gates** view consumes the same workspace. Business and technical views share one result and reference. It exposes active persona tier and engagement reason while retaining named-human authority.
+
+Requests never supply a project root, organisation root, policy root, or production target. Adapters call the shared service and never derive rules or outcomes.
+
+## Delivery integration
+
+When enabled, current passing policy evidence is conditional for Intent and Plan gates. Plan controls must resolve transitively to exact Claim Ledger, task, test, named-human, or specialist-review evidence. Relevant Impact dimensions are actors, AI use, data, destinations, hosting, and integrations. Changes invalidate affected evidence; unrelated summary churn does not.
+
+Lifecycle events are emitted only after exact durable records exist:
+
+- `ewai.policy.facts.confirmed`
+- `ewai.policy.evaluation.recorded`
+- `ewai.policy.review.recorded`
+- `ewai.policy.exception.recorded`
+
+Events include only status, intent reference, evidence digest, and optional rule ID. Hooks observe a completed EWAI mutation; they cannot veto it, change EWAI state, or invoke production systems on EWAI's behalf.

package/skills-src/ewai-palace-housekeeping/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: ewai-palace-housekeeping
+description: Inspect and maintain an EWAI project's SPECS Mind Palace using deterministic tidiness findings, the SPECS Knowledge Curator persona, and human-reviewed changes. Use when the user asks to tidy, clean, organise, validate, deduplicate, reconnect, or review project knowledge; when `ewai palace tidiness` recommends housekeeping; after Archaeology, Context Import, a large Retro, or substantial SPECS changes; or when knowledge appears stale, conflicting, unsupported, misplaced, duplicated, orphaned, or linked to files that no longer exist.
+---
+
+# EWAI Palace Housekeeping
+
+Keep the project Mind Palace trustworthy without treating AI interpretation as project truth. Deterministic checks identify possible disorder; the SPECS Knowledge Curator and project owner decide what it means and what should change.
+
+## Inspect before interpreting
+
+1. Run `ewai palace tidiness --project <root> --json`.
+2. If the result is `tidy`, report the no-op clearly and stop. Do not manufacture improvements.
+3. Read every flagged source document before proposing a change. A filename or link graph is evidence of structure, not evidence that the content is wrong.
+4. Use `ewai palace search <query> --project <root> --json` to find related decisions, intents, personas, standards, risks, runbooks, evidence, and code references.
+5. Apply the `ewai.core.specs-knowledge-curator` perspective when routing accepted knowledge.
+
+Treat tidiness codes as prompts for review:
+
+- `broken-internal-link`: verify whether the target moved, was intentionally removed, or was never created.
+- `duplicate-content`: determine the canonical record; similar files can legitimately represent different scopes.
+- `orphaned-document`: decide whether to add meaningful links, refile it, archive it, or leave it intentionally independent.
+- `missing-title` or `empty-document`: distinguish incomplete knowledge from an intentional placeholder or machine-readable artefact.
+
+## Review with the user
+
+Offer these routes in plain language:
+
+1. A short walkthrough grouped by the decisions one answer can resolve.
+2. A document-by-document review.
+3. A proposed housekeeping plan without changing anything.
+4. Apply only the low-risk corrections the user explicitly approves.
+
+Synthesize cross-document questions so one answer can resolve several genuinely shared findings. List every affected file before asking. Split the question when one answer would conceal meaningful differences.
+
+## Apply approved housekeeping
+
+- Never delete, merge, archive, refile, supersede, or rewrite canonical SPECS without explicit approval.
+- Preserve provenance and history. Prefer superseding links over erasure.
+- Do not promote an inference into a decision, constraint, standard, requirement, persona, risk, or accepted fact.
+- Refuse to overwrite different canonical knowledge silently.
+- Keep raw archaeology and context-import evidence in its evidence bundle when accepted knowledge is curated elsewhere.
+- Update affected indexes and reciprocal links when a record moves or changes status.
+- Do not commit changes unless the user asks.
+
+After approved changes:
+
+1. Run `ewai palace refresh --project <root>`.
+2. Run `ewai palace tidiness --project <root> --json` again.
+3. Explain what improved and what remains deliberately unresolved.
+4. Record material housekeeping under `SPECS/3.Evidence/palace-housekeeping/<date>-<subject>.md`, including the before/after findings, approvals, changed records, deferred items, and provenance. Do not create a report for a no-op unless the user requests one.
+
+## Completion contract
+
+Housekeeping is complete only when approved changes are applied, the derived index is refreshed, tidiness is rerun, unresolved findings remain visible, and no canonical meaning was changed without owner approval.

package/skills-src/ewai-palace-housekeeping/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "EWAI Palace Housekeeping"
+  short_description: "Review and tidy project knowledge safely"
+  default_prompt: "Use $ewai-palace-housekeeping to inspect my project Mind Palace and walk me through any proposed housekeeping."

package/skills-src/ewai-persona-entitlement/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: ewai-persona-entitlement
+description: Configure website-purchased EWAI persona licences, inspect entitlement and verified local pack state, explain annual individual/team expiry, and explicitly install or update premium personas.
+---
+
+# EWAI Persona Entitlement
+
+Premium personas are optional advisory lenses, not approval authority. Keep remote access, local installation, verification and active persona selection separate.
+
+## Check each session
+
+When EWAI is configured, run `ewai checkin --project . --json` at the start of every session, unless the managed SessionStart hook has already supplied that launch's result. Dashboard launch checks entitlement too, including reuse of an existing server. A new session needs a fresh check; an old status is not current access evidence.
+
+Report safe access, pack state, version/update offer and expiry message. Unknown is neither entitlement nor confirmed expiry. Core EWAI stays available. Never implicitly or automatically download or sync premium content during check-in, dashboard launch, delivery or persona selection.
+
+## Set up a website licence privately
+
+If no key is configured, ask: **“Do you have a premium persona licence, or shall we use the core personas?”** Respect a decline. Reading opens https://www.conversationalcoding.dev/personas/ without buying, activating or downloading. Do not ask this missing-key question for an expired, invalid or unavailable configured licence.
+
+Only when setup is chosen, explain where to find the key: Conversational Coding My Account, after purchase or seat allocation. Use the guarded loopback dashboard password form by default. A hidden private terminal prompt is an alternative only when a genuine interactive terminal is available; don't ask a tool runner to emulate hidden input or make the user paste it in chat. Submission verifies and installs the pack immediately; this is consent for that download, not future updates:
+
+```bash
+ewai persona premium configure --project . --machine-name "Work laptop"
+ewai persona premium status --project . --json
+```
+
+The configure command asks for the licence key without echoing it, verifies then downloads and installs using the core ZIP verifier. Report its safe ready/version/count result; if activation or installation fails, explain the failure without claiming readiness. Do not collect the key in chat, shell arguments/history, SPECS or screenshots. Dashboard entry is transient and goes only to the guarded loopback route; it never enters storage or responses. Invalid keys and the machine limit keep previous credentials on failed verification. Refresh the persona index after success. Before Archaeology settle chosen setup or explicitly continue core-only after decline/failure.
+
+Credentials live in private user-level EWAI config, not project YAML. A random private installation secret is shared through the documented Conversational Coding installation contract; the machine name is only a readable label. Website licence delivery is the only premium persona route. Missing keys offer private setup or continuing with core/personal/project personas. Never acquire personas from source control or use it after a failed licence check.
+
+## Download only with explicit consent
+
+Keep setup replies brief: installed version/count on success, or a safe cause and next action on failure. A setup 404 means the dashboard endpoint is missing, not that the key is invalid: restart EWAI, open its current dashboard link and retry there. Connection failures may leave completion uncertain; check status before retrying. Don't echo raw server messages or claim an unverified download is ready.
+
+Offer install, update or replacement, then obtain explicit human consent for that action:
+
+```bash
+ewai persona premium sync --project . --yes
+```
+
+A pack owned by another seat/provider additionally requires explained replacement and `--replace`. The flag is immediate command confirmation, not permission for future downloads. Do not override local changes.
+
+The website provider obtains a short-lived grant and immutable archive. Core EWAI bounds and verifies archive bytes, rejects unsafe ZIP entries, independently validates pack.yaml and content, stages privately, atomically promotes, writes an external provenance receipt, and rolls back on failure. No provider may self-assert trust or bypass these checks.
+
+## Annual expiry and safe cleanup
+
+- An authenticated **expired team** status removes only the managed premium cache whose receipt matches that server, subscription, seat and team plan. This is the narrowly authorised automatic cleanup exception; it never downloads content.
+- An **expired individual** subscription keeps installed personas and tells the user that updates have ended. Do not attempt a new download.
+- Cancellation does not mean expiry: access remains until the paid term ends.
+- Invalid activation, arbitrary 403, timeout, outage, malformed/older contract or unrelated seat is not deletion authority.
+- User-created personal/project personas are outside the managed cache and must never be touched.
+- Unsafe paths, local drift, mismatched ownership, concurrent mutation or failed cleanup need investigation; never describe blocked cleanup as successful.
+
+Installed does not automatically engage personas, and verified local content does not prove current entitlement. Report unverified states honestly.
+
+## Boundaries
+
+Use only safe status: no licence key, installation secret, bearer token, download grant, email, absolute cache path, raw server error or premium body. This skill cannot approve Build or Manual QA, accept risk or licence terms, deploy, publish, release, certify persona quality, or grant human authority.
+
+Read [the provider guide](../../Docs/persona-entitlement-provider-guide.md) when implementing or diagnosing trust, storage or expiry contracts. Live purchased-key acceptance is separate from synthetic tests.

package/skills-src/ewai-persona-entitlement/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "EWAI Persona Entitlement"
+  short_description: "Inspect and govern premium persona pack access"
+  default_prompt: "Use $ewai-persona-entitlement to inspect or safely operate premium persona entitlement for this EWAI project."