@vegastack/skills 0.4.0 → 0.6.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +4 -2
- package/dist/index.js +38 -45
- package/package.json +1 -1
- package/skill/architect/SKILL.md +68 -0
- package/skill/architect/agents/openai.yaml +4 -0
- package/skill/architect/assets/adr-template.md +21 -0
- package/skill/architect/assets/arch-template.md +20 -0
- package/skill/architect/references/advisory.md +102 -0
- package/skill/architect/references/ai-agents.md +95 -0
- package/skill/architect/references/data.md +90 -0
- package/skill/architect/references/infra.md +128 -0
- package/skill/architect/references/mobile.md +78 -0
- package/skill/architect/references/pinned-facts.md +108 -0
- package/skill/architect/references/principles.md +91 -0
- package/skill/architect/references/project-profile.md +37 -0
- package/skill/architect/references/security.md +97 -0
- package/skill/architect/references/stack.md +38 -0
- package/skill/architect/references/web.md +152 -0
- package/skill/architect/refresh/REFRESH.md +29 -0
- package/skill/architect/refresh/sources.json +244 -0
- package/skill/skill-maintainer/references/release-ops.md +11 -15
- package/skill/skill-maintainer/refresh/REFRESH.md +3 -3
- package/skill-integrity.json +20 -44
- package/skill/arch-guardian/SKILL.md +0 -84
- package/skill/arch-guardian/agents/openai.yaml +0 -4
- package/skill/arch-guardian/assets/adr-template.md +0 -25
- package/skill/arch-guardian/assets/answers-example.json +0 -10
- package/skill/arch-guardian/assets/architecture-profile.json +0 -13
- package/skill/arch-guardian/assets/architecture-profile.schema.json +0 -31
- package/skill/arch-guardian/assets/deployment-review-template.md +0 -24
- package/skill/arch-guardian/assets/service-design-template.md +0 -33
- package/skill/arch-guardian/assets/threat-model-template.md +0 -34
- package/skill/arch-guardian/references/advisory-report.md +0 -65
- package/skill/arch-guardian/references/architecture/agent-product.md +0 -22
- package/skill/arch-guardian/references/architecture/ai-cost.md +0 -24
- package/skill/arch-guardian/references/architecture/ai-data-boundaries.md +0 -21
- package/skill/arch-guardian/references/architecture/ai-evals.md +0 -28
- package/skill/arch-guardian/references/architecture/connectors-sandbox.md +0 -39
- package/skill/arch-guardian/references/architecture/data-memory.md +0 -25
- package/skill/arch-guardian/references/architecture/delivery-operations.md +0 -34
- package/skill/arch-guardian/references/architecture/durable-execution.md +0 -45
- package/skill/arch-guardian/references/architecture/flutter.md +0 -26
- package/skill/arch-guardian/references/architecture/foundation.md +0 -31
- package/skill/arch-guardian/references/architecture/hosting-reliability.md +0 -37
- package/skill/arch-guardian/references/architecture/identity-tenancy.md +0 -37
- package/skill/arch-guardian/references/architecture/model-lifecycle.md +0 -20
- package/skill/arch-guardian/references/architecture/models-observability.md +0 -23
- package/skill/arch-guardian/references/architecture/realtime-channels.md +0 -16
- package/skill/arch-guardian/references/architecture/security-privacy.md +0 -27
- package/skill/arch-guardian/references/architecture/topology-monorepo.md +0 -47
- package/skill/arch-guardian/references/architecture/web.md +0 -29
- package/skill/arch-guardian/references/foundation-compatibility.json +0 -44
- package/skill/arch-guardian/references/golden-patterns.md +0 -43
- package/skill/arch-guardian/references/profile-governance.md +0 -40
- package/skill/arch-guardian/references/rule-model.json +0 -36
- package/skill/arch-guardian/references/workflows.md +0 -48
- package/skill/arch-guardian/refresh/REFRESH.md +0 -47
- package/skill/arch-guardian/refresh/sources.json +0 -1171
- package/skill/arch-guardian/scripts/lib.mjs +0 -48
- package/skill/arch-guardian/scripts/profile-tool.mjs +0 -217
- package/skill/arch-guardian/scripts/refresh-evidence.mjs +0 -366
- package/skill/arch-guardian/scripts/schema-validate.mjs +0 -63
- package/skill/arch-guardian/scripts/validate-profile.mjs +0 -65
- package/skill/arch-guardian/scripts/verify-corpus.mjs +0 -136
|
@@ -1,26 +0,0 @@
|
|
|
1
|
-
# Flutter client
|
|
2
|
-
|
|
3
|
-
Apply this reference only when the `flutter` capability is enabled or Flutter code is observed.
|
|
4
|
-
|
|
5
|
-
## Architecture
|
|
6
|
-
|
|
7
|
-
- **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]
|
|
8
|
-
- **MOB-002 — Generated client.** Flutter **MUST** consume the generated OpenAPI client and must not maintain parallel request/response types.
|
|
9
|
-
- **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]
|
|
10
|
-
- **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.
|
|
11
|
-
|
|
12
|
-
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]
|
|
13
|
-
|
|
14
|
-
Apply pinned claims to the Flutter 3.44 stable series (Dart 3.12), the current stable baseline; adopting a newer stable is source drift that requests scoped review, matching how other foundation-compatibility families handle version advances. <!-- source: FLUTTER-DOCS -->
|
|
15
|
-
|
|
16
|
-
## Network and local state
|
|
17
|
-
|
|
18
|
-
Attach access tokens only to allowlisted API origins. Refresh through one coordinated path; on reuse, revocation, or invalid grant, clear credentials and require authentication. Bind idempotency keys to mutating commands and reconcile optimistic state with the server.
|
|
19
|
-
|
|
20
|
-
Classify cached data by sensitivity and retention. Encrypt confidential caches, scope them to account and workspace, purge them on sign-out, revocation, workspace removal, or policy change, and make schema migrations reversible or safely destructive.
|
|
21
|
-
|
|
22
|
-
## Push, links, and release
|
|
23
|
-
|
|
24
|
-
Treat notifications as hints and deduplicate them by event ID. [FCM-DOCS] [APNS-DOCS]
|
|
25
|
-
|
|
26
|
-
Support localized UI and templates, RTL, IANA timezones, accessibility semantics, font scaling, and locale-aware formatting. Release gates should cover generated-client drift, OAuth/PKCE, token refresh/revocation, offline mutation recovery, tenant switching, push/deep links, storage purge, localization, and accessibility.
|
|
@@ -1,31 +0,0 @@
|
|
|
1
|
-
# Foundation
|
|
2
|
-
|
|
3
|
-
## Operating model
|
|
4
|
-
|
|
5
|
-
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).
|
|
6
|
-
|
|
7
|
-
Tiers gate concerns, never tools:
|
|
8
|
-
|
|
9
|
-
| Tier | Rigor floor |
|
|
10
|
-
|---|---|
|
|
11
|
-
| `prototype` | irreversibles only: no plaintext secrets in code, no cross-tenant access where tenancy exists, no auth bypass, reversible data decisions |
|
|
12
|
-
| `production` | full correctness, security, and recovery concerns for enabled capabilities, in minimal viable form |
|
|
13
|
-
| `enterprise` | adds immutable audit, supply-chain attestation, SCIM/deprovisioning depth, formal threat models, and eval/cost gates |
|
|
14
|
-
|
|
15
|
-
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.
|
|
16
|
-
|
|
17
|
-
- **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]
|
|
18
|
-
- **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]
|
|
19
|
-
- **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]
|
|
20
|
-
|
|
21
|
-
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.
|
|
22
|
-
|
|
23
|
-
## Minimum viable architecture
|
|
24
|
-
|
|
25
|
-
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.
|
|
26
|
-
|
|
27
|
-
## Ownership and portability
|
|
28
|
-
|
|
29
|
-
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.
|
|
30
|
-
|
|
31
|
-
Retired rule IDs are never reused: `FOUND-002` (exception governance) was retired in foundation 0.4.0 together with the enforcement machinery.
|
|
@@ -1,37 +0,0 @@
|
|
|
1
|
-
# Hosting and reliability
|
|
2
|
-
|
|
3
|
-
Apply a hosting profile only to declared production deployables. `none` is valid for a non-deployable shared package. EVE/jobs placement clauses activate only when those owned capabilities are enabled.
|
|
4
|
-
|
|
5
|
-
## Exact placement profiles
|
|
6
|
-
|
|
7
|
-
- **HOST-001 — Declared profile.** A deployable **MUST** match one exact profile below; provider capability does not silently change the selected baseline.
|
|
8
|
-
- **HOST-002 — Self-hosted.** Starter production **MUST** use OCI deployables with Docker Compose documented as non-HA. It requires externalized backups, TLS, OpenBao bootstrap, monitoring, capacity, and explicit single-host failure handling.
|
|
9
|
-
- **HOST-003 — Vercel.** The Vercel profile **MUST** use the `vercel-web-external-eve` baseline: Next runs on Vercel while EVE and pg-boss run in qualified external long-running Node/OCI placements with direct PostgreSQL access. AgentRun projection initially belongs to this trusted long-running plane. This is a VegaStack profile choice, not a claim that Vercel lacks other capabilities.
|
|
10
|
-
- **HOST-004 — Cloudflare/OpenNext.** The OpenNext Worker owns only the Next control plane. EVE, Workflow packages, pg-boss workers, and background daemons **MUST NOT** enter its source or bundle. Tenant/auth paths use cache-disabled direct PostgreSQL semantics; `nodejs_compat` does not make the Worker a general Node process. [OPENNEXT-1202] [CF-WORKERS] [HYPERDRIVE]
|
|
11
|
-
|
|
12
|
-
| Profile | Next | EVE and jobs | PostgreSQL/World | Required warning |
|
|
13
|
-
|---|---|---|---|---|
|
|
14
|
-
| self-hosted | Node OCI | Node OCI | direct PostgreSQL | Compose is non-HA |
|
|
15
|
-
| Vercel | Vercel Next | external Node/OCI | external direct PostgreSQL | external runtime ownership |
|
|
16
|
-
| Cloudflare/OpenNext | OpenNext Worker | external Node/OCI | external direct PostgreSQL | Worker Node subset; auth cache off |
|
|
17
|
-
|
|
18
|
-
Profile changes require an ADR, deployment review, data/secret migration, contract and recovery tests, rollout, and rollback.
|
|
19
|
-
|
|
20
|
-
## Reliability
|
|
21
|
-
|
|
22
|
-
- **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.
|
|
23
|
-
- **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.
|
|
24
|
-
- **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.
|
|
25
|
-
- **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.
|
|
26
|
-
|
|
27
|
-
| Failure | Expected recovery evidence |
|
|
28
|
-
|---|---|
|
|
29
|
-
| Next loss | retry/idempotency; durable state intact |
|
|
30
|
-
| pg-boss crash | lease retry; same admission/effect key |
|
|
31
|
-
| EVE crash | World resume/replay; effect reconciliation |
|
|
32
|
-
| PostgreSQL loss | fail closed; PITR/failover within objectives |
|
|
33
|
-
| sandbox crash | recreate from durable inputs; cleanup reconciliation |
|
|
34
|
-
| dependency outage | policy-safe fallback or visible pause |
|
|
35
|
-
| cell loss | home-cell routing and exercised recovery plan |
|
|
36
|
-
|
|
37
|
-
Add Kubernetes only when HA, scale, placement, or operational requirements exceed Compose/managed profiles. Change workflow ownership only after the qualified EVE/Postgres World baseline fails a required capability and an ADR proves migration and rollback. PostgreSQL 18 is the candidate major-version horizon for these profiles; treat it as a qualification event, not a drop-in upgrade. <!-- source: POSTGRES-DOCS -->
|
|
@@ -1,37 +0,0 @@
|
|
|
1
|
-
# Identity and tenancy
|
|
2
|
-
|
|
3
|
-
Apply identity rules only to authenticated/delegated/service access that exists. Apply organization rules to multi-tenant workspace products. Apply `TEN-*` rules to shared-schema multi-tenancy; public, single-tenant and isolated-database projects do not acquire RLS requirements merely by using VegaStack.
|
|
4
|
-
|
|
5
|
-
## Identity boundary
|
|
6
|
-
|
|
7
|
-
- **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.
|
|
8
|
-
- **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]
|
|
9
|
-
- **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]
|
|
10
|
-
- **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]
|
|
11
|
-
- **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]
|
|
12
|
-
- **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]
|
|
13
|
-
- **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.
|
|
14
|
-
|
|
15
|
-
## Tenant database boundary
|
|
16
|
-
|
|
17
|
-
- **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]
|
|
18
|
-
- **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]
|
|
19
|
-
- **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]
|
|
20
|
-
- **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]
|
|
21
|
-
|
|
22
|
-
```mermaid
|
|
23
|
-
sequenceDiagram
|
|
24
|
-
participant API as Trusted API
|
|
25
|
-
participant Policy as Typed authorizer
|
|
26
|
-
participant DB as PostgreSQL transaction
|
|
27
|
-
API->>Policy: subject, workspace, action, resource
|
|
28
|
-
Policy-->>API: allow plus policy version
|
|
29
|
-
API->>DB: BEGIN and SET LOCAL context
|
|
30
|
-
API->>DB: query with workspace composite key
|
|
31
|
-
DB-->>API: RLS-filtered result
|
|
32
|
-
API->>DB: append audit and COMMIT
|
|
33
|
-
```
|
|
34
|
-
|
|
35
|
-
Use cache-disabled database paths for auth, session, permission, and RLS-sensitive reads. Hyperdrive transaction pooling resets session state and eligible cached reads do not provide authorization freshness. [HYPERDRIVE]
|
|
36
|
-
|
|
37
|
-
Qualification includes applicable cross-workspace IDs, joins, subqueries, composite foreign keys, inserts/updates, exports, background jobs, migrations, pool reuse, support expiry, role ownership, `SECURITY DEFINER`, SCIM deprovisioning, and session revocation.
|
|
@@ -1,20 +0,0 @@
|
|
|
1
|
-
# Model lifecycle
|
|
2
|
-
|
|
3
|
-
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.
|
|
4
|
-
|
|
5
|
-
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.
|
|
6
|
-
|
|
7
|
-
- **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]
|
|
8
|
-
- **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.
|
|
9
|
-
- **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.
|
|
10
|
-
- **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.
|
|
11
|
-
|
|
12
|
-
## Retirement flow
|
|
13
|
-
|
|
14
|
-
`pinned → deprecation notice → successor selected → eval and cost qualification → canary → cohort ramp → old pin removed`. Each step records evidence; skipping straight from notice to swap is qualification debt. Where the provider offers a legacy alias during migration, treat it as a bridge with an end date, not a destination. The provider model catalogs and deprecation registries are the watch surface. [ANTHROPIC-MODELS] [OPENAI-MODELS] [GOOGLE-MODELS]
|
|
15
|
-
|
|
16
|
-
## Fallback and admission
|
|
17
|
-
|
|
18
|
-
Fallback order is part of route policy: same-policy alternates first, degraded-capability alternates only when the product declares the degradation acceptable, visible pause when nothing satisfies policy. Record which pin actually served each request — a fallback that served traffic for a week is a de facto primary and must be qualified as one.
|
|
19
|
-
|
|
20
|
-
Admission shedding is an architecture concern, not an error handler: quotas per workspace and per feature decide who waits when capacity shrinks, and shed work surfaces as retryable, audited outcomes rather than silent loss. Measure provider error and latency baselines continuously so a deprecation-driven migration has a comparison target.
|
|
@@ -1,23 +0,0 @@
|
|
|
1
|
-
# Models and observability
|
|
2
|
-
|
|
3
|
-
Apply model rules only when model routing is enabled or observed. Apply telemetry/audit rules to signals and audit surfaces the project actually emits.
|
|
4
|
-
|
|
5
|
-
## Model routing
|
|
6
|
-
|
|
7
|
-
- **MODEL-001 — Provider-neutral adapter.** Model calls **MUST** use a provider-neutral adapter that declares model capabilities, streaming, structured output, tool use, region, retention, key source, quota, timeout, and fallback policy.
|
|
8
|
-
- **MODEL-002 — Key paths.** Platform keys stay in the trusted model service. Workspace BYOK **MUST** persist only as encrypted ciphertext/reference and be resolved just in time; agents and sandboxes receive neither key path.
|
|
9
|
-
- **MODEL-003 — Policy-preserving fallback.** Fallback and caches **MUST NOT** weaken region, retention, key-source, data-class, or tenant policy. A blocked fallback pauses visibly rather than silently changing policy.
|
|
10
|
-
|
|
11
|
-
Prefer Cloudflare AI Gateway behind the adapter; direct AI SDK providers and qualified self-hosted alternatives remain supported. Explicitly configure gateway logging/caching to the same privacy contract. [AI-GATEWAY] [AI-SDK-7]
|
|
12
|
-
|
|
13
|
-
Record route decision, policy version, provider/model, key source, region, latency, token/usage estimate, cache/fallback state, approval link, and outcome—never the key. Low-retention/no-retention requests must fail closed when no route satisfies policy.
|
|
14
|
-
|
|
15
|
-
## Telemetry and audit
|
|
16
|
-
|
|
17
|
-
- **OBS-001 — Vendor-neutral telemetry.** Services **MUST** emit OpenTelemetry-compatible traces, metrics, and logs with W3C propagation and stable tenant-safe correlation. [OTEL-DOCS]
|
|
18
|
-
- **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.
|
|
19
|
-
- **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.
|
|
20
|
-
|
|
21
|
-
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.
|
|
22
|
-
|
|
23
|
-
Define owners and alerts for API latency, admission age, EVE stalls, connector/model/sandbox failures, SSE freshness, notification delivery, audit pipeline health, and deletion backlog.
|
|
@@ -1,16 +0,0 @@
|
|
|
1
|
-
# Realtime and channels
|
|
2
|
-
|
|
3
|
-
Apply realtime, notification and external-channel rules independently when each capability is enabled or observed.
|
|
4
|
-
|
|
5
|
-
- **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.
|
|
6
|
-
- **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.
|
|
7
|
-
- **RT-003 — Event ownership.** Every event type **MUST** name one authoritative producer, allowed consumers, ordering scope, dedupe key, retention, authorization, and redaction policy.
|
|
8
|
-
- **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.
|
|
9
|
-
- **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.
|
|
10
|
-
- **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.
|
|
11
|
-
|
|
12
|
-
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.
|
|
13
|
-
|
|
14
|
-
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.
|
|
15
|
-
|
|
16
|
-
Add collaboration/presence infrastructure only after a bidirectional requirement and ordering scope are explicit; agent streaming alone is not a trigger.
|
|
@@ -1,27 +0,0 @@
|
|
|
1
|
-
# Security and privacy
|
|
2
|
-
|
|
3
|
-
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.
|
|
4
|
-
|
|
5
|
-
- **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.
|
|
6
|
-
- **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]
|
|
7
|
-
- **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]
|
|
8
|
-
- **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]
|
|
9
|
-
- **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.
|
|
10
|
-
|
|
11
|
-
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).
|
|
12
|
-
|
|
13
|
-
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.
|
|
14
|
-
|
|
15
|
-
| Control objective | Required mechanism |
|
|
16
|
-
|---|---|
|
|
17
|
-
| tenant isolation | `TEN-001` through `TEN-004`, typed grants, negative tests |
|
|
18
|
-
| least privilege | `AUTH-002`, `CONN-001`, short-lived service identities |
|
|
19
|
-
| untrusted execution | `SBX-001` through `SBX-005` |
|
|
20
|
-
| confidentiality | `SEC-002`, `MODEL-002`, `OBS-002`, encryption and redaction |
|
|
21
|
-
| durable accountability | EVE checkpoints, AgentRun projection, `OBS-003` |
|
|
22
|
-
| privacy lifecycle | `DATA-004`, export/deletion reconciliation, legal-hold scope |
|
|
23
|
-
| recovery | qualified backups, PITR, restore and incident drills |
|
|
24
|
-
|
|
25
|
-
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.
|
|
26
|
-
|
|
27
|
-
Threat and deployment reviews identify detection, containment, evidence preservation, recovery, communication, owner, and verification for every material scenario.
|
|
@@ -1,47 +0,0 @@
|
|
|
1
|
-
# Topology and monorepo
|
|
2
|
-
|
|
3
|
-
The topology is composable. Include only enabled project-owned capabilities; shared/external providers sit behind declared contracts and need no consumer source root.
|
|
4
|
-
|
|
5
|
-
## Runtime ownership
|
|
6
|
-
|
|
7
|
-
- **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]
|
|
8
|
-
- **RUN-002 — Job placement.** pg-boss workers **MUST** run in a separate supported Node/OCI placement, never inside the OpenNext request bundle.
|
|
9
|
-
- **RUN-003 — Explicit provider boundary.** Provider-specific compute, storage, model, and sandbox behavior **MUST** remain behind declared adapters and hosting profiles.
|
|
10
|
-
- **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.
|
|
11
|
-
|
|
12
|
-
```mermaid
|
|
13
|
-
flowchart LR
|
|
14
|
-
Client["Web, Flutter, channels"] --> Next["Next.js control plane"]
|
|
15
|
-
Next --> PG["PostgreSQL system of record"]
|
|
16
|
-
Next --> Boss["pg-boss admission and jobs"]
|
|
17
|
-
Boss --> Eve["EVE long-running Node service"]
|
|
18
|
-
Eve --> World["PostgreSQL Workflow World"]
|
|
19
|
-
Eve --> Broker["Trusted capability broker"]
|
|
20
|
-
Broker --> Sandbox["Untrusted sandbox"]
|
|
21
|
-
Eve --> Model["Model adapter"]
|
|
22
|
-
Eve --> Objects["S3-compatible objects"]
|
|
23
|
-
OpenBao["OpenBao"] --> Next
|
|
24
|
-
OpenBao --> Eve
|
|
25
|
-
```
|
|
26
|
-
|
|
27
|
-
| Component | Owns | Must not own |
|
|
28
|
-
|---|---|---|
|
|
29
|
-
| Next.js | UI, RSC, Route Handlers, Better Auth, REST/OpenAPI, admission transaction | long-running execution |
|
|
30
|
-
| pg-boss | transactional admission and ordinary jobs | EVE sessions, steps, waits, approvals, hooks, or streams |
|
|
31
|
-
| EVE + Postgres World | durable agent execution state | business admission/fairness queue |
|
|
32
|
-
| AgentRun | product/audit inputs and execution projection | workflow replay internals |
|
|
33
|
-
| sandbox broker/provider | isolated execution and scoped capabilities | database, OpenBao, or provider credentials |
|
|
34
|
-
| PostgreSQL | business truth, jobs, Workflow World, FTS/vector metadata | binary object payloads |
|
|
35
|
-
|
|
36
|
-
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]
|
|
37
|
-
|
|
38
|
-
## Workspace and packages
|
|
39
|
-
|
|
40
|
-
Use a Bun/Turborepo workspace for JavaScript/TypeScript and Flutter orchestration. Production deployables use their supported runtimes.
|
|
41
|
-
|
|
42
|
-
- **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.
|
|
43
|
-
- **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.
|
|
44
|
-
- **PKG-003 — Dependency qualification.** Security, runtime, and durability protocol families **MUST** be pinned and upgraded atomically with compatibility, migration, replay, and rollback tests.
|
|
45
|
-
- **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.
|
|
46
|
-
|
|
47
|
-
Commit generated public contracts needed by consumers. [TURBO-DOCS] [BUN-DOCS]
|
|
@@ -1,29 +0,0 @@
|
|
|
1
|
-
# Web control plane
|
|
2
|
-
|
|
3
|
-
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.
|
|
4
|
-
|
|
5
|
-
## Ownership and contract
|
|
6
|
-
|
|
7
|
-
- **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.
|
|
8
|
-
- **API-002 — Canonical API.** Bounded Zod schemas **MUST** deterministically generate OpenAPI and Flutter/public clients. Parallel hand-written wire contracts are forbidden.
|
|
9
|
-
- **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.
|
|
10
|
-
- **API-004 — Tenant-safe caching.** Auth, session, authorization, membership, audit, and tenant-sensitive reads **MUST NOT** use implicit or stale caches.
|
|
11
|
-
- **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.
|
|
12
|
-
|
|
13
|
-
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]
|
|
14
|
-
|
|
15
|
-
## Rendering and state
|
|
16
|
-
|
|
17
|
-
| Concern | Default |
|
|
18
|
-
|---|---|
|
|
19
|
-
| initial authenticated read | RSC with server-derived tenant context |
|
|
20
|
-
| interaction, mutation, reconnect | TanStack Query over typed REST |
|
|
21
|
-
| durable run output | resumable SSE with cursor and terminal reconciliation |
|
|
22
|
-
| validation | shared Zod contract; server authoritative |
|
|
23
|
-
| optimistic update | idempotency key, rollback, authoritative reconciliation, no privilege escalation |
|
|
24
|
-
|
|
25
|
-
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.
|
|
26
|
-
|
|
27
|
-
## Extraction trigger
|
|
28
|
-
|
|
29
|
-
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.
|
|
@@ -1,44 +0,0 @@
|
|
|
1
|
-
{
|
|
2
|
-
"schemaVersion": 1,
|
|
3
|
-
"foundationVersion": "0.4.0",
|
|
4
|
-
"baselines": {
|
|
5
|
-
"vs-2026-08-07": {
|
|
6
|
-
"state": "supported",
|
|
7
|
-
"reviewBy": "2026-11-07",
|
|
8
|
-
"families": {
|
|
9
|
-
"web": { "next": "16.3.0", "node": "24.18.0", "bun": "1.3.14" },
|
|
10
|
-
"cloudflare-opennext": { "openNext": "1.20.2" },
|
|
11
|
-
"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" },
|
|
12
|
-
"jobs": { "pgBoss": "12.27.0", "postgres": "17.10" },
|
|
13
|
-
"identity": { "betterAuth": "1.6.26" },
|
|
14
|
-
"sandbox-cloudflare": { "cloudflareSandbox": "0.12.4" }
|
|
15
|
-
}
|
|
16
|
-
},
|
|
17
|
-
"candidate": {
|
|
18
|
-
"state": "candidate",
|
|
19
|
-
"qualificationRequired": true,
|
|
20
|
-
"reviewBy": "2026-09-07",
|
|
21
|
-
"families": {},
|
|
22
|
-
"observedVersions": { "eve": "0.31.2", "workflowPostgres": "5.0.0-beta.32", "postgres": "18.4" },
|
|
23
|
-
"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"]
|
|
24
|
-
},
|
|
25
|
-
"vs-2026-05-01": {
|
|
26
|
-
"state": "deprecated",
|
|
27
|
-
"reviewBy": "2026-09-01",
|
|
28
|
-
"removalBy": "2026-12-01",
|
|
29
|
-
"families": {}
|
|
30
|
-
}
|
|
31
|
-
},
|
|
32
|
-
"policy": {
|
|
33
|
-
"exactProjectVersions": true,
|
|
34
|
-
"atomicFamilies": ["agents"],
|
|
35
|
-
"lagOrAdvanceRequiresProjectAdr": true
|
|
36
|
-
},
|
|
37
|
-
"sourceDrift": {
|
|
38
|
-
"observedAt": "2026-08-08T00:00:00.000Z",
|
|
39
|
-
"status": "qualification-required",
|
|
40
|
-
"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"],
|
|
41
|
-
"registry": "refresh/sources.json",
|
|
42
|
-
"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."
|
|
43
|
-
}
|
|
44
|
-
}
|
|
@@ -1,43 +0,0 @@
|
|
|
1
|
-
# Golden implementation patterns
|
|
2
|
-
|
|
3
|
-
Use these as concise boundary shapes, not copy-paste frameworks.
|
|
4
|
-
|
|
5
|
-
## Protected request and transaction-local RLS
|
|
6
|
-
|
|
7
|
-
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`.
|
|
8
|
-
|
|
9
|
-
## AgentRun and transactional admission
|
|
10
|
-
|
|
11
|
-
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.
|
|
12
|
-
|
|
13
|
-
## Lost acknowledgement recovery
|
|
14
|
-
|
|
15
|
-
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.
|
|
16
|
-
|
|
17
|
-
## Effect fence and reconciliation
|
|
18
|
-
|
|
19
|
-
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.
|
|
20
|
-
|
|
21
|
-
## Capability envelope and credential broker
|
|
22
|
-
|
|
23
|
-
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.
|
|
24
|
-
|
|
25
|
-
## Safe connector HTTP and redirects
|
|
26
|
-
|
|
27
|
-
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.
|
|
28
|
-
|
|
29
|
-
## Resumable SSE
|
|
30
|
-
|
|
31
|
-
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.
|
|
32
|
-
|
|
33
|
-
## Deterministic contracts
|
|
34
|
-
|
|
35
|
-
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.
|
|
36
|
-
|
|
37
|
-
## Deletion propagation
|
|
38
|
-
|
|
39
|
-
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.
|
|
40
|
-
|
|
41
|
-
## Support-session authorization
|
|
42
|
-
|
|
43
|
-
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`.
|
|
@@ -1,40 +0,0 @@
|
|
|
1
|
-
# Profile and governance
|
|
2
|
-
|
|
3
|
-
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.
|
|
4
|
-
|
|
5
|
-
| Field | Meaning |
|
|
6
|
-
|---|---|
|
|
7
|
-
| `project.tier` | `prototype` / `production` / `enterprise` — decides which concerns apply (see foundation) |
|
|
8
|
-
| `project.kind`, `tenancy` | confirmed project facts |
|
|
9
|
-
| `hosting` | production hosting target (`none` for a non-deployable package) |
|
|
10
|
-
| `capabilities` | enabled list: `web`, `flutter`, `agents`, `jobs`, `sandbox`, `connectors`, `knowledge`, `models`, `realtime`, `notifications`, `enterprise-identity` |
|
|
11
|
-
| `notes` | free-form confirmed facts and recorded deviations |
|
|
12
|
-
|
|
13
|
-
## Tier declaration
|
|
14
|
-
|
|
15
|
-
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.
|
|
16
|
-
|
|
17
|
-
## Capability activation
|
|
18
|
-
|
|
19
|
-
Apply rules only when a capability is enabled in the profile or observed in the repository, at or below the declared tier. Key implications:
|
|
20
|
-
|
|
21
|
-
- Flutter activates delegated OAuth/PKCE and generated-client rules.
|
|
22
|
-
- Agents activate durable-execution ownership rules; at prototype tier a simpler loop is acceptable with a named migration path (see durable execution).
|
|
23
|
-
- Untrusted execution activates the sandbox boundary.
|
|
24
|
-
- Shared-schema multi-tenancy activates `TEN-*` at every tier.
|
|
25
|
-
- Production secrets activate secret-custody guidance — the mechanism is tier- and trigger-dependent (see security and privacy), never automatically OpenBao.
|
|
26
|
-
- Removing a capability requires a cleanup/migration plan for durable data, credentials, queues, and contracts.
|
|
27
|
-
|
|
28
|
-
## Deviations
|
|
29
|
-
|
|
30
|
-
There is no exception or suppression machinery. When the team deliberately departs from a recommendation:
|
|
31
|
-
|
|
32
|
-
1. Record it — one line in `notes` for small departures; an ADR ([template](../assets/adr-template.md)) for consequential ones (owner, decision, revisit trigger).
|
|
33
|
-
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.
|
|
34
|
-
|
|
35
|
-
## Governance operations
|
|
36
|
-
|
|
37
|
-
- Drift PRs from the automated source refresh are reviewed by whoever merges them.
|
|
38
|
-
- Source staleness thresholds are a minimum of 14 days, aligned to the weekly automated refresh.
|
|
39
|
-
- 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.
|
|
40
|
-
- Full qualification matrices (e.g. `DUR-007`) are required before the production tier, not before every merge; interim reviews record the gap under `notVerified`.
|
|
@@ -1,36 +0,0 @@
|
|
|
1
|
-
{
|
|
2
|
-
"schemaVersion": 1,
|
|
3
|
-
"defaults": { "classification": "invariant", "tierFloor": "production", "authority": "canonical prose in references/architecture; tier tags on rule lines override the default floor" },
|
|
4
|
-
"groups": [
|
|
5
|
-
{ "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." },
|
|
6
|
-
{ "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." },
|
|
7
|
-
{ "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." },
|
|
8
|
-
{ "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." },
|
|
9
|
-
{ "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." },
|
|
10
|
-
{ "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." },
|
|
11
|
-
{ "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." },
|
|
12
|
-
{ "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." },
|
|
13
|
-
{ "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." },
|
|
14
|
-
{ "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." },
|
|
15
|
-
{ "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." },
|
|
16
|
-
{ "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." },
|
|
17
|
-
{ "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." },
|
|
18
|
-
{ "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." },
|
|
19
|
-
{ "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." },
|
|
20
|
-
{ "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." },
|
|
21
|
-
{ "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." },
|
|
22
|
-
{ "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." },
|
|
23
|
-
{ "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." },
|
|
24
|
-
{ "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." },
|
|
25
|
-
{ "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." },
|
|
26
|
-
{ "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." },
|
|
27
|
-
{ "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." }
|
|
28
|
-
],
|
|
29
|
-
"overrides": [
|
|
30
|
-
{ "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" },
|
|
31
|
-
{ "rule": "HOST-002", "classification": "preferred-default", "permittedOption": "A different qualified self-host topology through project ADR" },
|
|
32
|
-
{ "rule": "DATA-002", "classification": "preferred-default", "permittedOption": "A qualified external/shared knowledge service through declared ownership contract" },
|
|
33
|
-
{ "rule": "MLIFE-003", "classification": "preferred-default", "permittedOption": "Direct rollout for a low-risk change with eval pass and one-step rollback" },
|
|
34
|
-
{ "rule": "COST-003", "classification": "preferred-default", "permittedOption": "No prompt/context caching until a measured benefit exists" }
|
|
35
|
-
]
|
|
36
|
-
}
|
|
@@ -1,48 +0,0 @@
|
|
|
1
|
-
# Adaptive workflows
|
|
2
|
-
|
|
3
|
-
## Greenfield
|
|
4
|
-
|
|
5
|
-
Discover confirmed facts before recommending. Ask no more than three material questions at once and branch only when an answer activates a topic:
|
|
6
|
-
|
|
7
|
-
1. Product objective, users, lifecycle stage, access, tenancy mode — and the **tier** (prototype / production / enterprise), a deliberate choice the user confirms.
|
|
8
|
-
2. Clients: web, Flutter, public API, connectors or channels.
|
|
9
|
-
3. Agents, automation, ordinary jobs, untrusted execution and external effects.
|
|
10
|
-
4. Data classes, residency, retention, deletion, RPO/RTO and availability/latency objectives (production tier and above).
|
|
11
|
-
5. Hosting/self-hosting, workload/growth, team/on-call/cost, milestone, and deferrable choices.
|
|
12
|
-
|
|
13
|
-
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.
|
|
14
|
-
|
|
15
|
-
## Brownfield
|
|
16
|
-
|
|
17
|
-
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.
|
|
18
|
-
|
|
19
|
-
Separate:
|
|
20
|
-
|
|
21
|
-
- current observed state;
|
|
22
|
-
- intended state from committed artifacts;
|
|
23
|
-
- target recommendation at the declared tier;
|
|
24
|
-
- immediate security/correctness risks;
|
|
25
|
-
- required migrations and rollback;
|
|
26
|
-
- optional improvements;
|
|
27
|
-
- runtime evidence that is not verified.
|
|
28
|
-
|
|
29
|
-
Prefer incremental migration with compatibility windows and rollback over needless rewrites. Never convert detection heuristics into claims of absence or compliance.
|
|
30
|
-
|
|
31
|
-
## Reviews
|
|
32
|
-
|
|
33
|
-
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.
|
|
34
|
-
|
|
35
|
-
## Other lifecycle tasks
|
|
36
|
-
|
|
37
|
-
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.
|
|
38
|
-
|
|
39
|
-
- **Explanation:** answer the decision directly; load only references needed to explain it.
|
|
40
|
-
- **ADR:** a decision record, not a waiver — capture owner, decision, alternatives, risks, and revisit trigger.
|
|
41
|
-
- **Threat model:** model only enabled/exposed surfaces and their trust boundaries, at the tier's depth.
|
|
42
|
-
- **Deployment:** compare declared hosting with deployables, data, secrets, recovery and rollback.
|
|
43
|
-
- **Source drift:** refresh affected entries only; recommendations change only through review.
|
|
44
|
-
- **Migration/removal:** distinguish current/target state, preserve compatibility, and clean durable data, credentials, queues and contracts.
|
|
45
|
-
|
|
46
|
-
## Decision horizons
|
|
47
|
-
|
|
48
|
-
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.
|