> 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/.spec_system/archive/phases/phase_07/hosted_persistence_public_replay_boundaries.md). # Hosted Persistence and Public Replay Boundaries **Session ID**: `phase07-session04-hosted-persistence-and-public-replay-boundaries` **Status**: Source-backed planned-state baseline **Created**: 2026-05-30 **Scope**: Hosted persistence eligibility, public replay requirements, local-only fallback, diagnostics, and Phase 08 erasure handoff *** ## Purpose This artifact defines what FactionOS may claim about hosted persistence and public replay during Phase 07. It is a guardrail baseline, not an activation of hosted storage, public replay hosting, account-backed persistence, database schemas, buckets, uploads, migrations, or trusted erasure. FactionOS remains local-first. Core server, web, hooks, CLI, adapters, Worker fallback, local replay links, local export, local archive, scan, media draft, backup, and diagnostics workflows must continue to work without Supabase, hosted accounts, storage buckets, public replay hosts, Cloudflare credentials, analytics, push, remote tunnels, or provider credentials. ## Source Ownership | Surface | Owner | Current state | | ------------------- | -------------------------------------------- | --------------------------------------------------- | | Shared vocabulary | `packages/protocol/src/hostedPersistence.ts` | Planned-state contracts and eligibility labels | | Local diagnostics | `apps/server/src/lib/hostedPersistence.ts` | Status-only local posture | | Browser helper copy | `apps/web/src/lib/hostedPersistence.ts` | Unavailable storage and disabled public replay copy | | Replay links | `apps/web/src/lib/replayLink.ts` | Redacted local URL fragments only | | Stable docs | `docs/`, package README files | Current limitations and Phase 08 handoffs | ## Status Vocabulary | Status | Meaning | | ------------- | ------------------------------------------------------------------------------------------------------------------ | | `unavailable` | No hosted persistence runtime, storage client, bucket, database, upload endpoint, or public replay host is active. | | `planned` | Requirements are documented and diagnostics can describe the future posture without enabling hosted behavior. | | `local_only` | Current behavior stays in local browser, local server, local files, or room-local Worker state. | | `disabled` | Public replay hosting or hosted storage remains intentionally off even if reserved config placeholders exist. | | `unsupported` | A requested storage, public replay, deletion, takedown, or erasure claim is not available in this build. | No status in this artifact proves hosted storage, public replay hosting, release-grade deletion, production-hosted validation, or trusted unified erasure. ## Data Eligibility Categories | Category | Default handling | Examples | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | | `future_eligible` | May be considered for hosted storage only after server mediation, authorization, retention, export, deletion, and audit tests exist. | Coarse project metadata, public-safe feature flags, non-sensitive user preferences. | | `server_mediated_required` | Must never be written directly from browser-only code; future writes require authenticated server mediation or a reviewed equivalent. | Hosted account data, organization membership, replay publish decisions, takedown requests. | | `local_only` | Stays in local runtime or local files by default. | Replay buffers, archives, logs, backups, scan roots, settings snapshots, local auth hints. | | `redacted_only` | Only stable redacted summaries may cross a hosted boundary. Raw source values stay local. | Notice summaries, diagnostics counts, replay event labels, storage posture. | | `user_export_only` | User-triggered local export may include redacted output; hosted upload remains inactive. | CSV/JSON session export, archive review bundles. | | `blocked` | Must not be sent to hosted storage, public replay, diagnostics upload, analytics, push, remote access, Worker transfer, adapters, logs, or public docs by default. | Prompts, transcripts, file contents, commands, terminal output, secrets, broad local paths, export bodies, replay buffers, media drafts. | | `phase08_erasure_dependent` | Any future hosted persistence or deletion claim depends on Phase 08 trusted erasure design. | Account deletion, storage deletion, backup purge, Worker state deletion, archive and memory cleanup. | ## Blocked Hosted Payload Labels The following labels are blocked from hosted persistence and public replay by default: * `prompt_content` * `transcript_content` * `file_content` * `code_content` * `command_body` * `terminal_output` * `secret_value` * `credential_value` * `local_path` * `raw_env_dump` * `replay_buffer` * `export_body` * `archive_body` * `backup_payload` * `diagnostic_payload` * `log_payload` * `scan_payload` * `media_draft` * `war_room_payload` * `cloud_account_identifier` * `quarantined_historical_content` Future hosted features must reject, redact, or minimize these labels before any transfer occurs and must prove that behavior with focused tests. ## Hosted Persistence Requirements Before hosted persistence can become active, a later accepted session must define and validate all of the following controls: | Requirement | Minimum bar before activation | | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | Server mediation | Authorization-sensitive writes go through the server boundary closest to protected data unless a later reviewed design proves a narrower boundary. | | Schema artifacts | Database schemas, migrations, bucket policies, RLS policies, indexes, seeds, and test fixtures ship in the same session as runtime behavior. | | Authorization tests | Account, organization, role, and resource ownership checks reject stale, missing, downgraded, or mismatched identity. | | Payload eligibility | Blocked categories are rejected before storage and redacted-only categories are minimized. | | Consent | Users or operators approve each hosted persistence surface before transfer. | | Retention | Retention windows and purge behavior are documented and testable. | | Export | Hosted account data has a documented export path before claims are made. | | Deletion | Deletion requests and completion evidence are scoped, audited, and distinct from Phase 08 trusted erasure. | | Audit | Access, write, export, delete, deny, and abuse-control outcomes produce stable reason codes without raw payloads. | | Abuse controls | Rate limits, duplicate action prevention, replay protection, timeout, retry, and failure states are visible and tested. | | Local fallback | Missing credentials or service outage keeps local workflows usable with bounded unavailable states. | ## Public Replay Hosting Requirements Current share links are redacted local URL fragments. They do not upload replay data, create hosted replay records, prove public collaboration safety, or activate public replay pages. Before public replay hosting can become active, a later accepted session must define and validate: * Explicit user consent before publishing. * Replay event caps, byte caps, and per-event redaction before upload. * Rejection of prompts, transcripts, file contents, commands, terminal output, secrets, broad local paths, exports, archives, scan payloads, media drafts, logs, backups, and War Room payloads. * Expiration, revocation, and deletion behavior for hosted replay records. * Takedown request intake, review, audit, and bounded response behavior. * No-index headers or metadata for public replay pages. * Abuse controls for publish, fetch, replay, delete, and takedown endpoints. * Public-safe error messages without stack traces, ids, tokens, paths, or raw payloads. * Local-only fallback when public replay hosting is disabled, absent, invalid, rate limited, or unavailable. ## Diagnostics Rules Hosted persistence diagnostics may expose only: * Version, generated timestamp, status labels, and reason codes. * Docs paths and requirement names. * Booleans such as local-only fallback, hosted persistence required, public replay hosting enabled, upload endpoint available, and storage client active. * Counts of eligibility categories, public replay requirements, blocked payload labels, and unsupported claims. Hosted persistence diagnostics must not expose: * Raw env values, tokens, service-role keys, storage keys, account ids, request bodies, local paths, prompts, commands, terminal output, replay buffers, exports, archives, logs, backups, scan payloads, media drafts, War Room payloads, or file contents. * Any claim that hosted storage, account-backed persistence, public replay hosting, release-grade deletion, production-hosted validation, or trusted erasure is active. ## Unsupported Claims The following claims are unsupported in this build: * `hosted_database` * `storage_bucket` * `storage_migration` * `browser_direct_storage_write` * `account_backed_persistence` * `hosted_replay_upload` * `public_replay_page` * `public_replay_indexing` * `replay_takedown_runtime` * `release_grade_deletion` * `trusted_erasure` * `production_hosted_validation` Docs, diagnostics, tests, and UI copy should use these labels when preventing overclaim drift. ## Local-Only Fallback When hosted persistence, Supabase, storage buckets, public replay hosting, or account identity are absent, blank, invalid, reserved, or disabled: * The local server still starts. * The web cockpit still renders local state. * Hooks, CLI, adapters, backup, export, replay, archive, scan, and public demo workflows remain credential-free. * Local share links continue to use `#replay=` URL fragments only. * Diagnostics return compact planned or unavailable posture instead of raw values or blank failure states. * Release docs continue to mark production-hosted validation and trusted unified erasure as Phase 08 work. ## Phase 08 Handoff Phase 08 remains the owner for trusted unified erasure, production-hosted validation, release hardening, mobile and WCAG certification, legacy decommission, and release-grade deletion claims. Session 04 may define requirements for future retention, export, deletion, expiration, takedown, abuse controls, and audit evidence, but it must not close trusted erasure for Worker storage, browser hints, archives, memory, settings, replay buffers, exports, diagnostics, logs, backups, valid spool state, workspace files, or future hosted data. ## Evidence Requirements * Shared source contracts start in `packages/protocol`. * Server and browser helpers consume shared protocol labels instead of duplicating strings. * Diagnostics tests prove status-only output and auth inheritance. * Replay tests prove current share links remain redacted local URL fragments. * Documentation distinguishes shipped, planned, disabled, unavailable, unsupported, and Phase 08 deferred states. * Validation records focused tests, typechecks, ASCII/LF checks, and `git diff --check` evidence before handoff. --- # 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/.spec_system/archive/phases/phase_07/hosted_persistence_public_replay_boundaries.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.