@vegastack/skills 0.5.0 → 0.6.0

package/skill/arch-guardian/references/architecture/realtime-channels.md

@@ -1,16 +0,0 @@
-# Realtime and channels
-
-Apply realtime, notification and external-channel rules independently when each capability is enabled or observed.
-
-- **RT-001 — Resumable output.** Resumable SSE **MUST** be the default for run output and server-to-client events. Events need tenant and run identity, monotonic cursor/event ID, type/schema version, timestamp, trace correlation, and replay/terminal reconciliation.
-- **RT-002 — WebSocket trigger.** WebSockets MAY be added only for true bidirectional collaboration or presence; they **MUST NOT** become durable state or the default agent-output transport.
-- **RT-003 — Event ownership.** Every event type **MUST** name one authoritative producer, allowed consumers, ordering scope, dedupe key, retention, authorization, and redaction policy.
-- **RT-004 — Channel boundary.** Slack, Teams, Gmail, Outlook, and public API adapters **MUST** normalize identity, workspace mapping, consent, dedupe, threading, attachments, rate limits, retries, and revocation. They **MUST NOT** own workflow state.
-- **RT-005 — Notification intent.** In-app, email, FCM, and APNs delivery **MUST** originate from one durable tenant-scoped notification intent with channel attempts, preferences, locale, timezone, quiet hours, dedupe, receipt, and audit state.
-- **RT-006 — Channel admission.** Channel ingress **MUST** authenticate the provider, derive tenancy from server-owned mappings, enforce replay/dedupe, and durably admit before acknowledging work that can outlive the request.
-
-Interactive reconnect sends the last acknowledged cursor; the server replays authorized retained events or returns a snapshot/terminal result when replay is unavailable. Slow consumers need bounded buffers, backpressure, cancellation, and visible truncation.
-
-Create notification intent in the same transaction as the business event when possible; use an outbox only across a transaction/database boundary. Push payloads remain non-sensitive hints and clients fetch authoritative state.
-
-Add collaboration/presence infrastructure only after a bidirectional requirement and ordering scope are explicit; agent streaming alone is not a trigger.

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

@@ -1,27 +0,0 @@
-# Security and privacy
-
-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** 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 |
-|---|---|
-| tenant isolation | `TEN-001` through `TEN-004`, typed grants, negative tests |
-| least privilege | `AUTH-002`, `CONN-001`, short-lived service identities |
-| untrusted execution | `SBX-001` through `SBX-005` |
-| confidentiality | `SEC-002`, `MODEL-002`, `OBS-002`, encryption and redaction |
-| durable accountability | EVE checkpoints, AgentRun projection, `OBS-003` |
-| privacy lifecycle | `DATA-004`, export/deletion reconciliation, legal-hold scope |
-| recovery | qualified backups, PITR, restore and incident drills |
-
-Map evidence to applicable SOC 2 security/availability/confidentiality/privacy criteria and GDPR principles, lawful basis, data-subject rights, processor/subprocessor duties, breach response, transfers, and retention. This mapping supports control design; it is not a certification or legal conclusion.
-
-Threat and deployment reviews identify detection, containment, evidence preservation, recovery, communication, owner, and verification for every material scenario.

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

