@vegastack/skills 0.2.0 → 0.3.0

package/skill/arch-guardian/references/advisory-report.md

@@ -0,0 +1,65 @@
+# Advisory report contract
+
+The advisory report is the guardian's review output. It is produced by the agent (not a checker script), is consumable by humans and by automation (a ship skill may parse the JSON block), and carries no gating semantics: findings inform decisions, the team decides.
+
+## Severities
+
+| Severity | Meaning |
+|---|---|
+| `critical` | security, correctness, or data-loss defect — fix now at any tier |
+| `production-gate` | must be addressed before or at production tier |
+| `enterprise-gate` | required only at enterprise tier |
+| `consider` | improvement; explicitly optional |
+
+A finding's severity comes from the violated rule's tier floor relative to the project's declared tier: a rule at or below the current tier that is violated is `critical` when it is a security/correctness invariant, otherwise it reports at its own tier gate. Rules above the current tier report as that tier's gate, never as failures.
+
+## Evidence discipline
+
+These rules are hard requirements; they exist to make false positives structurally difficult.
+
+1. Every finding cites concrete evidence: `file:line`, a config key, a schema statement, or a fetched source URL. A claim without evidence is a **question**, listed separately — never a finding.
+2. Every finding names the principle or rule ID it derives from, so "why does this apply to me" is always answerable from the report.
+3. Detection is never a claim of absence. "No RLS statements found in `db/`" is a question unless every schema/migration file was actually read.
+4. Behavior that cannot be verified in context (runtime, provider, recovery) is listed under `notVerified` with a reason and a suggested verification — never asserted either way.
+5. Repeated identical findings are capped with a count; a report is a decision aid, not a wall of noise.
+6. Grades summarize, they do not gate: `sound` / `attention` / `at-risk` per reviewed area, plus a one-line overall assessment. There is no REJECT vocabulary; a deliberate, recorded team decision the guardian disagrees with is reported as `accepted risk — guardian recommends revisiting`, with the reason.
+
+## Report shape
+
+Markdown for humans, ending with one fenced `json` block for automation:
+
+```json
+{
+  "schemaVersion": 1,
+  "project": "name",
+  "tier": "production",
+  "overall": "one-line assessment",
+  "grades": { "identity": "sound", "tenancy": "attention" },
+  "findings": [
+    {
+      "severity": "production-gate",
+      "principle": "TEN-002",
+      "summary": "one-sentence defect statement",
+      "evidence": ["db/001-tenant.sql:14"],
+      "suggestedAction": "what to change"
+    }
+  ],
+  "questions": ["things the review could not determine from evidence"],
+  "notVerified": [{ "claim": "PITR restore works", "reason": "not executed", "verify": "run a restore drill" }]
+}
+```
+
+## Evidence recipes
+
+Deterministic searches worth running during a review (read the hits before citing them — a match is a lead, not a finding):
+
+- **Tenant tables without RLS**: for each `CREATE TABLE` with a `workspace_id` column, confirm matching `ALTER TABLE … ENABLE ROW LEVEL SECURITY` and `FORCE ROW LEVEL SECURITY` statements exist, and that policies do not reduce to `USING (true)`.
+- **Composite tenant keys**: tenant-owned unique/foreign keys should include `workspace_id`; a bare `id` uniqueness on a tenant table is a lead for TEN-001.
+- **Plaintext secrets**: search tracked files for private key blocks, `Authorization: Bearer` literals, and provider key prefixes; check `.env*` files are gitignored and `.env.local` stays local-only.
+- **Session-state tenancy**: `SET (?!LOCAL)` / `set_config(..., false)` in SQL near tenant context is a lead for TEN-003 (context must be transaction-local).
+- **Runtime placement**: EVE/`@workflow/*` or `pg-boss` imports inside a web bundle or OpenNext worker source root are leads for RUN-001/RUN-002.
+- **Cookie/CSRF posture**: auth configuration disabling secure cookies, CSRF, or origin checks is a lead for AUTH-003.
+- **Sandbox egress**: sandbox configuration without an explicit allowlist (deny-by-default) is a lead for SBX-003.
+- **Unpinned models**: `latest` or alias model identifiers in production routes are leads for MLIFE-001.
+
+Respect `.guardianignore` (path prefixes, one per line) when the project provides one, and say in the report which paths were excluded or skipped.

package/skill/arch-guardian/references/architecture/ai-cost.md

@@ -2,6 +2,8 @@
 
 Apply this reference only when metered AI resources exist — model calls, sandbox runtime, embedding or knowledge processing. Cost here is an architecture concern: unattributed spend is an ownership gap, and an unbounded token path is a reliability defect. Billing, pricing, and Stripe remain out of foundation scope.
 
+Minimum viable form by tier — prototype: none required. Production: attribution logging (`COST-001`) plus a hard spend cap or alert. Enterprise: full budgets, cache economics, and the regression gate.
+
 - **COST-001 — Workspace attribution.** Every model, embedding, sandbox, and knowledge-processing call **MUST** record per-workspace attribution: tokens in/out, cached versus uncached, provider and model pin, feature or agent identity, and run correlation. Aggregate provider invoices are not attribution; the platform must be able to state what any workspace cost yesterday.
 - **COST-002 — Budgets and alerts.** Production AI features **MUST** define token or spend budgets per workspace and per feature, with alert thresholds and an explicit overrun behavior — shed, degrade, or pause visibly. Silent unlimited spend and silent hard-stop are both forbidden; the overrun behavior is a declared product decision.
 - **COST-003 — Cache economics.** Prompt/context caching **SHOULD** be a measured decision: record hit rate and cost delta per route, and structure prompts so stable prefixes actually cache. Caching **MUST NOT** weaken region, retention, or tenant policy (`MODEL-003`); a cache that saves money by crossing a policy boundary fails.

package/skill/arch-guardian/references/architecture/ai-data-boundaries.md

@@ -2,6 +2,8 @@
 
 Apply this reference when personal data, knowledge ingestion, external model calls, or public-facing AI output exists. It concretizes `SEC-003` and `DATA-003` at the AI trust boundary: personal data moving outward, untrusted content moving inward.
 
+`PII-004` (injection quarantine) applies at every tier untrusted content reaches a prompt; `PII-001`/`PII-002` bind from production tier; `PII-003` moderation depth scales from a basic unsafe-content pass at production to full policy classes at enterprise.
+
 - **PII-001 — Ingestion redaction.** PII detection and classification **MUST** run before content enters embedding, chunking, or knowledge storage; detected PII is redacted, tokenized, or explicitly admitted under the data class policy of the target store. Record the classifier version and decision as provenance so re-scanning after a classifier upgrade is possible. Embeddings of unredacted PII are copies of it and inherit deletion propagation (`DATA-004`).
 - **PII-002 — Prompt boundary.** Before a prompt crosses the trust boundary to an external model provider, PII **MUST** be minimized to what the feature needs and stripped or masked where policy requires; the route's retention and region policy (`MODEL-001`) governs what may cross at all. Memory writes and eval/telemetry sampling are prompt-boundary crossings too — the same redaction applies.
 - **PII-003 — Output moderation.** Public-facing products **MUST** pass model output through a moderation policy before delivery: unsafe-content classes, PII leakage from context or memory, and impersonation of the platform. Internal tools MAY relax categories by declared policy, never by omission. Moderation outcomes are audited metadata; blocked output fails visibly, not silently.

package/skill/arch-guardian/references/architecture/ai-evals.md

