@yiaany/ghostapi 0.1.9 → 0.2.0

package/docs/operations/disaster-recovery-runbook.md

@@ -1,81 +0,0 @@
-# Disaster-Recovery Runbook
-
-Local backup and restore for the GhostAPI data directory (`GHOSTAPI_DATA_DIR`, default `.ghostapi/`).
-
-## When To Use This
-
-- You are replacing or moving the local data directory and need a verified copy.
-- A store is corrupt (`ghostapi` reports a degraded runtime health) and you want to restore from a known-good backup.
-- You are running a quarterly DR drill: back up, destroy, restore, verify.
-
-## Before You Start
-
-- Run `ghostapi start` is NOT required. Backup and restore work on a stopped or running instance, but restoring over a running instance is not supported — stop the instance first.
-- Backups are local directory copies with sha256 manifests. They are not encrypted, do not contain upstream secrets (the credential broker persists metadata only), and are not a substitute for object-storage or offsite backup.
-- The default backup destination is `.ghostapi/reliability/backups/backup-<timestamp>-<id>/`. Because the `backups` directory is excluded from future backups, backups never recursively include one another.
-
-## Backup
-
-Backup is available programmatically:
-
-```ts
-import { backupRuntime } from "@yiaany/ghostapi";
-const result = await backupRuntime({ destinationDir: ".ghostapi/reliability/backups/manual-drill" });
-// result: { backupId, path, fileCount, totalBytes, verified: true, createdAt }
-```
-
-The backup verifies every copied file (size + sha256 + JSON structure for `.json` entries) and refuses to overwrite an existing destination. `result.verified` is only true after full verification.
-
-## Restore
-
-```ts
-import { restoreRuntimeBackup } from "@yiaany/ghostapi";
-await restoreRuntimeBackup({ sourceDir: ".ghostapi/reliability/backups/manual-drill", targetDir: ".ghostapi-restored" });
-```
-
-Then point the runtime at the restored directory:
-
-```bash
-export GHOSTAPI_DATA_DIR=/absolute/path/to/.ghostapi-restored
-ghostapi doctor
-```
-
-Restore refuses:
-
-- A backup whose manifest was not verified at creation time.
-- Any manifest entry path that escapes the backup root (path traversal).
-- A target that is the backup source itself or inside it.
-- A target directory that is not empty (restore copies into a fresh directory).
-- Any entry whose bytes no longer match the manifest (tamper detection).
-
-## Verification Steps After Restore
-
-1. `ghostapi doctor` reports healthy.
-2. `curl http://127.0.0.1:8080/health` returns `{ "ok": true, "ready": true }`.
-3. `curl http://127.0.0.1:8080/health/readiness` returns HTTP 200 with a `ready: true` report. A 503 means the restored directory has a degraded store — do not continue.
-4. Spot-check state: list actions (`ghostapi actions` or the equivalent CLI), run a reconciliation run, and confirm SLO sample counts are non-zero.
-
-## Destroy-The-World Drill (Non-Destructive)
-
-1. `backupRuntime` into `.ghostapi/reliability/backups/drill-<date>`.
-2. `Remove-Item -Recurse -Force .ghostapi` (or `rm -rf`) to simulate data loss.
-3. `restoreRuntimeBackup` into a fresh directory.
-4. Point `GHOSTAPI_DATA_DIR` at the restored directory and run the verification steps above.
-5. Confirm the backup directory still exists untouched (restore copies out of it; it never deletes).
-
-## Failure Modes
-
-| Symptom | Meaning | Action |
-| --- | --- | --- |
-| "Backup destination already exists" | Refusing to overwrite | Use a new destination or remove the old backup deliberately |
-| "Backup source entry is not valid JSON" | A `.json` file in the data dir is corrupt | Find and fix/delete the corrupt store, then re-back up |
-| "Backup file content changed during copy" | Concurrent write during backup | Stop writers, re-run backup |
-| "failed integrity verification" on restore | Backup was tampered or the disk changed | Do not restore; find the original source or a different backup |
-| "path escapes its root directory" | Crafted/tampered manifest | Reject the backup as untrusted |
-| `/health/readiness` returns 503 | A restored store is corrupt | Inspect the `degraded` store in the report and repair/delete it, then re-check |
-
-## Retention Guidance
-
-- Keep at least two rotating backups: the previous known-good and the current.
-- Back up before any release or before switching `GHOSTAPI_DATA_DIR`.
-- The 64 MiB backup cap covers the bounded local stores; if your worlds/actions exceed it, prune old synthetic data first.