@@ -1,47 +0,0 @@
-# Topology and monorepo
-
-The topology is composable. Include only enabled project-owned capabilities; shared/external providers sit behind declared contracts and need no consumer source root.
-
-## Runtime ownership
-
-- **RUN-001 — EVE placement.** EVE **MUST** run as a separate officially supported long-running Node/OCI service and **MUST NOT** run inside an OpenNext Worker or request-lifetime function. Pinned `eve@0.29.5` requires Node 24+, and its PostgreSQL Workflow World needs a long-lived worker. [EVE-PINNED] [WORKFLOW-PG]
-- **RUN-002 — Job placement.** pg-boss workers **MUST** run in a separate supported Node/OCI placement, never inside the OpenNext request bundle.
-- **RUN-003 — Explicit provider boundary.** Provider-specific compute, storage, model, and sandbox behavior **MUST** remain behind declared adapters and hosting profiles.
-- **RUN-004 — Runtime qualification.** Bun compatibility **MUST NOT** be treated as proof that a deployable is supported on Node, Workers, Flutter, or another production runtime.
-
-```mermaid
-flowchart LR
-  Client["Web, Flutter, channels"] --> Next["Next.js control plane"]
-  Next --> PG["PostgreSQL system of record"]
-  Next --> Boss["pg-boss admission and jobs"]
-  Boss --> Eve["EVE long-running Node service"]
-  Eve --> World["PostgreSQL Workflow World"]
-  Eve --> Broker["Trusted capability broker"]
-  Broker --> Sandbox["Untrusted sandbox"]
-  Eve --> Model["Model adapter"]
-  Eve --> Objects["S3-compatible objects"]
-  OpenBao["OpenBao"] --> Next
-  OpenBao --> Eve
-```
-
-| Component | Owns | Must not own |
-|---|---|---|
-| Next.js | UI, RSC, Route Handlers, Better Auth, REST/OpenAPI, admission transaction | long-running execution |
-| pg-boss | transactional admission and ordinary jobs | EVE sessions, steps, waits, approvals, hooks, or streams |
-| EVE + Postgres World | durable agent execution state | business admission/fairness queue |
-| AgentRun | product/audit inputs and execution projection | workflow replay internals |
-| sandbox broker/provider | isolated execution and scoped capabilities | database, OpenBao, or provider credentials |
-| PostgreSQL | business truth, jobs, Workflow World, FTS/vector metadata | binary object payloads |
-
-OpenNext supports the selected Next.js request surface, but Workers provides only a subset of Node APIs; `nodejs_compat` is not a general Node process. [OPENNEXT-1202] [CF-WORKERS]
-
-## Workspace and packages
-
-Use a Bun/Turborepo workspace for JavaScript/TypeScript and Flutter orchestration. Production deployables use their supported runtimes.
-
-- **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, 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

@@ -1,29 +0,0 @@
-# Web control plane
-
-Apply this reference only when the owned `webControlPlane` capability is enabled or Next.js control-plane code is observed. A public API, shared package, or non-web platform service does not imply Next.js; review its declared provider-neutral contract and runtime separately.
-
-## Ownership and contract
-
-- **API-001 — Control-plane owner.** Next.js 16 App Router **MUST** initially own the web UI, RSC, Route Handlers, Better Auth, and canonical REST/OpenAPI control-plane API. Do not add NestJS or Hono without an extraction ADR.
-- **API-002 — Canonical API.** Bounded Zod schemas **MUST** deterministically generate OpenAPI and Flutter/public clients. Parallel hand-written wire contracts are forbidden.
-- **API-003 — Protected request order.** A protected request **MUST** authenticate, derive workspace membership server-side, authorize the typed action, set tenant context inside the protected transaction, execute the query, and emit an audit correlation ID.
-- **API-004 — Tenant-safe caching.** Auth, session, authorization, membership, audit, and tenant-sensitive reads **MUST NOT** use implicit or stale caches.
-- **WEB-001 — Design authority.** Web components, tokens, integrity, accessibility, and upgrade guidance **MUST** come from VegaStack Design skills/packages; this guardian must not duplicate them.
-
-Next.js 16 and the reviewed OpenNext adapter support the selected App Router request features, but the OpenNext Worker is not an Edge-runtime or general-Node replacement. [NEXT-1630] [OPENNEXT-1202]
-
-## Rendering and state
-
-| Concern | Default |
-|---|---|
-| initial authenticated read | RSC with server-derived tenant context |
-| interaction, mutation, reconnect | TanStack Query over typed REST |
-| durable run output | resumable SSE with cursor and terminal reconciliation |
-| validation | shared Zod contract; server authoritative |
-| optimistic update | idempotency key, rollback, authoritative reconciliation, no privilege escalation |
-
-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
-
-Extract an API service only for a measured independent security, runtime, scaling, or deployment boundary after query/cache work cannot meet the SLO. Framework preference and anticipated scale are not triggers. Preserve REST/OpenAPI and one implementation of authorization, schema, and business rules through extraction.

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