@@ -4,6 +4,8 @@ Apply this reference only when agents, prompts, or other model-backed behavior s
 
 An eval is a versioned golden dataset plus a scoring method plus an explicit pass threshold, run against a pinned model and prompt. A demo transcript, a vibe check, or an unpinned notebook run is not an eval and produces no evidence.
 
+Minimum viable form by tier — prototype: none required. Production: one golden dataset and threshold for the main model-backed behavior, run before promoting prompt/model changes. Enterprise: the full regime below, including online sampling policy.
+
 - **EVAL-001 — Eval definition.** Every evaluated behavior **MUST** define a golden dataset with provenance and tenant-safe sourcing, a deterministic scoring method or declared judge configuration, and numeric pass/regression thresholds recorded before the run, not chosen after it.
 - **EVAL-002 — Promotion gate.** Changes to agent instructions, prompts, model policy, routed model, tool schemas, or knowledge policy **MUST** pass offline regression evals against the golden datasets before publish or promote. A threshold regression blocks promotion; overriding it is a project-owner accepted risk, not a pass.
 - **EVAL-003 — Versioned datasets.** Eval datasets, scoring configuration, and thresholds **MUST** be versioned alongside the prompts and agent versions they gate, so any historical eval result can be reproduced from its exact inputs. Dataset edits that change pass rates are behavior changes and go through the same review as prompt changes.

package/skill/arch-guardian/references/architecture/connectors-sandbox.md

@@ -17,8 +17,8 @@ Target MCP spec revision `2026-07-28`: each request declares its protocol versio
 ## Sandbox boundary
 
 - **SBX-001 — Untrusted execution.** Production untrusted code **MUST** use a provider sandbox uniquely bound to workspace, run, and trust class. Local execution is trusted-development only.
-- **SBX-002 — Credential-free sandbox.** A sandbox **MUST NOT** receive database, OpenBao, model-provider, connector-refresh, or ambient object-store credentials. Trusted broker code MAY inject an upstream credential only after validating a short-lived capability and must never return it.
-- **SBX-003 — Default-deny egress.** Egress **MUST** default deny. Trusted policy **MUST** constrain destination, method, path, headers, redirects, body, and response; discard sandbox-provided `Authorization`, cookies, and `Host` before reconstructing the request.
+- **SBX-002 — Credential-free sandbox.** A sandbox **MUST NOT** receive database, secret-store, model-provider, connector-refresh, or ambient object-store credentials. Trusted broker code MAY inject an upstream credential only after validating a short-lived capability and must never return it. [tier: all]
+- **SBX-003 — Default-deny egress.** Egress **MUST** default deny. Trusted policy **MUST** constrain destination, method, path, headers, redirects, body, and response; discard sandbox-provided `Authorization`, cookies, and `Host` before reconstructing the request. [tier: all]
 - **SBX-004 — Disposable execution.** Enforce CPU, memory, disk, process, network, output, and time quotas plus cleanup and sweeper reconciliation. Correctness and durable state **MUST NOT** depend on sandbox process or filesystem survival.
 - **SBX-005 — Provider contract.** A provider **MUST** declare isolation, lifecycle, quotas, network controls, file transfer, streaming, cleanup, region/jurisdiction, and capability stability; conformance tests determine support.
 

package/skill/arch-guardian/references/architecture/delivery-operations.md

@@ -5,8 +5,8 @@ Apply test and release boundaries only to enabled capabilities and declared depl
 - **DEL-001 — Boundary verification.** Tests **MUST** cover every applicable enabled boundary—contracts/code generation, RLS/tenant negatives, EVE replay/evals, pg-boss crash/retry, sandbox egress/secrets, web/mobile E2E, performance, restore, and dependency failure. Static sentinels never substitute for runtime qualification.
 - **DEL-002 — Compatible migrations.** Migrations **MUST** use expand, migrate, and contract: add backward-compatible schema, deploy compatible code, backfill idempotently with progress, verify, switch reads/writes, and remove only after the rollback window.
 - **DEL-003 — Migration safety.** Destructive migrations **MUST NOT** run as unreviewed application startup side effects. Estimate locks/rewrites, bound batches, verify backup/restore, expose progress, and define rollback or forward-fix.
-- **DEL-004 — Release identity.** Release artifacts **MUST** record source/lock/toolchain digests, exact dependencies, generated outputs, tests and skips, package/container digests, SBOM, provenance, signatures, migrations, profile/ADR identity, target, and rollback artifact.
-- **DEL-005 — Relevant freshness.** Refresh official evidence only for affected rules/topics. Critical security, auth, tenancy, durability, secrets, and deployment evidence **MUST** fail closed when stale or unavailable; unrelated work stays on the fast path.
+- **DEL-004 — Release identity.** Release artifacts **MUST** record source/lock/toolchain digests, exact dependencies, generated outputs, tests and skips, package/container digests, SBOM, provenance, signatures, migrations, profile/ADR identity, target, and rollback artifact. [tier: enterprise]
+- **DEL-005 — Relevant freshness.** For design reviews and recommendations leaning on pinned claims, stale or unavailable critical security, auth, tenancy, durability, secrets, and deployment evidence **MUST** be reported as not verified rather than asserted; plain questions answer from the shipped snapshot with a staleness caveat, and unrelated work stays on the fast path.
 - **DEL-006 — Honest verification.** Environment-bound replay, isolation, failover, restore, and provider tests **MUST** be reported as `NOT RUN` when not executed, with reason, risk, owner, and next action.
 
 ## Required test boundaries
@@ -27,8 +27,8 @@ CI fails on hard-rule violations, nondeterministic generated output, broken refe
 
 Roll out by profile, cell, or cohort with health gates; preserve protocol compatibility during mixed versions; drain long-running workers; and keep code/config rollback independent where schema permits.
 
-Bootstrap by creating the profile, choosing an exact hosting profile, linking exceptions, validating placement/versions, refreshing affected sources, checking generated contracts, running architecture checks, and completing threat/deployment review.
+Bootstrap by creating the slim profile, declaring the tier and hosting, validating the profile, refreshing affected sources, checking generated contracts, and completing threat/deployment review at the tier's depth.
 
-Doctor verifies Node availability, profile structure, installed-skill integrity, and deterministic static invariants. It does not prove database connectivity/extensions, source freshness, OpenBao identity, generated-contract drift, or live object/sandbox/model behavior.
+Doctor verifies Node availability, profile structure, and installed-skill integrity. It does not prove database connectivity/extensions, source freshness, secret-store identity, generated-contract drift, or live object/sandbox/model behavior.
 
-Use the bundled ADR, threat-model, service-design, and deployment-review templates when relevant. Maintain applicable runbooks and review exceptions regularly; setup scripts never create paid or cloud resources implicitly.
+Use the bundled ADR, threat-model, service-design, and deployment-review templates when relevant. Maintain incident documentation at the tier's depth and revisit recorded deviations on their declared triggers; setup scripts never create paid or cloud resources implicitly.

package/skill/arch-guardian/references/architecture/durable-execution.md

@@ -2,6 +2,8 @@
 
 Apply EVE/Workflow/AgentRun rules only when agents are enabled or observed. Apply pg-boss rules only when owned agent admission or ordinary jobs are enabled or observed. A non-agentic project does not require EVE, Workflow World, AgentRun or pg-boss.
 