package/docs/operations/kill-switch-runbook.md

@@ -1,32 +0,0 @@
-# Kill Switch Runbook
-
-## Detection
-
-Use this procedure when policy violations, abnormal action velocity, budget exhaustion, reconciliation mismatch, latency/failure circuit opening, or suspected agent compromise is observed. An alert is evidence only; it is not a stop. Verify the affected organization, project, environment, agent/workload, provider, operation, or risk class before selecting scope.
-
-## Stop
-
-1. Use an independently authenticated emergency operator with `safety.stop`.
-2. Call the local `LocalSafetyController.stop({ identity, scope, reason })` API with the narrowest safe scope. Use `global` when the scope cannot be established quickly.
-3. Record a bounded factual reason without credentials, raw requests, personal data, or provider payloads.
-4. Confirm the persisted switch is enabled and examine the safety audit chain. Matching queued records must be in the dead-letter queue, not still pending.
-5. Treat actions that passed their final commit check as potentially completed. Do not retry unknown outcomes; investigate or reconcile them first.
-
-## Investigation
-
-1. Preserve the local safety, action, approval, and credential-broker state files as evidence under the existing local trust model.
-2. Inspect action receipt status, controller audit records, budget ledger, circuit reason, and dead letters.
-3. Identify the exact idempotency key and action hash. A changed action must be submitted as a new reviewed action, never forced through a prior reservation.
-4. For any future provider integration, reconcile against the provider before retrying or compensating. This local synthetic controller cannot prove external outcome.
-
-## Recovery
-
-1. Correct the policy/configuration or isolate the compromised workload.
-2. Review budgets, circuit thresholds, and the root cause. Do not clear audit, ledger, or dead-letter state to make a control appear healthy.
-3. Require a separately authenticated operator with `safety.reenable`; the stop permission alone is insufficient.
-4. Call `reenable({ identity, scope, reason })` and confirm the audit record and persisted switch state.
-5. Re-admit only a reviewed action. Approved artifacts still require current policy, identity, idempotency, budget, circuit, kill-switch, and final-commit checks.
-
-## Game Day
-
-The `GhostAPI Kill Switch Game Day` workflow runs at `03:17 UTC` each Monday and can be started manually. It executes only the local synthetic controller test. Investigate a failed drill before trusting the control: a successful alert without a verified blocked action is not sufficient.

package/docs/release-checklist.md

@@ -1,83 +0,0 @@
-# Release Checklist
-
-Use this checklist before publishing GhostAPI to GitHub or npm.
-
-## Metadata
-
-- `package.json` has the correct `name`, `version`, `description`, `license`, `bin`, `files`, `keywords`, and repository metadata.
-- `README.md` explains value, install, CLI, provider coverage, examples, safety, and contributing.
-- `CHANGELOG.md` has an entry for the release.
-- `LICENSE`, `SECURITY.md`, `CONTRIBUTING.md`, and `CODE_OF_CONDUCT.md` are present.
-- [Release readiness matrix](release-readiness.md) and [migration/rollback guide](release-migration-and-rollback.md) are current for the proposed release.
-
-## Local Verification
-
-```bash
-npm run typecheck
-npm test
-npm run build
-npm run smoke:package
-```
-
-Smoke check the built CLI:
-
-```bash
-node dist/cli/index.js --help
-node dist/cli/index.js providers list
-node dist/cli/index.js model get
-```
-
-Run local proxy smoke tests:
-
-```bash
-node dist/cli/index.js start --offline --port 8080
-```
-
-Then verify locally:
-
-```bash
-curl http://localhost:8080/health
-curl http://localhost:8080/dashboard
-curl -X POST http://localhost:8080/v1/customers -H "content-type: application/json" -d '{"email":"ada@example.com"}'
-curl http://localhost:8080/v1/customers
-curl -X POST http://localhost:8080/emails -H "content-type: application/json" -d '{"from":"dev@example.com","to":"ada@example.com","subject":"Hello"}'
-curl -X POST http://localhost:8080/2010-04-01/Accounts/AC123/Messages.json -H "content-type: application/x-www-form-urlencoded" -d "To=+15551234567&From=+15557654321&Body=Hello"
-```
-
-## Package Verification
-
-```bash
-npm pack --dry-run
-```
-
-Confirm the package includes only intended release files and does not include:
-
-- `.ghostapi/`
-- `.env`
-- `node_modules/`
-- local logs
-- test output
-
-## Safety Checks
-
-- GhostAPI does not make real provider API calls by default.
-- Ambient `OPENAI_API_KEY` does not enable external LLM access.
-- LLM usage requires explicit opt-in plus `GHOSTAPI_LLM_API_KEY`, and receives sanitized requests.
-- Dashboard events are sanitized.
-- State and persisted event files do not contain secret fixtures used by security tests.
-- Cache keys do not include raw secrets.
-- Ordered request arrays produce distinct cache keys when their order changes.
-- Concurrent child-process state and behavior writes preserve all covered updates.
-- Persisted events rotate at 5 MiB and retain no more than two archives.
-- Non-loopback startup fails without a strong `GHOSTAPI_AUTH_TOKEN`; dashboard APIs and SSE reject missing tokens.
-- Generated tests honor `GHOSTAPI_BASE_URL` instead of requiring port 8080.
-- CLI user errors are actionable and do not print confusing stack traces.
-- GitHub workflows use least-privilege permissions and SHA-pinned actions.
-- Security claims match tests actually run on the target platform; Windows/macOS local simulation is not Linux enforcement evidence.
-- Any full-audit findings have a documented owner and remediation plan.
-
-## Publish
-
-- Tag the release.
-- Push to GitHub.
-- Publish to npm only after package dry-run output has been reviewed.