@@ -1,44 +0,0 @@
-{
-  "schemaVersion": 1,
-  "foundationVersion": "0.4.0",
-  "baselines": {
-    "vs-2026-08-07": {
-      "state": "supported",
-      "reviewBy": "2026-11-07",
-      "families": {
-        "web": { "next": "16.3.0", "node": "24.18.0", "bun": "1.3.14" },
-        "cloudflare-opennext": { "openNext": "1.20.2" },
-        "agents": { "eve": "0.29.5", "workflowWorldContract": "5.0.0-beta.23", "workflowLocal": "5.0.0-beta.32", "workflowPostgres": "5.0.0-beta.30", "node": "24.18.0" },
-        "jobs": { "pgBoss": "12.27.0", "postgres": "17.10" },
-        "identity": { "betterAuth": "1.6.26" },
-        "sandbox-cloudflare": { "cloudflareSandbox": "0.12.4" }
-      }
-    },
-    "candidate": {
-      "state": "candidate",
-      "qualificationRequired": true,
-      "reviewBy": "2026-09-07",
-      "families": {},
-      "observedVersions": { "eve": "0.31.2", "workflowPostgres": "5.0.0-beta.32", "postgres": "18.4" },
-      "qualificationBlockers": ["complete compatible Workflow protocol family not established", "migration/replay/rollback qualification not run", "PostgreSQL 18 major not qualified against RLS/pgvector/pg-boss workloads"]
-    },
-    "vs-2026-05-01": {
-      "state": "deprecated",
-      "reviewBy": "2026-09-01",
-      "removalBy": "2026-12-01",
-      "families": {}
-    }
-  },
-  "policy": {
-    "exactProjectVersions": true,
-    "atomicFamilies": ["agents"],
-    "lagOrAdvanceRequiresProjectAdr": true
-  },
-  "sourceDrift": {
-    "observedAt": "2026-08-08T00:00:00.000Z",
-    "status": "qualification-required",
-    "criticalSources": ["EVE-PINNED", "WORKFLOW-PG", "PGBOSS-1227", "NEXT-1630", "OPENNEXT-1202", "CF-WORKERS", "CF-SANDBOX", "HYPERDRIVE", "AI-GATEWAY", "MODAL-SANDBOX", "BETTERAUTH-OAUTH", "BETTERAUTH-ORG", "BETTERAUTH-SESSIONS", "BETTERAUTH-SSO", "BETTERAUTH-SCIM", "BETTERAUTH-APIKEY", "BETTERAUTH-SECURITY", "APP-AUTH", "POSTGRES-DOCS", "OPENBAO-DOCS", "MCP-SPEC"],
-    "registry": "refresh/sources.json",
-    "disposition": "criticalSources mirrors every critical:true entry in refresh/sources.json (kept in sync by refresh runs); keep the supported tuple pinned; review affected rules and qualify the candidate before changing the supported baseline. Existing project ADRs remain active until their own review trigger."
-  }
-}

package/skill/arch-guardian/references/golden-patterns.md