+Minimum viable form by tier — prototype: agents MAY run as simple in-process loops with at-least-once effects and a named migration path to durable execution; ordinary background work MAY use plain cron/queue primitives. The `DUR-*` ownership and qualification rules bind from production tier, where crash recovery and replay become real requirements — the trigger for EVE/pg-boss is durable multi-step agent work that must survive restarts, not the presence of agents alone.
+
 ## Exclusive ownership
 
 - **DUR-001 — One workflow owner.** EVE with its compatible PostgreSQL Workflow World **MUST** exclusively own durable agent sessions, steps, waits, approvals, continuations, hooks, streams, and tool-loop state. Do not introduce a second workflow engine, tool loop, HITL store, or execution queue.
@@ -10,7 +12,7 @@ Apply EVE/Workflow/AgentRun rules only when agents are enabled or observed. Appl
 - **DUR-004 — Product record.** AgentRun **MUST** retain authoritative product/audit inputs and a cursor-versioned projection of EVE events. Projection is required behavior in a trusted long-running plane, not a required standalone deployable. It **MUST** declare its source, direction, reconciliation, and monotonic update rule; it is not replay truth.
 - **DUR-005 — Transaction boundary.** The control plane **MUST** create AgentRun and one pg-boss admission job in the same PostgreSQL transaction when possible. The job carries the deterministic admission key and AgentRun records pending/accepted audit state plus the unique EVE session reference. Use an outbox only when a transaction or database boundary prevents atomic enqueue.
 - **DUR-006 — External effects.** Every retried external effect **MUST** use an idempotency/effect fence and reconciliation. Job claiming or step replay is not proof of exactly-once external side effects.
-- **DUR-007 — Replay qualification.** Production durable execution **MUST** reproduce crash behavior before/after checkpoints and effects, completed-step replay, interrupted-step idempotency, approval persistence, wait/resume, cancellation, cursors, mixed-version migration, and PostgreSQL recovery for the exact tuple.
+- **DUR-007 — Replay qualification.** Before the production tier, durable execution **MUST** reproduce crash behavior before/after checkpoints and effects, completed-step replay, interrupted-step idempotency, approval persistence, wait/resume, cancellation, cursors, mixed-version migration, and PostgreSQL recovery for the exact tuple.
 - **DUR-008 — Tenant-qualified World.** Before shared-database production, every tenant-bearing Workflow World record and service role **MUST** satisfy `TEN-001` through `TEN-004`. A tuple that cannot preserve that boundary **MUST** fail qualification; RLS weakening, owner roles, and `BYPASSRLS` are forbidden.
 - **DUR-009 — Workflow exit contract.** Owning the workflow engine does not exempt it from provider neutrality: production durable execution **MUST** maintain an exit/migration contract naming the engine-specific constructs in use (sessions, steps, waits, approvals, hooks, streams), an exportable schema for durable session and event state, a drain/quiesce procedure, and a documented migration path with rollback to a replacement engine or major version. The contract is reviewed with the same cadence as the pinned tuple; a lock without an exit plan is accepted risk, not neutrality.
 

package/skill/arch-guardian/references/architecture/flutter.md

@@ -6,7 +6,7 @@ Apply this reference only when the `flutter` capability is enabled or Flutter co
 
 - **MOB-001 — Delegated mobile identity.** Flutter **MUST** use Better Auth OAuth 2.1/OIDC authorization code with S256 PKCE, discovery, consent, refresh rotation, and revocation. Better Auth Bearer session transport is not the mobile foundation. [BETTERAUTH-OAUTH] [APP-AUTH]
 - **MOB-002 — Generated client.** Flutter **MUST** consume the generated OpenAPI client and must not maintain parallel request/response types.
-- **MOB-003 — Local secrets.** Refresh tokens and device-bound secrets **MUST** use platform secure storage; logs, analytics, crash reports, deep links, and ordinary local databases **MUST NOT** contain them.
+- **MOB-003 — Local secrets.** Refresh tokens and device-bound secrets **MUST** use platform secure storage; logs, analytics, crash reports, deep links, and ordinary local databases **MUST NOT** contain them. [tier: all]
 - **MOB-004 — Push and link boundary.** Push payloads **MUST NOT** contain sensitive content or credentials; clients authenticate and fetch authoritative state. Universal/app links **MUST** validate scheme, host, path, state, expiry, and authenticated tenant before navigation.
 
 Organize code by Riverpod feature modules with declarative routing and online-first repositories. Expose loading, stale, error, retry, and conflict state rather than hiding network state. [FLUTTER-DOCS] [RIVERPOD-DOCS]

package/skill/arch-guardian/references/architecture/foundation.md

@@ -2,32 +2,30 @@
 
 ## Operating model
 
-VegaStack projects may be SaaS, internal/public products, platform services or shared packages; single- or multi-tenant; web-only, Flutter-enabled, agentic or non-agentic. Activate only declared or observed capabilities. Resolve decisions in this order: security/correctness; recovery; ownership; contracts; operability; delivery; optional optimization.
+VegaStack projects — internal or client — declare confirmed facts in a slim committed profile: kind, **tier**, tenancy, hosting, and the enabled capability list. The guardian is an advisor: it interviews, observes, recommends, and reviews. It never gates, and it has no exception or suppression machinery — a team that departs from a recommendation records the decision (profile note or ADR) and the guardian reports it as visible accepted risk. Review output follows the [advisory report contract](../advisory-report.md).
 
-- **FOUND-001 — Confirmed profile.** For architecture conformance checks, a project **MUST** commit a confirmed v3 `.vegastack/architecture.json` containing only applicable, confirmed facts (legacy `.yaml`-named JSON is accepted with a deprecation notice). [invariant; activation: CI/profile work; verification: structural+semantic; waiver: project ADR]
-- **FOUND-002 — Project exceptions.** A project exception **MUST** use exact rule/control/path scope and a contained accepted ADR with project owner, rationale/decision, risks, controls, verification, rollback/migration, review date or event, and foundation-deviation acknowledgement. [invariant; activation: exception declared; verification: semantic+filesystem; waiver: project ADR]
-- **FOUND-003 — Honest outcomes.** The guardian **MUST NOT** represent accepted risk as safe or foundation-compliant: report `PASS`, `FAIL`, `EXCEPTED`, and `NOT VERIFIED` exactly, and keep a rejection recommendation when warranted. [invariant; activation: every decision/review; verification: output review; waiver: project ADR]
-- **FOUND-004 — Capability alignment.** Declared capability status, ownership, versions, placement, roots and contracts **MUST** match project intent and repository evidence; removal **MUST** clean durable data, credentials, queues and contracts. [invariant; activation: capability declared/observed/removed; verification: static+semantic+runtime; waiver: project ADR]
+Tiers gate concerns, never tools:
 
-Every project architecture rule is waivable by an active project-owner ADR. A valid ADR changes a matching violation to `EXCEPTED` and may allow CI success, but it never proves safety. Invalid, expired or mismatched exceptions fail. Foundation changes and project accepted risks remain distinct.
+| Tier | Rigor floor |
+|---|---|
+| `prototype` | irreversibles only: no plaintext secrets in code, no cross-tenant access where tenancy exists, no auth bypass, reversible data decisions |
+| `production` | full correctness, security, and recovery concerns for enabled capabilities, in minimal viable form |
+| `enterprise` | adds immutable audit, supply-chain attestation, SCIM/deprovisioning depth, formal threat models, and eval/cost gates |
 
-Prefer reproduced behavior over prose and official primary sources over secondary material. Apply pinned claims to the pinned baseline; current documentation describes current capability. Source drift requests scoped review and does not automatically expire ADRs.
+Rules apply at tier `production` and above unless tagged `[tier: all]` (applies from prototype up) or `[tier: enterprise]`. Resolve decisions in this order: security/correctness; recovery; ownership; contracts; operability; delivery; optional optimization.
 