package/docs/release-migration-and-rollback.md

@@ -1,63 +0,0 @@
-# Release Migration And Rollback
-
-Last reviewed: 2026-08-08.
-
-This guide covers the published local `@yiaany/ghostapi` package. The separate `hosted/` pilot is not part of the npm package and has no production migration or rollback approval.
-
-## Before Upgrade
-
-1. Read the target `CHANGELOG.md`, `SECURITY.md`, platform limitations, and package contents.
-2. Keep the project policy and scenarios under normal source control only if they contain no sensitive data. `.ghostapi/` can contain local simulation data and evidence; do not upload it as a generic backup.
-3. If a local backup is needed, make an access-controlled copy of only the required `.ghostapi/` files and review it for secrets before transferring it.
-4. Run `ghostapi doctor --json`. On Windows and macOS, use `ghostapi start --open` for local simulation; do not expect `ghostapi run` enforcement.
-
-## Upgrade
-
-```bash
-npx @yiaany/ghostapi@<version> init
-npx @yiaany/ghostapi@<version> doctor --json
-```
-
-`init` does not overwrite existing setup files. Review generated setup guidance rather than replacing local policy or agent instructions blindly.
-
-For a source checkout, install the pinned lockfile and run:
-
-```bash
-npm ci
-npm run typecheck
-npm test
-npm run build
-npm run smoke:package
-```
-
-On supported Linux runners, also run the selected enforced workflow and generate a sanitized evidence report. A successful Windows/macOS local simulation must not be used as substitute evidence for Linux namespace enforcement.
-
-## Rollback
-
-1. Stop the local GhostAPI process or CI job.
-2. Reinstall the previously reviewed package version or return the source checkout to the previously reviewed commit using the repository's normal non-destructive deployment procedure.
-3. Re-run `ghostapi doctor --json` and the same local smoke or CI workflow used before the upgrade.
-4. Preserve only sanitized evidence needed to explain the rollback. Do not attach raw traffic, secrets, source code, or local data directories to an issue.
-5. If a local data schema rejects an older runtime, do not hand-edit or delete data in place. Work on an access-controlled copy, report the exact version/error through the security or maintainer channel, and retain the original until a recovery path is reviewed.
-
-## Rollback Scope
-
-- The current local runtime has no account, hosted entitlement, billing state, or remote control plane to roll back.
-- `ghostapi telemetry disable` removes the optional local aggregate; it is not a product-version rollback tool.
-- Local file locks coordinate cooperating processes on one filesystem only. Do not attempt a rollback while concurrent GhostAPI processes write the same data directory.
-
-## Release Verification
-
-Run these on the proposed release commit:
-
-```bash
-npm ci
-npm run typecheck
-npm test
-npm run build
-npm run smoke:package
-npm pack --dry-run
-npm audit --omit=dev
-```
-
-Also review the package file list, tracked-source secret scan, direct runtime dependency licenses, GitHub workflow permissions/action pins, and the known gaps in [release readiness](release-readiness.md). Both the production-only and full dependency audits must pass for this release.

