# Security Policy

## Supported Scope

Security review for this project is organized by distribution lane:

- **Source repository**: the authoritative interdisciplinary review surface. It carries `.github`, CODEOWNERS, runbooks, documentation, and documented distribution scripts.
- **external_complete**: the downloadable verification ZIP. It includes package-local verification witnesses and self-audit tooling, but it is not a web hosting root.
- **public_runtime_secure**: the minimal static hosting package. It intentionally excludes `docs/CODEX`, tools, verification witness bundles, service-worker/PWA shell caching, and `lab.html`.

Public web completion is not claimed until a real `PHASE1_HOSTING_ORIGIN` passes strict hosting-header verification.

## How To Report

Do not publish attack reproduction details in public issues, social media, screenshots, or shared documents before the maintainer has had a chance to assess them.

For a private source repository, use the private review channel by which you received the repository or package. If no private channel is available, request one from the maintainer before sending sensitive details.

For a future public GitHub repository, use GitHub Security Advisories when available. If Security Advisories are not enabled, contact the repository owner listed in CODEOWNERS and ask for a private disclosure channel before sharing minimal reproduction material.

Please include:

- the affected lane: source repository, `external_complete`, `public_runtime_secure`, or hosted deployment;
- the exact commit hash or ZIP filename and SHA-256;
- reproduction steps with the smallest non-destructive example;
- whether the finding requires local filesystem access, browser storage from the same origin, hosted HTTPS access, or a malicious package mirror;
- any console errors, network requests, or generated evidence files.

## Authorized Testing Boundary (Safe Testing Boundary)

The testing boundary is designed to keep review useful without turning a
distributed research package into an uncontrolled attack surface. In ordinary
language: review the files, run the documented local checks, and report findings
privately; do not run destructive, high-rate, persistent, or public tests unless
the maintainer has explicitly approved that separate exercise.

Allowed without prior written approval:

- static review of files included in the source repository or distributed ZIPs;
- local execution of documented runbooks and package self-audits;
- local browser testing against your own extracted copy of `public_runtime_secure`;
- AI-assisted or automated vulnerability discovery when it stays within the
  same local/static boundaries, does not generate destructive test inputs, and
  does not leave persistent state on the maintainer's machine or browser
  profile;
- reporting outdated documentation, incorrect statements, missing headers, or package-boundary defects.

Not allowed without explicit approval:

- destructive tests;
- denial-of-service or load tests;
- high-rate automated scans, autonomous exploitation attempts, or persistence
  tests against any hosted origin, cloud account, browser profile, or local
  machine without explicit written approval;
- attempts to access another person’s machine, browser profile, cloud account, or unpublished hosting origin;
- public disclosure of attack reproduction steps before triage;
- modification or redistribution of official packages as if they were official releases.

## Known Boundaries

- `lab.html` and `lab_active` are research surfaces and are excluded from `public_runtime_secure`.
- Ximön, Persistence Affect, Canonical Functional Profile, Psychoacoustic Terrain, and Dynamic Viability Objective are read-only observation surfaces unless a document explicitly says otherwise. They are not claims of consciousness, biological equivalence, or human emotion.
- Canary hosting uses `noindex`, `no-store`, and short HSTS until a deliberate indexed public release is approved.
- The project has no public bug bounty or reward program unless a future release document explicitly states one.

## Expected Response

The maintainer should acknowledge a valid private report, reproduce the issue on the relevant lane, record the fix and verification path, and avoid weakening Gate3 repeatability, Gate4 invariants, snapshot/restore, preference input, or public distribution hygiene while repairing the issue.