@@ -1,43 +0,0 @@
-# Golden implementation patterns
-
-Use these as concise boundary shapes, not copy-paste frameworks.
-
-## Protected request and transaction-local RLS
-
-Authenticate → resolve current membership server-side → authorize typed action → begin transaction → `SET LOCAL`/`set_config(..., true)` workspace, subject and support context → query with composite tenant key → append audit correlation → commit. Request roles are non-owner and never `BYPASSRLS`.
-
-## AgentRun and transactional admission
-
-In one PostgreSQL transaction, create `AgentRun` plus one pg-boss admission job keyed by `(workspace_id, admission_key)`. Use an outbox only across a real database/transaction boundary. The trusted EVE projection, not the admission worker, advances terminal state.
-
-## Lost acknowledgement recovery
-
-On uncertain EVE start acknowledgement, look up the session by the deterministic admission key before retry. Resume the same logical session; never create a second run.
-
-## Effect fence and reconciliation
-
-Persist a tenant-scoped effect key and intended operation before a retried external effect. Reuse the key, record provider outcome, and reconcile unknown results before retrying.
-
-## Capability envelope and credential broker
-
-Issue a short-lived capability bound to audience, workspace, resource, action, data/risk class and approval. A trusted broker validates it, reconstructs an allowlisted request and injects a credential; agents and sandboxes never receive ambient or refresh credentials.
-
-## Safe connector HTTP and redirects
-
-Bound method, ports, path, body, response and time. Resolve and validate DNS against the actual connection; reject private, loopback, link-local, metadata and multicast targets at every redirect; strip cross-origin credentials and re-authorize each hop.
-
-## Resumable SSE
-
-Emit tenant/run identity, monotonic cursor, event and schema version, timestamp and trace correlation. Reconnect with last acknowledged cursor; replay authorized retained events or return a snapshot/terminal result. Bound buffers and expose truncation.
-
-## Deterministic contracts
-
-Treat bounded Zod schemas as editable wire source. Generate OpenAPI, Flutter/public clients and snapshots with pinned tools, canonical ordering and digests. CI regenerates and fails on drift.
-
-## Deletion propagation
-
-Create a durable deletion intent, enumerate PostgreSQL, objects, indexes/vectors, caches, telemetry and connector copies, track each outcome, retry safely, honor scoped legal holds and reconcile to completion.
-
-## Support-session authorization
-
-Create visible, reason/ticket-bound, expiring and revocable support elevation. Authorize each action through normal typed policy and tenant RLS; append immutable audit. Never impersonate a user or grant `BYPASSRLS`.

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