-## Ownership and portability
+- **FOUND-001 — Confirmed profile.** A project **MUST** commit a confirmed v4 `.vegastack/architecture.json` containing only confirmed facts: name, kind, tier, tenancy, hosting, and enabled capabilities (legacy names are accepted with a deprecation notice; versions live in lockfiles, never the profile). [tier: all]
+- **FOUND-003 — Honest outcomes.** The guardian **MUST NOT** represent unverified behavior as verified or accepted risk as recommended: findings follow the advisory evidence discipline, unverified claims are labeled, and a deliberate team decision the guardian disagrees with is reported as accepted risk with the reason — visibly, without suppression. [tier: all]
+- **FOUND-004 — Capability alignment.** The declared capability list **MUST** match project intent and repository evidence, and removing a capability **MUST** clean durable data, credentials, queues, and contracts. [tier: all]
 
-Product-owned enabled capabilities are the default. Shared-managed and external-managed services are explicit exceptions to ownership, not compliance exceptions; require the complete service contract in the profile. A consumer of shared EVE or another shared service does not contain the provider's source roots.
+Prefer reproduced behavior over prose and official primary sources over secondary material. Apply pinned claims to the pinned baseline; current documentation describes current capability. Source drift requests scoped review.
 
-Use PostgreSQL, REST/OpenAPI, OCI, S3-compatible objects, OpenTelemetry, OAuth/OIDC and provider-neutral sandbox/model interfaces when their capabilities apply. Provider features must not become hidden correctness dependencies.
+## Minimum viable architecture
 
-The foundation excludes billing, pricing and Stripe. Usage, quota, capacity, token, sandbox and storage accounting remain applicable when those resources exist. Add optional infrastructure only after the trigger in its reference is met.
+Never add a moving service without a named trigger. Every infra addition states the trigger it satisfies and the simpler option it replaces; every capability reference names its default and its escalation triggers. Libraries and standards with no operational cost are standing defaults when their capability applies: Better Auth, PostgreSQL, REST/OpenAPI, OCI, S3-compatible objects, OpenTelemetry, OAuth/OIDC, provider-neutral sandbox/model interfaces. Operational services are trigger-gated: OpenBao, Valkey, Kubernetes, WebSockets, regional cells, extracted services. Provider features must not become hidden correctness dependencies.
 
-## Enforcement
+## Ownership and portability
 
-| Class | Treatment |
-|---|---|
-| invariant / forbidden design | CI failure when detectable; otherwise manual qualification |
-| preferred default | warning with evidence-backed reason to vary |
-| permitted option | supported only inside declared activation and ownership boundaries |
-| valid project ADR | visible `EXCEPTED`; CI may pass; recommendation remains unmet |
+Product-owned enabled capabilities are the default. Shared-managed and external-managed services are explicit ownership exceptions recorded in the profile notes with their contract; a consumer of a shared service does not contain the provider's source roots. The foundation excludes billing, pricing, and Stripe.
 
-Choose the smallest design meeting current requirements and measured objectives. Challenge a foundation default when project evidence shows it does not fit; use an ADR to record the project decision.
+Retired rule IDs are never reused: `FOUND-002` (exception governance) was retired in foundation 0.4.0 together with the enforcement machinery.

package/skill/arch-guardian/references/architecture/hosting-reliability.md

@@ -22,7 +22,7 @@ Profile changes require an ADR, deployment review, data/secret migration, contra
 - **REL-001 — Measured objectives.** Each production profile **MUST** define measured objectives for its applicable enabled boundaries (such as API latency, admission age, EVE continuation, SSE freshness, dependency success or notification delivery), with RPO/RTO only where durable data and recovery requirements exist.
 - **REL-002 — Reproduced recovery.** Recovery plans **MUST** use encrypted PostgreSQL backups plus WAL/PITR, object versioning/replication where required, OpenBao recovery procedures, and independent restore verification. A successful backup job is not restore evidence.
 - **REL-003 — Regional ownership.** Add cells only for measured capacity, residency, or blast-radius needs. A workspace and its authoritative business/workflow state **MUST** have one home cell; moves use quiescence, copy, validation, cutover, and rollback.
-- **REL-004 — Incident ownership.** Teams **MUST** maintain owned runbooks for cross-tenant exposure, credential theft, workflow/job stalls, database loss, sandbox egress/escape, model data incidents, connector abuse, provider/cell loss, and deletion failure.
+- **REL-004 — Incident ownership.** Teams **MUST** maintain owned incident documentation at their tier's depth: production — one runbook covering the top three realistic failures for enabled capabilities (typically database loss, workflow/job stalls, credential theft); enterprise — the full set including cross-tenant exposure, sandbox egress/escape, model data incidents, connector abuse, provider/cell loss, and deletion failure.
 
 | Failure | Expected recovery evidence |
 |---|---|

package/skill/arch-guardian/references/architecture/identity-tenancy.md

@@ -6,18 +6,18 @@ Apply identity rules only to authenticated/delegated/service access that exists.
 
 - **AUTH-001 — Workspace boundary.** For authenticated multi-tenant products, Better Auth organization **MUST** be the workspace boundary. A client-supplied or session-cached active organization **MUST NOT** authorize access without current membership resolution. Projects MAY subdivide a workspace.
 - **AUTH-002 — Resource authorization.** `owner`, `admin`, and `member` are coarse membership roles; teams are grouping only. Application-owned typed resource policies and grants **MUST** be authoritative and default-deny. [BETTERAUTH-ORG]
-- **AUTH-003 — Browser sessions.** Browser authentication **MUST** use secure, HttpOnly, SameSite cookies. CSRF/origin checks **MUST NOT** be disabled; production origins **MUST** be exact HTTPS allowlists. Sensitive actions **MUST** revalidate the session and current membership against durable storage rather than trusting cookie cache. [BETTERAUTH-SESSIONS] [BETTERAUTH-SECURITY]
+- **AUTH-003 — Browser sessions.** Browser authentication **MUST** use secure, HttpOnly, SameSite cookies. CSRF/origin checks **MUST NOT** be disabled; production origins **MUST** be exact HTTPS allowlists. Sensitive actions **MUST** revalidate the session and current membership against durable storage rather than trusting cookie cache. [tier: all] [BETTERAUTH-SESSIONS] [BETTERAUTH-SECURITY]
 - **AUTH-004 — Delegated clients.** Flutter, MCP, delegated applications, and third parties **MUST** use authorization code with S256 PKCE, discovery, explicit consent, audience/resource validation, refresh rotation, revocation, and introspection. Reject `require_pkce: false`; do not use the Bearer plugin as the mobile foundation. Verify that OAuth and OIDC discovery endpoints are reachable outside framework catch-all routes. [BETTERAUTH-OAUTH]