package/docs/release-readiness.md

@@ -1,39 +0,0 @@
-# Release Readiness Matrix
-
-Last reviewed: 2026-08-22.
-
-This matrix is a release-candidate review, not a publication approval. No Git tag, GitHub release, or npm publication was created during this review.
-
-| Feature | Platform / boundary | Guarantee level | Evidence reviewed | Known gap | Owner before release |
-| --- | --- | --- | --- | --- | --- |
-| Local provider simulation, dashboard, MCP | Node.js on Windows and Ubuntu WSL2 | Local simulation only; no real provider calls by default. | Final 0.1.8 root lint and typecheck; 55 files and 341 tests with zero skipped; build; packed-package smoke; full and production audits with zero vulnerabilities. | GitHub Actions has not yet been observed on the exact final pushed commit. | Maintainer: retain the exact-commit CI results before publication. |
-| `ghostapi run` | Linux only when `unshare` and `ip` preflight pass | Loopback-only user/mount/network/PID namespace; fail closed. Not a hostile-code filesystem sandbox. | Native Ubuntu WSL2 enforcement suite passed 12 of 12 tests with zero skipped on 2026-08-22, exercising the Linux namespace boundary. Earlier 0.1.7 WSL evidence remains historical. | Local WSL2 evidence is not a substitute for GitHub Actions on the exact final commit. | Maintainer: observe the pinned workflow after push and retain sanitized evidence. |
-| Policy parser | Local YAML input | Bounded, one-document, no anchors/aliases/interpolation, path-contained parsing. | Unit tests plus 400 deterministic malformed-input cases. | Fuzz corpus is deterministic regression coverage, not a replacement for long-running fuzzing. | Maintainer: extend corpus when syntax support changes. |
-| Evidence reports | Local files and explicit `--run` input | Bounded report/run input, secret redaction, canonical logical hash, fail-closed CI result. | Evidence tests include corruption, traversal, terminal escapes, malformed and oversized run evidence. | Same-user filesystem TOCTOU remains outside the local lock/store threat boundary. | Maintainer: document/assess before any shared filesystem support. |
-| Record/replay and contract import | Local JSON/HAR/OpenAPI input | Bounded JSON only; archives, remote refs, symlinks, unsafe hosts, redirects, and secret-bearing bundles reject. | Scenario and contract suites; deterministic malformed-input coverage. | Sanitization is heuristic and requires operator review before sharing. | Maintainer: maintain provider/sanitizer regression fixtures. |
-| Provider packs | Local runtime | Deterministic provider-shaped behavior; unsupported endpoints fail diagnostically. | Stripe lifecycle/conformance tests and provider tests. | Fidelity remains limited to implemented capabilities, not live-provider parity. | Pack maintainer: add conformance before widening claims. |
-| Root CI workflow | GitHub Actions | Read-only repository token and SHA-pinned actions. | Workflow regression coverage is included in the final root suite; workflow definitions include lint/typecheck/test/build/package/audit, hosted, Docker, and Linux enforcement checks. | The workflows still must be observed on the exact final commit after push. | Maintainer: review and retain the GitHub run before publication. |
-| Hosted pilot | Separate Bun/Elysia codebase, implemented but not deployed | Code-level tenant authorization, role checks, bounded request handling, hashed one-time secrets, durable quotas, idempotency, outbox/worker retries, dead-letter state, retention cleanup, readiness checks, and audit metadata. No live-service guarantee. | Clean hosted install; typecheck; 26 tests with zero skipped, including cloned auth-request body bounds; Bun build; zero-vulnerability audit; local non-root Docker image build; migrations `001`-`004` applied to PostgreSQL 17; concurrent organization quota race passed. | No staging deployment; live Google OAuth, Redis, QStash, sustained load, failover, and disaster-recovery behavior remain unproven. | Hosted owner: complete operational gates before any pilot use. |
-| Product telemetry | Local runtime | Disabled by default, aggregate-only, no network transport; opt-out deletes local aggregate. | Product telemetry tests and package smoke. | Not a hosted/team analytics system. | Product owner: obtain explicit partner need before any networked design. |
-
-## Threat Model Delta Since Session 06
-
-- The old proxy-guidance-only model is now explicitly separated from Linux `ghostapi run` enforcement. Unsupported platforms fail closed instead of treating proxy configuration as isolation.
-- Process execution now creates bounded lifecycle evidence, strips secret-shaped target environment values, limits target output, and records only aggregate output-secret/limit signals.
-- Policy, scenario, contract, evidence, replay, and hosted report inputs have bounded parsers and reject traversal, symlink, archive, remote-reference, unsupported-schema, or secret-bearing inputs where applicable.
-- Root CI now explicitly uses `contents: read`; the PR safety workflow remains SHA-pinned, artifact-bounded, and avoids executing fork code in its write-comment job.
-- The hosted pilot now implements bounded request parsing, explicit tenant/role authorization, exact-origin mutation checks, one-time hashed invitation and ingest secrets, durable quotas, worker/outbox retry limits, dead-letter handling, retention cleanup, security headers, and dependency-aware readiness. These are locally tested implementation claims, not evidence of a deployed service.
-
-## Open P2 Items
-
-| Item | Plan | Owner |
-| --- | --- | --- |
-| GitHub Actions on the exact final commit is still required before publication. | Push the final commit, observe every required pinned workflow and job, and retain the run plus sanitized evidence links. | Maintainer. |
-| Hosted staging and migration rehearsal are incomplete. | Deploy an isolated staging environment and apply the four application migrations plus the pinned Better Auth migration against production-shaped PostgreSQL; verify rollback/forward-recovery procedures and tenant authorization. | Hosted owner. |
-| Hosted load and queue behavior are unproven. | Exercise production-shaped sustained/burst load, Redis rate limits, QStash signature validation/redelivery, outbox leases, worker retries/dead letters, and backlog drain behavior with measured thresholds. | Hosted owner. |
-| Hosted disaster recovery is unproven. | Run repeated backup/restore and regional dependency-failure drills; record measured RPO/RTO instead of claiming the architectural targets. | Hosted owner. |
-| Live OAuth and operational secret/configuration paths are unproven. | Validate Google OAuth redirect/origin configuration, session expiry/rotation, account-linking restrictions, secret rotation, and failure behavior in staging. | Hosted owner. |
-
-## Release Gate
-
-The root local package passed the final local 0.1.8 verification recorded in [the 0.1.8 verification record](development/verification-0.1.8.md). Publication still requires observing GitHub Actions on the exact final commit after push. Do not claim a deployed hosted service, completed hosted operational readiness, Linux enforcement on Windows/macOS, or billing availability from this matrix.