@@ -1,40 +0,0 @@
-# Profile and governance
-
-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.
-
-| 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 |
-
-## Tier declaration
-
-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 a capability is enabled in the profile or observed in the repository, at or below the declared tier. Key implications:
-
-- 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.
-
-## Deviations
-
-There is no exception or suppression machinery. When the team deliberately departs from a recommendation:
-
-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
-
-- 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,36 +0,0 @@
-{
-  "schemaVersion": 1,
-  "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-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." },
-    { "rules": ["TEN-001", "TEN-002", "TEN-003", "TEN-004"], "activation": "shared-schema multi-tenancy enabled or tenant context observed", "verification": "SQL static analysis and negative runtime tests", "rationale": "Prevent cross-tenant access through keys, policies, roles, and privileged paths." },
-    { "rules": ["AGENT-001", "AGENT-002", "AGENT-003", "AGENT-004"], "activation": "agent authoring/publication enabled or observed", "verification": "compiler determinism, schema, eval and publication tests", "rationale": "Make published agent behavior immutable, pinned and reviewable." },
-    { "rules": ["DUR-001", "DUR-002", "DUR-003", "DUR-004", "DUR-005", "DUR-006", "DUR-007", "DUR-008", "DUR-009"], "activation": "agents, agent admission, jobs, retried effects, or shared tenant Workflow World as specified", "verification": "static, semantic, crash/replay/reconciliation", "rationale": "Give each durable state class one owner and qualify recovery, tenancy, and engine exit safely." },
-    { "rules": ["CONN-001", "CONN-002", "CONN-003", "CONN-004", "CONN-005"], "activation": "connector, MCP or webhook enabled or observed", "verification": "static, SSRF/replay/credential integration", "rationale": "Constrain external capabilities, identity and side effects at the trust boundary." },
-    { "rules": ["SBX-001", "SBX-002", "SBX-003", "SBX-004", "SBX-005"], "activation": "untrusted execution or sandbox enabled or observed", "verification": "semantic and live isolation/egress/cleanup tests", "rationale": "Keep untrusted execution disposable, credential-free and policy-brokered." },
-    { "rules": ["DATA-001", "DATA-002", "DATA-003", "DATA-004", "DATA-005"], "activation": "corresponding business, knowledge, memory, object, or lifecycle data exists", "verification": "schema, authorization, deletion, object security and recovery tests", "rationale": "Keep authoritative data, derived state and lifecycle ownership explicit." },
-    { "rules": ["RT-001", "RT-002", "RT-003", "RT-004", "RT-005", "RT-006"], "activation": "corresponding realtime, channel, or notification capability exists", "verification": "protocol, ingress, reconnect, dedupe and delivery tests", "rationale": "Separate ephemeral transport from durable event and notification ownership." },
-    { "rules": ["MODEL-001", "MODEL-002", "MODEL-003"], "activation": "model routing or BYOK enabled or observed", "verification": "route policy, credential and fallback integration", "rationale": "Preserve tenant, region, retention and key-source policy across model routes." },
-    { "rules": ["OBS-001", "OBS-002", "OBS-003"], "activation": "telemetry or audit surface exists", "verification": "static redaction and telemetry/audit integration", "rationale": "Provide useful evidence without leaking sensitive content." },
-    { "rules": ["SEC-001", "SEC-002", "SEC-003", "SEC-004", "SEC-005"], "activation": "the corresponding exposed capability, secret, authorization, build or abuse surface exists", "verification": "threat model, static, security integration", "rationale": "Enforce security in typed/runtime boundaries rather than prompts or assumptions." },
-    { "rules": ["RUN-001", "RUN-002", "RUN-003", "RUN-004"], "activation": "corresponding owned deployable/provider boundary exists", "verification": "source graph, bundle and runtime qualification", "rationale": "Keep runtimes inside supported ownership and trust boundaries." },
-    { "rules": ["PKG-001", "PKG-002", "PKG-003", "PKG-004"], "activation": "package graph, generated contract, version family, or production deployable exists", "verification": "graph, deterministic generation, compatibility/replay", "rationale": "Keep packages directed, production graphs verified, and protocol families atomically qualified." },
-    { "rules": ["HOST-001", "HOST-002", "HOST-003", "HOST-004"], "activation": "production deployable uses the corresponding hosting profile", "verification": "semantic, bundle and deployment qualification", "rationale": "Make runtime placement and provider limitations explicit." },
-    { "rules": ["REL-001", "REL-002", "REL-003", "REL-004"], "activation": "applicable production objective, durable data, region/cell, or incident surface exists", "verification": "declared objective and live recovery/incident drill", "rationale": "Tie architecture to measured service and recovery behavior." },
-    { "rules": ["DEL-001", "DEL-002", "DEL-003", "DEL-004", "DEL-005", "DEL-006"], "activation": "corresponding enabled capability, migration, release, source decision, or environment test exists", "verification": "CI, migration, release and evidence checks", "rationale": "Deliver changes compatibly and report only evidence actually reproduced." },
-    { "rules": ["EVAL-001", "EVAL-002", "EVAL-003", "EVAL-004"], "activation": "agents, prompts, or model-backed behavior shipped to users", "verification": "eval regression, dataset versioning, sampling policy review", "rationale": "Gate agent, prompt, and model changes on reproduced evaluation evidence." },
-    { "rules": ["MLIFE-001", "MLIFE-002", "MLIFE-003", "MLIFE-004"], "activation": "external model providers enabled or observed", "verification": "route policy, deprecation tracking, canary and pressure qualification", "rationale": "Keep model choice explicit and migratable and behavior stable under provider change and load." },
-    { "rules": ["COST-001", "COST-002", "COST-003", "COST-004"], "activation": "metered AI, sandbox, or knowledge-processing resources exist", "verification": "attribution, budget, and cost-regression checks", "rationale": "Treat AI spend as an owned architectural resource with attribution, budgets, and deploy gates." },
-    { "rules": ["PII-001", "PII-002", "PII-003", "PII-004"], "activation": "personal data, knowledge ingestion, external model calls, or public AI output exists", "verification": "redaction, moderation, and injection-mitigation review", "rationale": "Keep personal data and untrusted content controlled across AI trust boundaries." }
-  ],
-  "overrides": [
-    { "rule": "RT-002", "classification": "preferred-default", "permittedOption": "WebSockets for an explicit bidirectional collaboration/presence requirement; durable-state and default-transport misuse is enforced under DUR-001 and RT-001" },
-    { "rule": "HOST-002", "classification": "preferred-default", "permittedOption": "A different qualified self-host topology through project ADR" },
-    { "rule": "DATA-002", "classification": "preferred-default", "permittedOption": "A qualified external/shared knowledge service through declared ownership contract" },
-    { "rule": "MLIFE-003", "classification": "preferred-default", "permittedOption": "Direct rollout for a low-risk change with eval pass and one-step rollback" },
-    { "rule": "COST-003", "classification": "preferred-default", "permittedOption": "No prompt/context caching until a measured benefit exists" }
-  ]
-}

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