-- **AUTH-005 — Automation and services.** Workspace API keys **MUST** be organization-owned, hashed, scoped, expiring, rate-limited, and revocable. Internal services **MUST** use short-lived audience-bound OpenBao identities, with mTLS where practical. Neither identity may synthesize a browser session. [BETTERAUTH-APIKEY] [OPENBAO-DOCS]
-- **AUTH-006 — Enterprise provisioning.** SSO and SCIM connections **MUST** be organization-scoped. Production `defaultSCIM` and plaintext SCIM token storage are forbidden. Deprovisioning **MUST** revoke sessions, memberships, grants, API keys, connector access, and support elevation. [BETTERAUTH-SSO] [BETTERAUTH-SCIM]
+- **AUTH-005 — Automation and services.** Workspace API keys **MUST** be organization-owned, hashed, scoped, expiring, rate-limited, and revocable. Internal service-to-service identity **MUST** be short-lived and audience-bound — OpenBao-issued identities with mTLS where the multi-service trigger is met, platform-issued identities otherwise. Neither identity may synthesize a browser session. [BETTERAUTH-APIKEY] [OPENBAO-DOCS]
+- **AUTH-006 — Enterprise provisioning.** SSO and SCIM connections **MUST** be organization-scoped. Production `defaultSCIM` and plaintext SCIM token storage are forbidden. Deprovisioning **MUST** revoke sessions, memberships, grants, API keys, connector access, and support elevation. [tier: enterprise] [BETTERAUTH-SSO] [BETTERAUTH-SCIM]
 - **AUTH-007 — Support elevation.** Support access **MUST** be visible, reason/ticket-bound, narrowly scoped, expiring, revocable, and immutable-audited. It **MUST NOT** impersonate a user or bypass normal RLS.
 
 ## Tenant database boundary
 