package/docs/team-control-plane.md

@@ -1,72 +0,0 @@
-# Team Control-Plane Prototype
-
-## Scope
-
-As of August 8, 2026, the cloud/design-partner gate remains unmet. This is a local architecture prototype stored in a private JSON file. It has no hosted or public endpoint, network listener, deployment, SSO/OIDC/SAML integration, cloud synchronization, telemetry, or external dependency. Local GhostAPI workflows do not require an account or team token.
-
-The store is `.ghostapi/team-control-plane.json` (or the configured `GHOSTAPI_DATA_DIR`). Existing same-directory atomic writes and cooperative cross-process locking protect updates. The store rejects symlinks and data over 1 MiB. This is not a compliance product, immutable storage system, credential broker, or distributed security boundary.
-
-## Data Flow
-
-```mermaid
-flowchart LR
-  Caller[Local typed-library caller] --> Auth[Token authentication or local actor]
-  Auth --> Permit[Central permission and scope evaluator]
-  Permit --> Plane[Local control-plane methods]
-  Plane --> Lock[Locked atomic JSON store]
-  Plane --> Ledger[Per-organization SHA-256 audit chain]
-  Future[Future HTTP transport] -. must apply .-> Headers[CSP and security headers]
-  Future -. must apply .-> Limit[Fixed-window fail-closed limiter]
-  Disabled[Disabled identity provider] -. always denies; no I/O .-> Future
-```
-
-No transport is supplied. A future HTTP layer must authenticate before dispatch, apply `createTeamControlPlaneSecurityHeaders()` (or the immutable `TEAM_CONTROL_PLANE_SECURITY_HEADERS`), use `TeamControlPlaneRateLimiter` before processing with a non-secret opaque principal key, avoid logging raw tokens, and fail closed on invalid keys, invalid limits, invalid clocks, or limiter capacity exhaustion.
-
-## Tenant And Authorization Model
-
-Organizations are tenant boundaries. Projects, environments, scenarios, evidence, policies, service accounts, tokens, and audit records all belong to one organization. Parent references are validated on every read and write. Missing scoped parents return `Resource not found`, preventing cross-tenant identifier disclosure.
-
-All authorization uses the centralized `TEAM_PERMISSION_MATRIX`. The least-privilege matrix is:
-
-| Role | Permissions |
-| --- | --- |
-| `owner` | `member.manage`, `project.manage`, `environment.manage`, `policy.manage`, `token.manage`, `service_account.manage`, `audit.read`, `audit.export`, `data.delete`, `retention.manage`, all scoped reads, `scenario.publish`, `evidence.upload` |
-| `admin` | Everything listed for owner except `member.manage` |
-| `developer` | Scoped reads, `scenario.publish`, `evidence.upload` |
-| `viewer` | Scoped reads only |
-| `service_account` | Token-scoped project/environment reads, `scenario.publish`, and `evidence.upload` only; no organization-wide policy or audit access |
-
-`admin` cannot grant members or issue, rotate, or revoke a token for an owner. `owner` can manage every human-member token. Service-account actors have a distinct `service:<id>` audit identity and cannot impersonate a human member.
-
-## Tokens And Service Accounts
-
-Owners and admins create managed service accounts using an identifier and display name. A service account has no plaintext secret and is not a human member. Tokens are typed `user` or `service`, have SHA-256 digests only in persisted state, are returned once at issuance, can be revoked, and must expire within 90 days.
-
-`issueToken` remains the human-token API. `issueServiceToken` requires a live service account and a nonempty, bounded list of scope entries. Every entry names an existing `{ projectId, environmentId }` and a nonempty subset of service-account scoped permissions. Authentication validates token digest, expiry, revocation, account state, and scope. A service actor is an in-memory authenticated capability returned only by `authenticateToken`; constructing an object with a token id is rejected. Each scoped method resolves that token's persisted scope, expiry, revocation, and account state again before acting. Rotation revokes the prior token and creates the replacement in one locked mutation; `disableServiceAccount` immediately revokes all of its live tokens. No reusable plaintext token is stored.
-
-## Audit Integrity And Export
-
-Schema v3 uses a per-organization append-only SHA-256 chain. Each record includes `sequence`, `previousHash`, and `recordHash`; the organization anchor supplies the sequence and hash before the retained window. `exportAudit` returns the anchor, records, and an integrity result. `verifyAuditExport` is public and detects changes to a record, record order, sequence, or chain link. Exports contain audit metadata only and never include token plaintext or other secrets.
-
-Schema v1 migrates through v2 to v3. Legacy `member` becomes `developer`; typed user tokens replace legacy `memberId` token bindings; legacy audit rows are replayed into a validated v3 SHA-256 chain. Unknown fields, malformed references, invalid token scopes, invalid service-account references, and invalid chains fail closed.
-
-Audit retention is bounded to 90 days and 1,000 records per organization. Pruning does not silently sever the chain: the last pruned record becomes the retained audit anchor. Sanitized evidence is retained for 30 days and capped at 100 records per organization. Owners and admins may explicitly delete evidence; deletion is tenant- and project-bound and audited. `deleteProject` removes that tenant project's environments, scenarios, evidence, and scoped service tokens in the same locked mutation. Audit export is restricted to `audit.export`; data deletion is restricted to `data.delete`.
-
-## Identity And Incident Response
-
-`TeamIdentityProvider` is a future integration boundary only. The single provided implementation, `createDisabledIdentityProvider`, performs no I/O and always denies authentication. No OIDC, SAML, SSO, SCIM, or remote identity protocol is implemented.
-
-If a token is exposed, an owner or authorized admin must revoke it, remove it from local logs or CI output, rotate or issue a short-lived replacement, and inspect `exportAudit` with `verifyAuditExport`. If the integrity result is false or the store fails validation, stop using the store, preserve the file for local investigation, restore only a reviewed local backup, and do not manually repair records or bypass validation. If evidence is incorrectly retained, use explicit evidence deletion or `pruneRetention`; both actions are audited.
-
-## Verification
-
-```bash
-npm run typecheck
-npm test -- --run test/teamControl.test.ts
-```
-
-## Explicit Non-Goals
-
-- No hosted API, public endpoint, deployment, dashboard, cloud sync, billing, SSO, SCIM, or generic project management.
-- No raw traffic, source code, secrets, or automatic artifact upload.
-- No compliance, legal-hold, immutable-storage, or distributed-isolation claim.