@@ -1,48 +0,0 @@
-# Adaptive workflows
-
-## Greenfield
-
-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, 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 (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 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
-
-Before asking, inspect repository instructions, manifests and locks, deployables, package graph, schemas/migrations, identity, APIs/generated clients, jobs/workflows, infra/deployment, ADRs, telemetry and runbooks. Run `profile-tool.mjs inspect` for an observed read-only draft.
-
-Separate:
-
-- current observed state;
-- intended state from committed artifacts;
-- target recommendation at the declared tier;
-- immediate security/correctness risks;
-- required migrations and rollback;
-- optional improvements;
-- 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 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.
-- **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 decision record to update.

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

@@ -1,47 +0,0 @@
-# Refresh contract — arch-guardian
-
-Instructions for the scheduled refresh agent (and any human running a manual refresh). This file, together with `sources.json`, is the complete freshness contract for this skill.
-
-## What this skill claims
-
-- **Durable rules** (`references/architecture/*.md`, `references/*.md|json`): versionless principles. The refresh agent NEVER edits these. If a source change invalidates a durable rule, open an issue titled `drift: <rule-id>` quoting the evidence — do not edit.
-- **Mechanism-coupled claims**: sentences marked `<!-- source: SOURCE-ID -->` inside references. Durable intent expressed through vendor-named mechanisms (e.g. Better Auth option names, sandbox egress API, MCP negotiation). The agent may propose edits to these marked sentences ONLY, in the same PR as the registry update that evidences the change.
-- **Volatile layer** (the only files the agent edits freely):
-  - `refresh/sources.json` — the source registry and publish-time staleness snapshot (checksums, versions, retrieval times).
-  - `references/foundation-compatibility.json` — pinned baselines and the criticalSources mirror.
-
-## How to refresh
-
-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. 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 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
-
-Weekly scheduled run. Every `thresholdDays` in `sources.json` is ≥ 14 (2× cadence) so one missed run never breaches a threshold. Sources that would genuinely need faster tracking get a daily deterministic-only version check, not a lower threshold.
-
-## What counts as drift worth a PR
-
-- 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
-
-- Never edit rule IDs, MUST/SHOULD wording, or unmarked sentences.
-- Never expire, edit, or reference project ADRs — drift requests review; it never silently expires an ADR.
-- Never hand-write checksum/version/timestamp values.
-- Never archive third-party documentation bodies in this repo (claim metadata, URLs, hashes, and concise excerpts only).