> For the complete documentation index, see [llms.txt](https://faction-os.gitbook.io/faction-os-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://faction-os.gitbook.io/faction-os-docs/docs/release.md). # Release Guide ## Current Release Target The current release target is a GitHub release and local-only repository workflow. The project is not currently npm-first for the full workspace. ## Release Readiness Gates Run: ```bash npm ci --no-audit --no-fund npm run format:check npm run lint npm run typecheck --workspaces --if-present npm --workspace @factionos/public-website run typecheck npm --workspace @factionos/public-website run build npm --workspace @factionos/public-website run check:links npm test npm run build --workspaces --if-present npm run media:check npm run media:visual:check npm run media:demo:check npm run media:drafts:check npm run battlefield:check npm run media:gates:check npm run release:hosted-smoke -- --no-network npm run security:secrets git diff --check ``` ## Phase 20 Command Center Release Evidence Map Phase 20 local orchestration claims are owned by `.spec_system/specs/phase20-session11-release-evidence-and-event-privacy/release-evidence.md`. Use that matrix before release notes describe terminal, Git, campaign, file, guarded action, managed hero lifecycle, container, template, or channel intake behavior as executable. Focused Phase 20 command-center gates: ```bash npm --workspace packages/protocol run typecheck npm --workspace apps/server run typecheck npm --workspace apps/web run typecheck npm test npm run test:e2e -- --project=app-desktop tests/e2e/orchestration-command-center.e2e.ts git diff --check ``` Record the result of each focused command in `.spec_system/specs/phase20-session11-release-evidence-and-event-privacy/release-evidence.md` before drafting release notes. Treat missing PTY, Docker, Apple Containers, Cloudflare credentials, production hosts, provider credentials, or external webhook trust as `unavailable` or `no-claim` evidence, not as proof that a local executor path failed. Do not promote Git push, generic webhook/chat auto-execution, hosted/Worker command bridges, remote access, arbitrary Docker commands, provider model/permission/isolation mutation, production-hosted Command Center validation, hosted identity/storage, public replay hosting, or trusted unified erasure unless a later release evidence matrix adds tests, docs, and source-owned validation for that path. Command-center release claims and no-claim boundaries are owned by these files: | Area | Docs owner | Test owner | Release boundary | | ---------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Protocol contracts, event parsers, blocked fields, and enum handling | `packages/protocol/README_protocol.md` | `packages/protocol/tests/orchestration.test.ts`, `packages/protocol/tests/orchestrationCommandCenter.test.ts` | Protocol may define only compact public shapes; it does not itself prove server execution. | | Queue terminal, Git, file, guarded action, container, campaign, channel, diagnostics, and export behavior | `apps/server/README_server.md`, `docs/api/README_api.md` | `apps/server/tests/taskExecutionCoordinator.test.ts`, `apps/server/tests/taskExecutionCoordinator.container.test.ts`, `apps/server/tests/planCampaignExecutableDispatch.test.ts`, `apps/server/tests/planCampaignDagRecovery.test.ts`, `apps/server/tests/fileMutationManager.test.ts`, `apps/server/tests/managedAgentSessionManager.test.ts`, `apps/server/tests/channelCommandRoutes.test.ts`, `apps/server/tests/commandCenterRoutes.test.ts`, `apps/server/tests/exportRoute.test.ts` | Server claims are local-first and manager-owned; optional runtime absence must be unavailable, not a failed or hidden execution claim. | | Product-facing workbenches, rows, action verbs, retry/unavailable copy, and WebSocket normalization | `apps/web/README_web.md`, `.spec_system/PRD/PRD_UX.md` | `apps/web/tests/QueueWorkbench.test.tsx`, `apps/web/tests/CampaignWorkbench.test.tsx`, `apps/web/tests/FileGitWorkbench.test.tsx`, `apps/web/tests/HeroLineageWorkbench.test.tsx`, `apps/web/tests/ChannelCommandPanel.test.tsx`, `apps/web/tests/wsClientPrivacy.test.ts` | Web labels may use action verbs only where a local executor path or truthful unavailable state is proven. | | Browser release evidence for create or approve, dispatch or execute, observe, recover, unavailable states, and broad privacy | `docs/release.md`, `docs/privacy-and-security.md` | `tests/e2e/orchestration-command-center.e2e.ts` | Local browser evidence is not production-hosted validation, hosted identity proof, remote execution proof, or formal certification. | | Privacy, security, exports, diagnostics, webhook/channel intake, external transfer, and local-only data inventory | `docs/privacy-and-security.md`, `.spec_system/SECURITY-COMPLIANCE.md` | The protocol, server, web, export, and e2e owners listed above | Broad rows, events, exports, diagnostics, docs examples, and UI rows must not expose raw commands, command output, Git output, diffs, file contents, patch bodies, tokens, provider payloads, webhook bodies, secrets, or broad absolute paths. | Release wording may claim local execution only for the paths with evidence in the matrix. Keep these as no-claim or unavailable unless a later source-backed release record proves them: hosted identity, hosted storage, public replay hosting, trusted unified erasure, production-hosted Command Center validation, Cloudflare-authorized deploy evidence, remote access, Worker command bridges, generic webhook or chat auto-execution, provider model/permission/isolation mutation, arbitrary Docker commands, and Git push through queue or campaign. For Phase 08 Session 08 release-candidate closeout, record each command with one of `pass`, `fail`, `blocked`, `unavailable`, `no-claim`, or `prior evidence` in `.spec_system/archive/phases/phase_08/release_candidate_validation_record.md`. Run the local-first release gate plan in this order: ```bash npm ci --no-audit --no-fund npm run format:check npm run lint npm run typecheck --workspaces --if-present npm --workspace @factionos/public-website run typecheck npm --workspace @factionos/public-website run build npm --workspace @factionos/public-website run check:links npm test npm run build --workspaces --if-present npm run media:check npm run media:visual:check npm run media:demo:check npm run media:drafts:check npm run battlefield:check npm run media:gates:check npm run release:hosted-smoke -- --no-network --json npm run security:secrets git diff --check ``` Then run focused Phase 08 release checks where the local environment allows: ```bash npx vitest run packages/protocol/tests/erasure.test.ts apps/server/tests/localErasure.test.ts apps/server/tests/erasureRoute.test.ts apps/server/tests/erasureInventory.test.ts apps/warroom/tests/roomErasure.test.ts apps/warroom/tests/erasureInventory.test.ts apps/web/tests/localErasure.test.ts apps/web/tests/LocalErasurePanel.test.tsx packages/protocol/tests/hostedConfig.test.ts packages/protocol/tests/hostedIdentity.test.ts packages/protocol/tests/hostedPersistence.test.ts packages/protocol/tests/hostedAnalytics.test.ts packages/protocol/tests/hostedOperations.test.ts apps/server/tests/hostedConfigDiagnostics.test.ts apps/server/tests/hostedIdentityDiagnostics.test.ts apps/server/tests/hostedPersistenceDiagnostics.test.ts apps/server/tests/hostedOperationsDiagnostics.test.ts apps/web/tests/hostedConfig.test.ts apps/web/tests/hostedIdentity.test.ts apps/web/tests/hostedPersistence.test.ts apps/web/tests/hostedAnalytics.test.ts apps/web/tests/hostedOperations.test.ts tests/productionHostedSmoke.test.ts apps/web/tests/MobileAccessibility.test.tsx tests/mediaReleaseGates.test.ts tests/mediaVisualPromotion.test.ts tests/publicDemoMedia.test.ts packages/protocol/tests/mediaCatalog.test.ts apps/web/tests/mediaCatalog.test.ts npm run test:e2e -- --project=app-desktop --project=app-mobile tests/e2e/app.e2e.ts npm run test:e2e -- --project=public-demo-desktop --project=public-demo-mobile tests/e2e/public-demo.e2e.ts ``` Run live hosted validation only from a safe release environment with explicit public HTTPS targets and no credentials in command output: ```bash npm run release:hosted-smoke -- --json ``` For the main public website, the deploy gate is Cloudflare Pages for the static Astro output only. Before any deployed website release claim, run and record: ```bash npm --workspace @factionos/public-website run typecheck npm --workspace @factionos/public-website run build npm --workspace @factionos/public-website run check:links ``` Then record the result of `.github/workflows/public-website-deploy.yml` or the manual `wrangler pages deploy public-website/dist` fallback as one of `passed`, `failed`, `skipped`, `blocked`, or `unavailable`. A local typecheck, local build, built-site checker pass, workflow file, Cloudflare dashboard setting, or credential-skipped deploy is not production-hosted validation by itself. Production-hosted evidence for `https://faction-os.com/` requires a live Pages deploy and bounded HTTPS homepage smoke with sanitized output. Missing Cloudflare credentials, missing dashboard access, absent domain activation, or an unavailable live smoke must be recorded as no-claim evidence, not as a failed local release gate. Phase 16 Session 05 public website launch review on 2026-06-02 recorded this release outcome: | Gate | Status | Evidence | | ------------------------------------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | Website typecheck | passed | Package typecheck passed under Node `26.2.0` and npm `11.16.0`. | | Website build | passed | Package build produced 31 static pages. | | Built-site checker | passed | Static checker passed with 31 routes and 2185 links. | | Root command gates | passed | Root format, lint, typecheck, build, secret scan, and `git diff --check` passed. | | Manual browser QA | passed | 19 critical routes were checked at 360px, 768px, 1280px, and 1600px, including nav, CTAs, keyboard focus, images, reduced motion, and overflow checks. | | Static privacy boundary | passed | Built output has no executable analytics, hosted form, browser storage write, cookie write, beacon, fetch, WebSocket, or EventSource patterns. | | Cloudflare Pages workflow readiness | passed | Dedicated workflow and manual Wrangler fallback are documented for `public-website/dist`. | | Cloudflare deploy credentials | unavailable | Local launch-review shell did not provide Cloudflare deploy credentials. | | Cloudflare dashboard/domain evidence | unavailable | Dashboard and domain status were not available in the local launch-review shell. | | Live Pages deploy | no-claim | No authorized deploy ran in the local launch-review shell. | | Production HTTPS smoke | no-claim | No bounded HTTPS smoke ran because live deploy evidence was unavailable. | | Legal/privacy owner review | pending | Legal and privacy pages remain pre-review where marked; no formal owner approval is recorded. | The resulting release posture is local static launch readiness for an authorized deployment path. It is not proof that `https://faction-os.com/` is live, domain-active, legally approved, formally certified, analytics-enabled, hosted-identity-backed, hosted-storage-backed, or trusted-erasure-backed. If live hosted targets, Cloudflare credentials, production app host, physical mobile devices, manual assistive-technology review, or third-party certification are unavailable, record unavailable/no-claim evidence rather than treating local-first workflows as failed. Session 08 must not convert local browser, mocked Worker, no-network smoke, docs-only, or prior session evidence into production-hosted, hosted identity, formal certification, broad media readiness, real executor, active analytics/push/remote, or full trusted unified erasure claims. Session 08 documentation sync must use this map after gate outcomes are known: | Area | Files | Required sync | | --------------------------- | ------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- | | Product status | `.spec_system/PRD/PRD.md`, `docs/PRD.md`, `.spec_system/archive/phases/phase_08/PRD_phase_08.md` | Phase 08 status, release readiness or blockers, and no-claim wording. | | UX status | `.spec_system/PRD/PRD_UX.md`, `docs/PRD_UX.md` | Local browser evidence, certification no-claim, production-hosted separation, and media UX blockers. | | Security posture | `.spec_system/SECURITY-COMPLIANCE.md`, `.spec_system/CONSIDERATIONS.md` | Open findings, residual risks, carry-forward lessons, and sanitized evidence boundaries. | | Release and deployment | `docs/release.md`, `docs/deployment.md` | Gate outcomes, hosted smoke results, release notes inputs, rollback notes, and deployed-target no-claim states. | | Privacy and hosted services | `docs/privacy-and-security.md`, `docs/hosted-services.md`, `docs/environments.md` | Erasure scope, hosted identity/storage/analytics/push/remote disabled states, reserved variables, and sensitive-output boundaries. | | Legacy and media | `docs/legacy-consolidation.md`, `docs/media/media-assets.md` | Decommission dispositions, retained evidence, media release gates, conditional media blockers, and quarantine policy. | | Public demo | `public-demo/docs_public-demo/validation.md` | Public-demo local browser evidence, service-worker/cache expectations, production URL smoke, and media/cache status. | Session 08 release-candidate evidence is recorded in `.spec_system/archive/phases/phase_08/release_candidate_validation_record.md`. As of the current implementation closeout, local install, format, lint, workspace typecheck, full Vitest, workspace build, media gates, focused Phase 08 Vitest, app desktop/mobile Playwright, and public-demo desktop/mobile Playwright have passing local evidence. App Playwright recorded one recovered mobile flaky retry; preserve that note in release handoff rather than presenting the gate as stronger than it is. No-network hosted smoke is passing only as unavailable/no-claim evidence. Live hosted smoke currently blocks deployed public demo and Worker release claims with sanitized issue codes and keeps the optional production app shell unavailable. These blockers do not fail the local-first release posture, but they prohibit deployed-hosted release copy until the affected targets are updated and smoke passes. Media release readiness is blocked unless the focused media gates and `npm run media:gates:check` pass. The approved media catalog records are `media.battlefield.background` and `media.battlefield.heroStandees`, covering `apps/web/public/battlefield/background.webp` and the five `apps/web/public/battlefield/heroes/*.webp` standees with matching `public-demo/assets/battlefield/` mirrors. Conditional public-demo speech, music, portraits, showcase art, install icons, generated drafts, and reference assets must retain blockers and must not be described as release-ready. For Phase 02 browser-facing release candidates, also run: ```bash npm run battlefield:check npm run test:e2e -- --project=app-desktop --project=app-mobile tests/e2e/app.e2e.ts npm run test:e2e -- --project=public-demo-desktop --project=public-demo-mobile tests/e2e/public-demo.e2e.ts ``` Those same browser checks are also Phase 04 media closeout evidence for failed media fallbacks, reduced motion, visible audio equivalents, public-demo offline reload, service-worker behavior, and privacy-safe browser guards. Before a release candidate, also verify: * `README.md`, package READMEs, and `docs/` describe current shipped behavior. * `public-website/README_public-website.md` describes the shipped static site surface and its package-local build posture. * Stable docs distinguish shipped, planned, deferred, stubbed, and historical evidence-only behavior. * `LICENSE`, `CONTRIBUTING.md`, package metadata, and stable docs remain aligned with the current proprietary/CLA posture. * No obsolete licensing or reuse-limit language remains in stable docs. * No raw service tokens, OAuth client IDs, probe responses, or local credentials are added. * Hosted auth, hosted storage, analytics, War Room, and adapters are described as optional unless source and tests prove they are required. * War Room release candidates verify `npm --workspace @factionos/warroom run typecheck`, focused Worker/web War Room tests, the deploy workflow health smoke check, and a bounded `/health` probe for the configured Worker URL. * War Room docs and UI must keep disabled, invalid, unreachable, timed-out, rate-limited, malformed, healthy, and connected states visible without claiming hosted identity, trusted erasure, public replay hosting, hosted storage, or analytics. * Anthropic provider transfer is documented as requiring both `ANTHROPIC_API_KEY` and `FACTIONOS_ALLOW_LLM_PROVIDER_TRANSFER=true`. * Current exports, archives, replay-share payloads, LLM route inputs, and adapter compact payloads keep redaction tests and docs aligned. * Historical artifacts are not deleted until the decommission gates below are complete. * Quarantined media from `EXAMPLES/` remains reference-only and is not promoted directly. Generated or owned replacements need provenance, usage-rights, attribution, optimization, metadata, browser-support, and size review. * Phase 04 media work uses `.spec_system/archive/phases/phase_04/media_gap_matrix.md` as the source-backed routing record for current tracked media, planned media, prototype-only evidence, rejected media, unknown provenance, and deferrals. * Newly promoted media must have catalog or promotion evidence for source, rights, attribution, optimized output, dimensions or duration, byte size, metadata cleanup, browser support, fallback behavior, accessibility, privacy, and product use before release. * Public demo audio and music must remain gesture-compatible or opt-in, standalone, cache-aware, and visibly equivalent when muted, blocked, or unavailable. * Public demo deploy workflow succeeds if `public-demo/` changed. * Public website release posture is Cloudflare Pages. Before any deployed release claim, validate the static site with `npm --workspace @factionos/public-website run typecheck` and `npm --workspace @factionos/public-website run build`, then run `npm --workspace @factionos/public-website run check:links` against the fresh build output. Record the `.github/workflows/public-website-deploy.yml` or manual Wrangler deploy result as `passed`, `failed`, `skipped`, `blocked`, or `unavailable`, and keep hosted website evidence claim-scoped to a live Pages deploy plus bounded HTTPS homepage smoke. The static checker verifies published routes, draft exclusion, RSS, sitemap, robots, metadata, approved links, guarded copy, hosted-form absence, browser-storage absence, runtime-network absence, and analytics/tracker absence without making a production-hosted validation claim. * Public demo service-worker `CACHE_VERSION` is bumped when the precache list changes or when already-precached shell content needs a forced offline-cache refresh; Phase 04 media validation currently uses `factionos-demo-v9`. * Phase 02 and Phase 04 browser evidence covers local app and public demo desktop/mobile validation. Production-hosted validation requires matching release-record evidence. * Phase 05 browser evidence covers local app desktop/mobile War Room states for disabled, diagnostics, join, pending, create, approved, connected, reconnecting, unavailable, and redacted remote-context behavior. It does not replace deployed Worker smoke checks, production-hosted app validation, trusted identity review, mobile certification, or full erasure evidence. * Phase 06 release candidates must use `.spec_system/archive/phases/phase_06/collaboration_isolation_safety_baseline.md`, `.spec_system/archive/phases/phase_06/phase06_requirement_routing_matrix.md`, and `.spec_system/archive/phases/phase_06/mobile_accessibility_acceptance_checklist.md` as the collaboration, isolation, mobile, accessibility, and deferral baseline. Do not describe Session 01 artifacts as hosted identity, production-hosted validation, mobile certification, remote execution, Docker execution, public replay hosting, analytics, or trusted erasure. * Phase 06 closeout evidence is recorded in `.spec_system/archive/sessions/phase06-session07-collaboration-isolation-and-mobile-validation-closeout/`. It can support local regression review for room-local authority, safe collaboration frames, isolation diagnostics, compact CLI/hook diagnostics, and app desktop/mobile behavior. Release candidates still require deployed app or Worker smoke where applicable, production-hosted validation if a hosted claim is made, and release-record trusted erasure/decommission review before any release-grade deletion or cleanup claim. * Phase 07 Session 01 baseline artifacts live in `.spec_system/archive/phases/phase_07/hosted_services_requirements_privacy_baseline.md`, `.spec_system/archive/phases/phase_07/phase07_requirement_routing_matrix.md`, and `.spec_system/archive/phases/phase_07/hosted_payload_privacy_blocklist.md`. They define guardrails only. Do not describe them as hosted identity, hosted storage, analytics capture, push delivery, public replay hosting, remote access, hosted diagnostics, production-hosted validation, trusted erasure, certification, release hardening, or decommission completion. * Phase 07 Session 02 hosted config checks must pass before any hosted config claim is made: protocol hosted config tests, server hosted config unit tests, `/diagnostics/hosted-config` route tests, browser hosted config helper tests, existing War Room diagnostics tests, and docs/env review. Diagnostics must remain status-only and browser helpers must keep malformed, credentialed, reserved, blocked, or absent values in local-only mode. * Phase 07 Session 03 hosted identity checks must pass before any hosted identity guardrail claim is made: protocol hosted identity tests, server `/diagnostics/hosted-identity` route tests, browser hosted identity helper tests, and docs review for account lifecycle, consent, revocation, authorization, role/audit, local-only fallback, and Worker non-overclaim wording. These checks prove guardrails only. They do not prove OAuth, SSO, organization membership, account UI, Supabase auth, analytics consent, public collaboration safety, production audit proof, production-hosted validation, or trusted erasure. * Phase 07 Session 04 hosted persistence and public replay checks must pass before any storage or replay guardrail claim is made: protocol hosted persistence tests, server `/diagnostics/hosted-persistence` route tests, browser hosted persistence helper tests, replay-link local fragment regression tests, and docs review for data eligibility, blocked payloads, storage requirements, public replay consent, payload caps, redaction, expiration, takedown, no-index posture, abuse controls, local-only fallback, and Phase 08 erasure deferrals. These checks prove guardrails only. They do not prove Supabase readiness, RLS, bucket policy, migrations, account-backed persistence, public replay hosting, release-grade deletion, production-hosted validation, or trusted erasure. * Phase 07 Session 05 analytics checks must pass before any analytics guardrail claim is made: protocol hosted analytics tests, hosted config reserved-variable regression tests, browser hosted analytics helper tests, runtime sender send/no-send tests, Settings drawer analytics status tests, and docs review for disabled default, consent, opt-out, self-hosted Umami posture, payload allowlists, blocked categories, local-only fallback, and replaceability. These checks prove approved minimized `/api/send` behavior only. They do not prove tracking scripts, server-side ingestion, dashboards, recorder, heatmaps, session replay, account-backed consent storage, production-hosted validation, or trusted erasure. * Phase 07 Session 06 push, remote access, tunnel, and operator diagnostics checks must pass before any hosted operation guardrail claim is made: protocol hosted operation tests, hosted config reserved-variable regression tests, server `/diagnostics/hosted-operations` route tests, CLI diagnostics and runtime output tests, browser hosted operation helper tests, notification and service worker guardrail tests, and docs/env review for local notification posture, disabled Web Push, VAPID private key boundaries, loopback-only diagnostics, remote access and tunnel unavailable states, blocked payload labels, unsupported claim labels, and local-only fallback. These checks prove guardrails only. They do not prove push delivery, push subscription storage, VAPID runtime use, Cloudflare Tunnel, remote access, remote execution, hosted diagnostic agents, production-hosted validation, or trusted erasure. * Future Phase 07 release candidates must prove public-client config, server-only secrets, deploy-only credentials, disabled defaults, consent, minimization, redaction, authorization, unavailable states, and local-first fallback before any hosted surface is listed as active. * Phase 08 records scoped release-candidate evidence for trusted-erasure boundaries, production-hosted app and Worker validation, certification, release hardening, and legacy decommission. Do not close those gates using Session 03 identity diagnostics, Session 04 hosted persistence diagnostics, Session 05 analytics readiness and payload tests, or Session 06 hosted operation diagnostics and notification guardrail tests. * Phase 08 Session 01 baseline artifacts live in `.spec_system/archive/phases/phase_08/release_requirements_risk_baseline.md`, `.spec_system/archive/phases/phase_08/phase08_requirement_routing_matrix.md`, `.spec_system/archive/phases/phase_08/phase08_release_risk_matrix.md`, and `.spec_system/archive/phases/phase_08/decommission_approval_matrix.md`. They define claim gates, routing, risk ownership, and candidate-only decommission inputs only. They do not prove trusted erasure, hosted identity, production-hosted validation, certification, broader media readiness, release completion, or deletion approval. * Phase 08 Session 02 erasure contract evidence lives in `.spec_system/archive/phases/phase_08/unified_erasure_inventory.md`, `packages/protocol/src/erasure.ts`, `apps/server/src/lib/erasureInventory.ts`, and `apps/warroom/src/erasureInventory.ts`. This evidence proves an inventory, shared vocabulary, read-only local/server summaries, read-only Worker summaries, blocked payload labels, and unsupported-claim labels only. It does not prove deletion, purge, browser erasure controls, Worker room erasure, hosted account deletion, public replay takedown, production-hosted validation, or trusted unified erasure. Release notes must keep `P06-S07-ERASURE` open until Sessions 03, 04, and 08 validate runtime deletion, Worker handling, audit, verification, and no-overclaim wording. * Phase 08 Session 03 local/browser erasure evidence lives in `apps/server/src/lib/localErasure.ts`, `apps/server/src/routes/erasure.ts`, `apps/cli/src/lib/erasureClient.js`, `apps/cli/src/commands/erase.js`, `apps/web/src/lib/localErasure.ts`, `apps/web/src/store/useLocalErasureStore.ts`, `apps/web/src/components/LocalErasurePanel.tsx`, and focused protocol, server, CLI, and web tests. This evidence proves dry-run, explicit local confirmation, idempotency, redacted audit summaries, partial-failure reporting, local/browser cleanup, and verification for release-scoped local and browser state only. It does not prove Worker Durable Object erasure, hosted account/storage/analytics deletion, public replay takedown, push subscription deletion, remote-access deletion, broad workspace-file deletion, production-hosted validation, or full trusted unified erasure. * Phase 08 Session 04 Worker room-state erasure evidence lives in `packages/protocol/src/warroom.ts`, `packages/protocol/src/erasure.ts`, `apps/warroom/src/roomErasure.ts`, `apps/warroom/src/index.ts`, `apps/web/src/lib/warRoomClient.ts`, `apps/web/src/store/useWarRoomStore.ts`, `apps/web/src/components/WarRoomPanel.tsx`, server/web hosted identity helpers, and focused protocol, Worker, server, and web tests. This evidence proves leader-authorized preview and confirmed deletion for one Worker Durable Object room record with expected revision, exact confirmation, idempotency, redacted receipts, socket closure, partial-failure reporting, and post-delete verification. It does not prove browser-local erasure, local filesystem erasure, hosted account/storage/analytics deletion, production-hosted Worker validation, public collaboration safety, or full trusted unified erasure. Hosted identity remains a release no-claim gate: no SSO, organization membership, account UI, analytics consent runtime, production audit proof, public collaboration safety, or account-backed authorization claim is made from room-local Worker authority. * Phase 08 Session 05 production-hosted validation evidence lives in `scripts/check-production-hosted-smoke.mjs`, `tests/productionHostedSmoke.test.ts`, and `.spec_system/archive/phases/phase_08/production_hosted_validation_evidence.md`. The release smoke command validates deployed public demo and Worker targets when network is enabled, records no-claim unavailable states when network or optional app hosts are absent, and emits sanitized target ids, safe hostnames, statuses, booleans, timing buckets, docs paths, and issue codes only. This evidence is distinct from local browser, mocked Worker, CI-only, and documentation-only evidence. It does not prove hosted identity, hosted storage, analytics capture, public replay hosting, push delivery, remote access, Cloudflare Tunnel, production account behavior, certification, release-candidate completion, or trusted unified erasure. * Phase 08 Session 06 mobile/accessibility evidence lives in `.spec_system/archive/phases/phase_08/mobile_accessibility_certification_evidence.md`, `tests/e2e/app.e2e.ts`, `tests/e2e/public-demo.e2e.ts`, `tests/e2e/support/browserGuards.ts`, and `apps/web/tests/MobileAccessibility.test.tsx`. Run: ```bash npx vitest run apps/web/tests/MobileAccessibility.test.tsx npx biome check tests/e2e/support/browserGuards.ts tests/e2e/app.e2e.ts tests/e2e/public-demo.e2e.ts apps/web/tests/MobileAccessibility.test.tsx public-demo/index.html npm run test:e2e -- --project=app-desktop --project=app-mobile tests/e2e/app.e2e.ts npm run test:e2e -- --project=public-demo-desktop --project=public-demo-mobile tests/e2e/public-demo.e2e.ts git diff --check ``` This evidence covers local browser desktop/mobile emulation, focused component regressions, screenshots, text-fit/overflow/focus/accessible-name checks, visible fallbacks, and no-overclaim copy. It is not formal WCAG certification, physical-device mobile certification, third-party audit evidence, production-hosted validation, hosted identity proof, analytics capture, Web Push delivery, remote access validation, or trusted erasure. * Phase 07 is complete and closed out (Session 07). Closeout validated the hosted-services and analytics guardrails (20 focused test files / 183 tests, full suite 2186 passed / 1 skipped, format/lint/typecheck/build/secret-scan over 886 tracked files) and confirmed requirement closure for P07-R001 through R025. This proves guardrails only; the remaining release gates above stay open for Phase 08. ## Version Alignment Keep these intentionally aligned unless a release note explains the mismatch: * Root `package.json` * Workspace `package.json` files * `packages/protocol/src/index.ts` runtime version ## Release Notes A useful release note should cover: * User-facing changes. * Breaking protocol or API changes. * New or changed environment variables. * Privacy, security, hosted-service, analytics, or adapter impact. * Migration steps for hook settings or local state. * Known limitations that remain planned work. ## Decommission Gates The PRD says these files and ignored intake areas are temporary until their unique value is captured: * `EXAMPLES/findings/` * `EXAMPLES/1st-pass-artifacts/` * `EXAMPLES/REPORT.md` * `EXAMPLES/REPORT.html` * `docs/PROGRESS.md` Do not delete them as part of a routine release unless the stable docs, this decommission matrix, and Phase 08 release-hardening work say each item is covered. The Phase 08 Session 01 decommission matrix at `.spec_system/archive/phases/phase_08/decommission_approval_matrix.md` is a candidate inventory only. Session 07 must record final dispositions and rerun affected release, media, quarantine, sensitive-output, docs, whitespace, ASCII, and LF gates before deletion or reduction. | Source | Decommission gate | | --------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `EXAMPLES/1st-pass-artifacts/` | Hook contracts, manifests, templates, Docker recipe, copied package evidence, service-config risks, and media/model references are captured, rejected, or assigned to a future phase. | | `EXAMPLES/findings/` | Each finding family is classified as delete, archive, keep, or future-work evidence after API, event, hook, service, prompt, and media value is captured elsewhere. | | `EXAMPLES/REPORT.md` and `EXAMPLES/REPORT.html` | Migration pointers and unique findings are represented in the PRD, UX PRD, API docs, media docs, security docs, or this consolidation record. | | `docs/PROGRESS.md` | Retained milestones are recoverable from stable docs and Git history, and old phase labels are no longer needed for resume context. | | Sensitive service-discovery, probe, prompt, token, OAuth, and path evidence | Stable docs preserve posture conclusions only and do not retain raw values, prompt bodies, probe dumps, or sensitive local paths. | | Ignored `EXAMPLES/` media intake | Reference inventory captures standards, gaps, hashes, provenance concerns, and final disposition; generated or owned replacements have rights, attribution, optimization, browser support, metadata, and size-budget decisions before release. | For each deletion or major reduction, confirm: * Unique requirements, contracts, risks, and decisions are captured elsewhere. * License and privacy conclusions are preserved without raw tokens, OAuth IDs, probe responses, prompt bodies, or sensitive local paths. * API, event, hook, adapter, hosted-service, and media-provenance references needed for future work are represented in stable docs. * Git history remains sufficient for build-history recovery. ## Phase 08 Session 07 Decommission And Media Gate Session 07 records final fail-closed dispositions in `.spec_system/archive/phases/phase_08/legacy_decommission_media_release_gate.md`. The current release posture is: * Ignored `EXAMPLES/findings/`, `EXAMPLES/1st-pass-artifacts/`, and `EXAMPLES/REPORT.*` are retained as ignored traceability evidence. * `docs/PROGRESS.md` remains tracked and retained until final release-candidate documentation sync decides otherwise. * Ignored legacy media, generated/raw provider staging, copied build output, raw sensitive historical evidence, and quarantined media stay blocked from release promotion, runtime imports, public-demo cache entries, and stable-doc excerpts. * Archived spec-system sessions and phase artifacts remain retained evidence. Session 07 does not approve broad deletion, archive movement, report reduction, public-demo cache changes, or media promotion. Any later cleanup must start from the Session 07 action record, preserve stable replacement docs, and rerun affected gates. After Session 07 docs or cleanup decisions, run and record: ```bash npm run media:gates:check npm run media:check npm run media:visual:check npm run media:demo:check npm run media:drafts:check npm run battlefield:check npm run security:secrets git diff --check ``` Also run ASCII/LF validation over changed tracked files. Run focused Biome or Vitest checks only when scripts, tests, media config, public-demo cache logic, or package code changes. For Session 07-only changes, final release-candidate validation remains owned by S0808. No release copy should treat Session 07 as trusted unified erasure, hosted identity proof, production-hosted app validation, formal accessibility/mobile certification, broad media readiness, or final release-candidate closeout. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://faction-os.gitbook.io/faction-os-docs/docs/release.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.