-- **TEN-001 — Composite tenant keys.** Every tenant-owned primary, unique, and foreign-key relationship **MUST** include `workspace_id`; a globally unique object ID is not tenant isolation.
-- **TEN-002 — Forced RLS.** Every tenant table **MUST** enable and force PostgreSQL RLS with fail-closed `USING` and `WITH CHECK` coverage appropriate to each command. [POSTGRES-DOCS]
-- **TEN-003 — Trusted transaction context.** Request roles **MUST** be non-owner and lack `BYPASSRLS`. Trusted server code **MUST** establish workspace, subject, and support context using `SET LOCAL` or `set_config(..., true)` inside the same explicit transaction as protected queries. Clients and pooled session state **MUST NOT** set it.
-- **TEN-004 — Privileged and batch paths.** Bulk, export, background, support, and maintenance paths **MUST** preserve tenant context. A `SECURITY DEFINER` function **MUST** use a fixed safe `search_path`, revoke public execution, validate tenant inputs, and avoid an RLS-bypassing owner.
+- **TEN-001 — Composite tenant keys.** Every tenant-owned primary, unique, and foreign-key relationship **MUST** include `workspace_id`; a globally unique object ID is not tenant isolation. [tier: all]
+- **TEN-002 — Forced RLS.** Every tenant table **MUST** enable and force PostgreSQL RLS with fail-closed `USING` and `WITH CHECK` coverage appropriate to each command. [tier: all] [POSTGRES-DOCS]
+- **TEN-003 — Trusted transaction context.** Request roles **MUST** be non-owner and lack `BYPASSRLS`. Trusted server code **MUST** establish workspace, subject, and support context using `SET LOCAL` or `set_config(..., true)` inside the same explicit transaction as protected queries. Clients and pooled session state **MUST NOT** set it. [tier: all]
+- **TEN-004 — Privileged and batch paths.** Bulk, export, background, support, and maintenance paths **MUST** preserve tenant context. A `SECURITY DEFINER` function **MUST** use a fixed safe `search_path`, revoke public execution, validate tenant inputs, and avoid an RLS-bypassing owner. [tier: all]
 
 ```mermaid
 sequenceDiagram

package/skill/arch-guardian/references/architecture/model-lifecycle.md

@@ -2,9 +2,11 @@
 
 Apply this reference only when external model providers are enabled or observed. It extends `MODEL-001` through `MODEL-003` with lifecycle, rollout, and pressure behavior; the provider-neutral adapter remains the enforcement point.
 
-- **MLIFE-001 — Explicit model pins.** Every route **MUST** pin an explicit model identifier. Floating aliases such as `latest` or provider-default snapshots are forbidden in production routes; alias resolution happens at review time, and the resolved identifier is what ships.
-- **MLIFE-002 — Deprecation watch.** The project **MUST** subscribe to deprecation and retirement notices for every pinned model and record, per model, the announced retirement date, the chosen successor, and a migration window that completes eval and cost qualification (`EVAL-002`, `COST-004`) before the provider deadline. A pinned model with a published retirement date and no successor plan is a `FAIL`, not a warning.
-- **MLIFE-003 — Canary rollout.** Prompt+model behavior changes reaching paying tenants **MUST** roll out by canary or cohort: a bounded traffic slice, pre-declared comparison metrics (eval score, error rate, latency, cost), and automatic or one-step rollback to the prior pinned pair. Pre-launch and internal-only surfaces may ship directly. Cohort assignment respects tenant policy; a tenant is never split across behavior variants within one conversation.
+Minimum viable form by tier — prototype: pin explicit model identifiers, nothing more. Production: pins plus deprecation watch and basic backpressure handling. Enterprise: the full regime including canary/cohort rollout and qualified fallback policy.
+
+- **MLIFE-001 — Explicit model pins.** Every route **MUST** pin an explicit model identifier. Floating aliases such as `latest` or provider-default snapshots are forbidden in production routes; alias resolution happens at review time, and the resolved identifier is what ships. [tier: all]
+- **MLIFE-002 — Deprecation watch.** The project **MUST** subscribe to deprecation and retirement notices for every pinned model and record, per model, the announced retirement date, the chosen successor, and a migration window that completes eval and cost qualification (`EVAL-002`, `COST-004`) before the provider deadline. A pinned model with a published retirement date and no successor plan is a critical finding, not a footnote.
+- **MLIFE-003 — Canary rollout.** Prompt+model behavior changes reaching production-tier users **MUST** roll out by canary or cohort: a bounded traffic slice, pre-declared comparison metrics (eval score, error rate, latency, cost), and automatic or one-step rollback to the prior pinned pair. Prototype and internal-only surfaces may ship directly. Cohort assignment respects tenant policy; a tenant is never split across behavior variants within one conversation.
 - **MLIFE-004 — Provider backpressure.** Provider rate limits and `429`/overload responses **MUST** be absorbed by the adapter with bounded adaptive backoff, per-tenant fairness, and admission shedding at the queue edge — reject or defer new work visibly rather than retrying into a saturated provider. Retries **MUST NOT** amplify load, and fallback routing under pressure obeys `MODEL-003` policy preservation.
 
 ## Retirement flow

package/skill/arch-guardian/references/architecture/models-observability.md

@@ -16,7 +16,7 @@ Record route decision, policy version, provider/model, key source, region, laten
 
 - **OBS-001 — Vendor-neutral telemetry.** Services **MUST** emit OpenTelemetry-compatible traces, metrics, and logs with W3C propagation and stable tenant-safe correlation. [OTEL-DOCS]
 - **OBS-002 — Metadata-only default.** Telemetry **MUST** default to metadata. Cookies, authorization headers, tokens, keys, prompts, restricted content, and unbounded tool output **MUST NOT** enter logs or traces.
-- **OBS-003 — Immutable audit.** Security and product audit events **MUST** be append-only, tenant-scoped, access-controlled, tamper-evident, retention-managed, and exportable to WORM storage where policy requires.
+- **OBS-003 — Immutable audit.** Security and product audit events **MUST** be append-only, tenant-scoped, and access-controlled; tamper evidence, managed retention, and WORM export bind at enterprise tier.
 
 Run history MAY expose inputs/outputs allowed by data policy, steps, tool calls, approvals, model decisions, usage, errors, and replay lineage. Do not store hidden chain-of-thought; retain structured reasons, decisions, and evidence references.
 

package/skill/arch-guardian/references/architecture/security-privacy.md

@@ -2,11 +2,15 @@
 
 Apply threat scenarios to enabled/exposed services and capabilities. Absence of a capability is not a missing control; observed sensitive data, secrets or execution activates the relevant boundary.
 
-- **SEC-001 — Threat model.** Every enabled/exposed service and capability **MUST** model its applicable tenant crossing, confused deputy, prompt/tool injection, SSRF, credential theft, replay, support abuse, sandbox escape/exfiltration, supply-chain, resource exhaustion, and deletion-failure scenarios.
-- **SEC-002 — Secret custody.** When production secrets exist, workspace BYOK and connector tokens **MUST** persist only as encrypted ciphertext/reference; project-owned production secret/KMS functions, service identities, rotation, revocation, and audit **MUST** use OpenBao. Plaintext secrets in code, profiles, logs, telemetry, agents, or sandboxes are forbidden. [OPENBAO-DOCS]
-- **SEC-003 — Enforced authorization.** Prompts and model instructions **MUST NOT** be treated as security controls. Typed authorization, capabilities, EVE approval gates, database RLS, egress policy, quotas, and immutable audit enforce decisions.
-- **SEC-004 — Supply chain.** Builds **MUST** use reviewed locks, registry integrity, canonical tags/commits, isolated builders, vulnerability/license review, pinned image digests, SBOM, provenance, and signatures for release artifacts.
-- **SEC-005 — Abuse controls.** Systems **MUST** apply tenant/identity/IP/risk-class quotas, payload and output limits, anomaly detection, suspension/kill switches, appeal/restore paths, and immutable administrative audit.
+- **SEC-001 — Threat model.** Every enabled/exposed service and capability **MUST** carry a threat model at its tier's depth — prototype: five bullets on the auth/tenant boundary; production: the applicable scenarios below for enabled capabilities; enterprise: the full matrix with owners and verification.
+- **SEC-002 — Secret custody.** Plaintext secrets in code, profiles, logs, telemetry, agents, or sandboxes are forbidden at every tier: production secrets, workspace BYOK, and connector tokens **MUST** persist only in a managed secret store or as encrypted ciphertext/reference, with rotation and revocation possible. [tier: all] [OPENBAO-DOCS]
+- **SEC-003 — Enforced authorization.** Prompts and model instructions **MUST NOT** be treated as security controls. Typed authorization, capabilities, EVE approval gates, database RLS, egress policy, quotas, and immutable audit enforce decisions. [tier: all]
+- **SEC-004 — Supply chain.** Builds **MUST** use reviewed locks, registry integrity, canonical tags/commits, isolated builders, vulnerability/license review, pinned image digests, SBOM, provenance, and signatures for release artifacts. [tier: enterprise]
+- **SEC-005 — Abuse controls.** Public-facing systems **MUST** apply tenant/identity/IP/risk-class quotas, payload and output limits, suspension/kill switches, appeal/restore paths, and administrative audit; anomaly detection and immutability harden this at enterprise tier.
+
+Secret-custody mechanism is chosen by trigger, not tier: the platform's or cloud's managed secret store is the default at every tier (it satisfies SEC-002 with zero operational cost). Run OpenBao only when a real trigger exists — self-hosted infrastructure, multi-service identity (short-lived service credentials/mTLS), BYOK key custody, or dynamic database credentials. An enterprise-tier app on a managed platform with none of those triggers does not need OpenBao; a production-tier self-hosted platform does. Production-tier floor: reviewed locks and pinned CI for the supply chain (full SEC-004 attestation is enterprise).
+
+Applicable threat scenarios: tenant crossing, confused deputy, prompt/tool injection, SSRF, credential theft, replay, support abuse, sandbox escape/exfiltration, supply-chain compromise, resource exhaustion, deletion failure.
 
 | Control objective | Required mechanism |
 |---|---|

package/skill/arch-guardian/references/architecture/topology-monorepo.md

@@ -42,6 +42,6 @@ Use a Bun/Turborepo workspace for JavaScript/TypeScript and Flutter orchestratio
 - **PKG-001 — Directed package graph.** Apps **MUST NOT** import another app's internals. Domain packages **MUST NOT** depend on Next.js, Flutter, UI, or provider SDKs; adapters depend on provider-neutral contracts.
 - **PKG-002 — Generated contracts.** Zod is editable API source; OpenAPI, Flutter/public clients, schema snapshots, and the packaged skill copy **MUST** be deterministic outputs with source and tool digests.
 - **PKG-003 — Dependency qualification.** Security, runtime, and durability protocol families **MUST** be pinned and upgraded atomically with compatibility, migration, replay, and rollback tests.
-- **PKG-004 — Production graph qualification.** CI **MUST** validate the install graph and every pruned production graph, public exports, dependency cycles, registry integrity, SBOM/provenance, and lockfile consistency.
+- **PKG-004 — Production graph qualification.** CI **MUST** validate the install graph and every pruned production graph, public exports, dependency cycles, and lockfile consistency; registry integrity and SBOM/provenance attestation bind at enterprise tier.
 
 Commit generated public contracts needed by consumers. [TURBO-DOCS] [BUN-DOCS]

package/skill/arch-guardian/references/architecture/web.md

@@ -22,7 +22,7 @@ Next.js 16 and the reviewed OpenNext adapter support the selected App Router req
 | validation | shared Zod contract; server authoritative |
 | optimistic update | idempotency key, rollback, authoritative reconciliation, no privilege escalation |
 
-Store UTC instants and IANA timezone identifiers. Support localized templates, pluralization, locale-aware formatting, RTL, keyboard navigation, focus management, reduced motion, and screen readers from the first implementation.
+Store UTC instants and IANA timezone identifiers from the first implementation — retrofitting time handling is expensive. Accessibility and localization scale by tier and by what the product actually targets: production — keyboard navigation, focus management, and locale-aware formatting for supported locales; enterprise or an explicitly international audience — full localization templates, pluralization, RTL, reduced motion, and screen-reader coverage.
 
 ## Extraction trigger
 

package/skill/arch-guardian/references/foundation-compatibility.json

@@ -1,6 +1,6 @@
 {
   "schemaVersion": 1,
-  "foundationVersion": "0.3.0",
+  "foundationVersion": "0.4.0",
   "baselines": {
     "vs-2026-08-07": {
       "state": "supported",

package/skill/arch-guardian/references/profile-governance.md

@@ -1,54 +1,40 @@
 # Profile and governance
 
-The v3 profile declares project facts without assuming a full-stack product. `capabilities` is authoritative intent; repository detection is evidence for drift, not a reason to silently enable anything.
+The v4 profile is slim advisor memory — roughly a dozen lines of confirmed facts. `capabilities` is authoritative intent; repository detection is evidence for drift, never a reason to silently enable anything. Versions are read from lockfiles and manifests at advice time and are never duplicated into the profile.
 
-## Capability ownership
+| Field | Meaning |
+|---|---|
+| `project.tier` | `prototype` / `production` / `enterprise` — decides which concerns apply (see foundation) |
+| `project.kind`, `tenancy` | confirmed project facts |
+| `hosting` | production hosting target (`none` for a non-deployable package) |
+| `capabilities` | enabled list: `web`, `flutter`, `agents`, `jobs`, `sandbox`, `connectors`, `knowledge`, `models`, `realtime`, `notifications`, `enterprise-identity` |
+| `notes` | free-form confirmed facts and recorded deviations |
 
-- `owned`: the project owns source, deployment, operations and migration. Enabled owned capabilities declare exact versions, placement and source roots.
-- `shared-managed`: another VegaStack owner runs the capability for this project.
-- `external-managed`: a third party runs it behind a project-approved contract.
-- `not-applicable`: use only for disabled capabilities.
+## Tier declaration
 
-Enabled shared/external capabilities declare owner/service, contract name/version, tenant/security boundary, identity/audience, data/residency, SLO/recovery dependency, incident ownership, compatibility and migration/exit behavior. They do not require provider source roots in the consumer repository.
-
-Owned durable capabilities declare concrete owners in `controls`: agents name `workflowDatabaseOwner` and `agentRunOwner`; jobs name `databaseOwner`; owned knowledge names `postgresOwner` and, when `binaryObjects` is true, `objectStorageOwner`; notifications name `durableIntentOwner`. Credential-bearing connectors/model routing set `credentialBearing: true`, and SCIM activates production secret custody. These are confirmed project facts, never generated placeholders.
-
-Never invent owner, SLO, retention, residency, compliance or version values. Missing material facts remain validation errors or `NOT VERIFIED` evidence.
+Choosing the tier is a deliberate product decision, not a guess: prototype means the team accepts that only irreversibles are guarded; production means real users depend on it; enterprise means compliance-grade posture. Raising the tier is a review event — the guardian re-reviews enabled capabilities against the new floor and reports the gap as `production-gate`/`enterprise-gate` findings, not failures.
 
 ## Capability activation
 
-Apply rules only when activated by declared intent or observed drift. Key implications:
-
-- Flutter requires delegated OAuth/OIDC code with S256 PKCE and generated REST/OpenAPI client consumption.
-- Agents require qualified EVE/Postgres World plus AgentRun.
-- Owned agent admission requires pg-boss; shared admission requires an explicit qualified contract.
-- Untrusted execution requires a sandbox and trusted capability broker.
-- SCIM requires organization mapping and complete deprovisioning.
-- Cloudflare/OpenNext plus owned agents/jobs requires external long-running Node/OCI placement.
-- Removing a capability requires a cleanup/migration plan for durable data, credentials, queues and contracts.
-- Production secrets activate OpenBao unless an explicit shared/external secrets contract is declared.
-
-## Exceptions
-
-Every project rule is waivable by the project owner. A valid exception declares an exact single rule, exact repository-relative evidence paths, project owner, rationale/decision, risks, compensating controls, verification, rollback/migration, review date or event, and acknowledgement of foundation deviation. `controls` is optional: an exception that omits it covers all controls under its single rule; one that declares control IDs suppresses only the controls it lists. Its contained ADR repeats the identity and decision.
+Apply rules only when a capability is enabled in the profile or observed in the repository, at or below the declared tier. Key implications:
 
-Static exceptions match only when rule and exact evidence path match and, when `controls` is declared, the control ID also matches. Wildcards and directory-prefix suppression are forbidden. An exception that lists controls never suppresses a finding for a control it does not list, and no exception covers a second rule. Manual exceptions declare `verificationType: manual-qualification` and remain visibly accepted risk.
+- Flutter activates delegated OAuth/PKCE and generated-client rules.
+- Agents activate durable-execution ownership rules; at prototype tier a simpler loop is acceptable with a named migration path (see durable execution).
+- Untrusted execution activates the sandbox boundary.
+- Shared-schema multi-tenancy activates `TEN-*` at every tier.
+- Production secrets activate secret-custody guidance — the mechanism is tier- and trigger-dependent (see security and privacy), never automatically OpenBao.
+- Removing a capability requires a cleanup/migration plan for durable data, credentials, queues, and contracts.
 
-Outcome semantics:
+## Deviations
 
-| Outcome | Meaning | CI |
-|---|---|---|
-| `PASS` | recommendation satisfied | pass |
-| `FAIL` | violation or invalid/expired/mismatched exception | fail |
-| `EXCEPTED` | valid active project-owner accepted risk; recommendation remains unmet | pass |
-| `NOT VERIFIED` | environment behavior not reproduced; reason/risk/owner/next action required | configurable warning |
+There is no exception or suppression machinery. When the team deliberately departs from a recommendation:
 
-The guardian may still state `GUARDIAN VERDICT: REJECT` when an accepted risk is unsafe. Foundation evolution changes the recommended baseline; project exceptions remain distinguishable and do not silently expire on source drift.
+1. Record it — one line in `notes` for small departures; an ADR ([template](../assets/adr-template.md)) for consequential ones (owner, decision, revisit trigger).
+2. The guardian keeps reporting it in reviews as `accepted risk — guardian recommends revisiting`, with the reason. Recording a decision makes it visible and deliberate; it never silences the advisor and nothing gates on it.
 
 ## Governance operations
 
-- Evidence labels are optional; they are reserved for review and drift reports and never affect exception matching.
-- Drift PRs from the automated source refresh are reviewed by whoever merges them; drift policy has no per-topic owners.
-- Source staleness thresholds are a minimum of 14 days, aligned to the weekly automated refresh; shorter thresholds only produce false staleness between refreshes.
-- Profiles pin the foundation version (currently `0.3.0`); it is decoupled from the installer npm package version, so installer upgrades never change a project's pinned foundation.
-- `DUR-007`-style full qualification matrices are required before the first paying tenant, not before every merge; interim merges record `NOT VERIFIED` with reason, owner, and next action.
+- Drift PRs from the automated source refresh are reviewed by whoever merges them.
+- Source staleness thresholds are a minimum of 14 days, aligned to the weekly automated refresh.
+- Profiles may pin `foundationVersion` (currently `0.4.0`); it is decoupled from the installer npm package version, so installer upgrades never change a project's pinned foundation.
+- Full qualification matrices (e.g. `DUR-007`) are required before the production tier, not before every merge; interim reviews record the gap under `notVerified`.

package/skill/arch-guardian/references/rule-model.json

@@ -1,8 +1,8 @@
 {
   "schemaVersion": 1,
-  "defaults": { "classification": "invariant", "waiver": "project-owner-adr", "authority": "canonical prose in references/architecture" },
+  "defaults": { "classification": "invariant", "tierFloor": "production", "authority": "canonical prose in references/architecture; tier tags on rule lines override the default floor" },
   "groups": [
-    { "rules": ["FOUND-001", "FOUND-002", "FOUND-003", "FOUND-004"], "activation": "profile, governance, or any guardian output", "verification": "structural, semantic, output review", "rationale": "Keep project facts, accepted risk, and capability applicability honest." },
+    { "rules": ["FOUND-001", "FOUND-003", "FOUND-004"], "activation": "profile, governance, or any guardian output", "verification": "structural, semantic, output review", "rationale": "Keep project facts, accepted risk, and capability applicability honest." },
     { "rules": ["API-001", "API-002", "API-003", "API-004", "WEB-001"], "activation": "web control plane or public/generated API enabled or observed", "verification": "static, generated-contract, runtime", "rationale": "Keep one portable control-plane contract and safe request boundary." },
     { "rules": ["MOB-001", "MOB-002", "MOB-003", "MOB-004"], "activation": "Flutter enabled or observed", "verification": "semantic, generated-contract, mobile runtime", "rationale": "Keep delegated mobile identity, wire contracts, local secrets, push, and links safe." },
     { "rules": ["AUTH-001", "AUTH-002", "AUTH-003", "AUTH-004", "AUTH-005", "AUTH-006", "AUTH-007"], "activation": "the corresponding authenticated, delegated, service, enterprise, or support access exists", "verification": "static, semantic, identity integration", "rationale": "Bind identity and authorization to current durable project state." },

package/skill/arch-guardian/references/workflows.md

@@ -4,13 +4,13 @@
 
 Discover confirmed facts before recommending. Ask no more than three material questions at once and branch only when an answer activates a topic:
 
-1. Product objective, users, lifecycle stage, access and tenancy mode.
+1. Product objective, users, lifecycle stage, access, tenancy mode — and the **tier** (prototype / production / enterprise), a deliberate choice the user confirms.
 2. Clients: web, Flutter, public API, connectors or channels.
 3. Agents, automation, ordinary jobs, untrusted execution and external effects.
-4. Data classes, residency, retention, deletion, RPO/RTO and availability/latency objectives.
+4. Data classes, residency, retention, deletion, RPO/RTO and availability/latency objectives (production tier and above).
 5. Hosting/self-hosting, workload/growth, team/on-call/cost, milestone, and deferrable choices.
 
-If facts are unavailable, name bounded assumptions and choose the simplest applicable default. Recommend one capability set and topology. For each enabled capability state ownership, boundary, contract, placement, immediate/deferred decisions, risks, implementation order and qualification evidence. Offer a profile/artifact draft; write only after confirmation.
+If facts are unavailable, name bounded assumptions and choose the simplest applicable default. Recommend one capability set and topology sized by the minimum-viable-architecture principle: every proposed moving service names the trigger that justifies it, and every deferred one names the trigger that would. State immediate and deferred decisions, risks, implementation order, and what evidence would qualify the design at the declared tier. Offer a slim profile draft; write only after confirmation.
 
 ## Brownfield
 
@@ -20,26 +20,29 @@ Separate:
 
 - current observed state;
 - intended state from committed artifacts;
-- target recommendation;
+- target recommendation at the declared tier;
 - immediate security/correctness risks;
 - required migrations and rollback;
 - optional improvements;
-- runtime evidence that is `NOT VERIFIED`.
+- runtime evidence that is not verified.
 
 Prefer incremental migration with compatibility windows and rollback over needless rewrites. Never convert detection heuristics into claims of absence or compliance.
 
+## Reviews
+
+Identify the decision scope, gather evidence (read the relevant files; use the evidence recipes in the [advisory report contract](advisory-report.md)), and produce an advisory report: per-area grades, severity-ranked findings with evidence, questions, and not-verified items. Findings above the project's tier report as that tier's gate, not as defects.
+
 ## Other lifecycle tasks
 
-For questions and explanations, answer directly: the verdict if there is one, the recommendation, and at most one material risk. The full eight-part response contract applies only to design reviews, ADRs, and migration plans — not to questions, explanations, or short follow-ups.
+For questions and explanations, answer directly: the recommendation and at most one material risk. The full response contract applies only to design reviews, ADRs, and migration plans.
 
 - **Explanation:** answer the decision directly; load only references needed to explain it.
-- **Review:** identify decision scope, run applicable checks, and prioritize actionable findings.
-- **ADR:** distinguish a foundation change from project accepted risk; record exact control/path scope.
-- **Threat model:** model only enabled/exposed surfaces and their trust boundaries.
-- **Deployment:** compare declared production target with deployables, data, secrets, SLO/recovery and rollback.
-- **Source drift:** refresh affected entries only; qualification state changes only through review.
+- **ADR:** a decision record, not a waiver — capture owner, decision, alternatives, risks, and revisit trigger.
+- **Threat model:** model only enabled/exposed surfaces and their trust boundaries, at the tier's depth.
+- **Deployment:** compare declared hosting with deployables, data, secrets, recovery and rollback.
+- **Source drift:** refresh affected entries only; recommendations change only through review.
 - **Migration/removal:** distinguish current/target state, preserve compatibility, and clean durable data, credentials, queues and contracts.
 
 ## Decision horizons
 
-Sequence work as: irreversible security/data/identity boundaries; contracts and durable ownership; deployable placement and recovery; delivery scaffolding; measured optimization. Every phase names owner, verification, rollback and any ADR action.
+Sequence work as: irreversible security/data/identity boundaries; contracts and durable ownership; deployable placement and recovery; delivery scaffolding; measured optimization. Every phase names owner, verification, rollback and any decision record to update.

package/skill/arch-guardian/refresh/REFRESH.md

@@ -14,12 +14,14 @@ Instructions for the scheduled refresh agent (and any human running a manual ref
 
 1. **Deterministic pass first** (no LLM judgment):
    `node scripts/refresh-evidence.mjs --registry refresh/sources.json`
-   drift/version-drift/stale/unavailable results are the work-list. Exit 1 with a critical entry means fail-closed: the run must not be silently skipped.
+   drift/version-drift/stale/unavailable results are the work-list. Exit 1 with a critical entry means fail-closed: the run must not be silently skipped. The same pass also:
+   - queries OSV.dev for every pinned npm/PyPI package (`advisories` in the report; an advisory against a critical source's pin fails closed — the remediation is a human pin-bump decision, never silence);
+   - warns when a `reviewBy` date in `references/foundation-compatibility.json` has passed (`reviewOverdue`) — the baseline-adoption decision is overdue, and the warning repeats every run until a human makes it.
 2. **Accept verified changes** in the same code path:
    `node scripts/refresh-evidence.mjs --registry refresh/sources.json --accept-baselines`
    This writes registry, cache, and drift report together — never hand-edit checksums, versions, or timestamps; they must always come from a run.
 3. **Semantic verification** only for sources the deterministic pass flagged: read the changed source (WebFetch the registry URLs), decide whether any `<!-- source: X -->` marked sentence or compatibility pin is now wrong, and propose the minimal edit.
-4. **One PR per refresh**, branch `refresh/<date>`, force-updating the standing refresh branch if last week's PR is unmerged (never stack duplicate PRs). PR body lists: each changed source, old→new version/checksum, links to the evidence, and which marked sentences changed and why.
+4. **One standing refresh PR**, branch `refresh/weekly`, force-updated on every run (never stacked duplicates; the weekly workflow .github/workflows/refresh.yml maintains it). PR body lists: each changed source, old→new version/checksum, links to the evidence, and which marked sentences changed and why.
 5. Changes to durable rules, scripts, SKILL.md, assets, or tests are out of scope for a refresh PR — CI enforces this (refresh-guard workflow).
 
 ## Cadence and thresholds
@@ -31,6 +33,11 @@ Weekly scheduled run. Every `thresholdDays` in `sources.json` is ≥ 14 (2× cad
 - A pinned package/spec version changed (npm/pypi detection) → update `currentVersion`; if the supported baseline should move, that is a **separate human decision**, flagged in the PR body, never auto-applied to `foundation-compatibility.json` families.
 - A doc page's text-scope checksum changed → read the page; if the mechanism a marked sentence names changed, propose the sentence edit; if it is editorial churn, accept the baseline silently. Known per-request-churn sources (Google properties: `FCM-DOCS`, `GOOGLE-MODELS`) drift on nearly every fetch — their checksum drift alone is never a semantic signal; rely on their version/manual review instead.
 - A critical source is unavailable or a redirect leaves the approved host set → investigate immediately; host changes require a deliberate `approvedHosts` update in `scripts/refresh-evidence.mjs` (out of refresh-PR scope — open an issue).
+- An OSV advisory against a pinned package → propose the pin bump (with its qualification implications) in the PR body; never drop the advisory from the report.
+
+## Research index
+
+Registry entries carry an optional `llms` URL (the vendor's published `llms.txt`) alongside `docsIndex`. Agents answering questions that need current detail beyond a pinned claim should fetch the source's `llms` or `docsIndex` URL (or use an available docs MCP) — the registry doubles as the live research index, not just freshness metadata.
 
 ## Never