diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index e0823a6c..370ddab1 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -84,16 +84,18 @@ jobs: # Tag-gated tests (DC-06 / T-2026-07-25-16). The build-tag matrix above # only COMPILES the otel/wazero variants; the tests behind those tags - # (plugin/sandbox_wazero_test.go, telemetry/telemetry_otel_test.go) ran - # nowhere until this step. Scoped to the two packages that carry tagged - # files — every other package is tag-invariant and already covered by the - # race run above. One leg is enough; no -race (the runtime under the tag - # is the concern, not new concurrency). + # (plugin/sandbox_wazero_test.go, telemetry/telemetry_otel_test.go, + # api/recoverer_otel_test.go — the OC-0346 panic-log test, which this + # step never executed until ./api/... was added) ran nowhere until this + # step. Scoped to the packages that carry tagged files — every other + # package is tag-invariant and already covered by the race run above. + # One leg is enough; no -race (the runtime under the tag is the concern, + # not new concurrency). - name: Run tag-gated tests (-tags wazero, -tags otel) if: matrix.os == 'ubuntu-latest' run: | go test -tags wazero -count=1 ./plugin/... - go test -tags otel -count=1 ./telemetry/... + go test -tags otel -count=1 ./telemetry/... ./api/... # Coverage ratchet (B3-6 item 1). Reads the profile the race step wrote, # but placed after the other test steps so a floor miss does not hide diff --git a/docs/plans/README.md b/docs/plans/README.md index 6ccd9f18..5cc5cc6d 100644 --- a/docs/plans/README.md +++ b/docs/plans/README.md @@ -10,22 +10,22 @@ authority**. ## Active — these drive current work -| Plan | State | -| ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [beta-product-requirements-2026-08-23](beta-product-requirements-2026-08-23.md) | Approved beta scope, frozen. 57 `BPR-*` requirements. | -| [repo-health-roadmap-2026-08-23](repo-health-roadmap-2026-08-23.md) | Phase order and gates, B0–B10. **B0, B1 and B2 complete** (HP-0, HP-1 and HP-2 all accepted); **B3 is next** — opens with the layout-refactor first slice. B3–B10 not started. **Amended 2026-08-28:** dated lines in B3–B10, a "Phase execution pattern" section, and a truthful status header. **Amended 2026-08-29:** B3/B7/B9 lines binding the layout-refactor supplement below; current slice updated for B2-2. | -| [repo-health-issue-register-2026-08-23](repo-health-issue-register-2026-08-23.md) | 88 planning rows. Public-safe; not a replacement for the ledger. | -| [beta-requirements-traceability-2026-08-23](beta-requirements-traceability-2026-08-23.md) | Requirement → phase → evidence map. No row is release-qualified. | -| [b0-baseline-2026-08-25](b0-baseline-2026-08-25.md) | **Supersedes the roadmap's "current evidence snapshot."** B0 measurements and dispositions. | -| [b1-repository-foundation-2026-08-25](b1-repository-foundation-2026-08-25.md) | **B1-0 through B1-8 all done.** B1 execution plan. Re-verifies every RL-\* claim against HEAD; several are refuted. | -| [hp-0-scorecard-2026-08-25](hp-0-scorecard-2026-08-25.md) | **HP-0 accepted 2026-08-25.** The single baseline-acceptance artifact. Part-closes `R-08`. | -| [hp-1-scorecard-2026-08-27](hp-1-scorecard-2026-08-27.md) | **HP-1 accepted 2026-08-27.** Structural-diff proofs for the flatten and module rename, plus the B1 exit gate. | -| [b2-protocol-trust-compat-2026-08-28](b2-protocol-trust-compat-2026-08-28.md) | **B2 complete — HP-2 accepted 2026-08-29.** B2-0, B2-1, B2-8 done 2026-08-28; B2-2 (B2-3/B2-4 folded in), B2-5, B2-6, B2-7, B2-9 done 2026-08-29. Scorecard below. | -| [hp-2-scorecard-2026-08-29](hp-2-scorecard-2026-08-29.md) | **HP-2 accepted 2026-08-29.** Seven questions answered with commands; B2 exit gate, nine conditions met (1 at the slim epoch scope, 4 with one E2EE gap disclaimed). Owner follow-ups that do not gate B3: BPR-051 reader line, SEC-01/SEC-04 advisory IDs. | -| [b3-server-architecture-guardrails-2026-08-29](b3-server-architecture-guardrails-2026-08-29.md) | **B3 in progress from 2026-08-29.** Execution plan: B3-0 inventory → B3-1/B3-2 auth slice → HP-3 → lifecycle, hub options, `ws` split, families; guardrails and the alpha dataset beside the slice. B3-0 (inventory + `db-import-boundary` rule) and B3-1 (auth characterization) merged 2026-08-29; B3-2 (auth vertical slice) merged 2026-08-30; B3-9 (five of the six B3-tagged findings; OC-0323 rides B3-8) merged 2026-08-30; HP-3 accepted 2026-08-30; B3-3 (lifecycle extraction into `Server/internal/app/`, one composite close, hub construction out of `api.NewRouter`) is PR #1464, opened 2026-08-30 — B3-4 next. | -| [hp-3-scorecard-2026-08-29](hp-3-scorecard-2026-08-29.md) | **HP-3 accepted 2026-08-30 by the owner.** Five questions on the auth vertical slice answered with commands: frozen set green at every pre-squash SHA, `api` db importers 12 → 10, B2 contracts unchanged, the pattern written as D4 in server.md, guardrails as they exist. | -| [b3-bench-baseline-2026-08-30](b3-bench-baseline-2026-08-30.md) | **Recorded 2026-08-30, not gated.** The six B3-6 `Benchmark*` through `benchstat` at `ec8ef24a`, produced by `make bench-baseline`. Nothing in CI reads these numbers; the performance gate is B6's. Regenerating writes a new dated file — replace this row and delete the superseded document, so only the newest baseline is kept. | -| [audit-2026-08-19-remediation](audit-2026-08-19-remediation.md) | Phases 1–6 done 2026-08-20; **phase 7 pending**. Its header still reads "in progress 2026-08-19" — stale; the phase table is correct. | +| Plan | State | +| ----------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| [beta-product-requirements-2026-08-23](beta-product-requirements-2026-08-23.md) | Approved beta scope, frozen. 57 `BPR-*` requirements. **Amended 2026-08-31:** BPR-032 reworded to the slim single-current-epoch policy (owner decision; the scope HP-2 accepted). | +| [repo-health-roadmap-2026-08-23](repo-health-roadmap-2026-08-23.md) | Phase order and gates, B0–B10. **B0, B1 and B2 complete** (HP-0, HP-1 and HP-2 all accepted); **B3 in progress** — the B3 plan row below tracks it. B4–B10 not started. **Amended 2026-08-28:** dated lines in B3–B10, a "Phase execution pattern" section, and a truthful status header. **Amended 2026-08-29:** B3/B7/B9 lines binding the layout-refactor supplement below; current slice updated for B2-2. **Amended 2026-08-31:** B1 exit reworded to identical-tree integration evidence; B6/B8/B10 `server-info` and epoch-window lines aligned with the B2-2 slim decision; B10 gains the BPR-051 comprehension-read row (owner decisions 2026-08-31). | +| [repo-health-issue-register-2026-08-23](repo-health-issue-register-2026-08-23.md) | 88 planning rows. Public-safe; not a replacement for the ledger. | +| [beta-requirements-traceability-2026-08-23](beta-requirements-traceability-2026-08-23.md) | Requirement → phase → evidence map. No row is release-qualified. | +| [b0-baseline-2026-08-25](b0-baseline-2026-08-25.md) | **Supersedes the roadmap's "current evidence snapshot."** B0 measurements and dispositions. | +| [b1-repository-foundation-2026-08-25](b1-repository-foundation-2026-08-25.md) | **B1-0 through B1-8 all done.** B1 execution plan. Re-verifies every RL-\* claim against HEAD; several are refuted. | +| [hp-0-scorecard-2026-08-25](hp-0-scorecard-2026-08-25.md) | **HP-0 accepted 2026-08-25.** The single baseline-acceptance artifact. Part-closes `R-08`. | +| [hp-1-scorecard-2026-08-27](hp-1-scorecard-2026-08-27.md) | **HP-1 accepted 2026-08-27.** Structural-diff proofs for the flatten and module rename, plus the B1 exit gate. | +| [b2-protocol-trust-compat-2026-08-28](b2-protocol-trust-compat-2026-08-28.md) | **B2 complete — HP-2 accepted 2026-08-29.** B2-0, B2-1, B2-8 done 2026-08-28; B2-2 (B2-3/B2-4 folded in), B2-5, B2-6, B2-7, B2-9 done 2026-08-29. Scorecard below. | +| [hp-2-scorecard-2026-08-29](hp-2-scorecard-2026-08-29.md) | **HP-2 accepted 2026-08-29.** Seven questions answered with commands; B2 exit gate, nine conditions met (1 at the slim epoch scope, 4 with one E2EE gap disclaimed). Owner follow-ups that do not gate B3: BPR-051 reader line, SEC-01/SEC-04 advisory IDs. | +| [b3-server-architecture-guardrails-2026-08-29](b3-server-architecture-guardrails-2026-08-29.md) | **B3 in progress from 2026-08-29.** Execution plan: B3-0 inventory → B3-1/B3-2 auth slice → HP-3 → lifecycle, hub options, `ws` split, families; guardrails and the alpha dataset beside the slice. B3-0 (inventory + `db-import-boundary` rule) and B3-1 (auth characterization) merged 2026-08-29; B3-2 (auth vertical slice) merged 2026-08-30; B3-9 (five of the six B3-tagged findings; OC-0323 rides B3-8) merged 2026-08-30; HP-3 accepted 2026-08-30; B3-3 (lifecycle extraction into `Server/internal/app/`, one composite close, hub construction out of `api.NewRouter`) is PR #1464, opened 2026-08-30 — B3-4 next. | +| [hp-3-scorecard-2026-08-29](hp-3-scorecard-2026-08-29.md) | **HP-3 accepted 2026-08-30 by the owner.** Five questions on the auth vertical slice answered with commands: frozen set green at every pre-squash SHA, `api` db importers 12 → 10, B2 contracts unchanged, the pattern written as D4 in server.md, guardrails as they exist. | +| [b3-bench-baseline-2026-08-30](b3-bench-baseline-2026-08-30.md) | **Recorded 2026-08-30, not gated.** The six B3-6 `Benchmark*` through `benchstat` at `ec8ef24a`, produced by `make bench-baseline`. Nothing in CI reads these numbers; the performance gate is B6's. Regenerating writes a new dated file — replace this row and delete the superseded document, so only the newest baseline is kept. | +| [audit-2026-08-19-remediation](audit-2026-08-19-remediation.md) | Phases 1–6 done 2026-08-20; **phase 7 pending**. Its header still reads "in progress 2026-08-19" — stale; the phase table is correct. | ## Partially implemented @@ -70,9 +70,10 @@ Planning documents are not trackers. Do not read a defect count out of one. Ledger at 2026-08-30: **320 fixed / 54 open / 3 declined / 1 duplicate = 378** (B3-9, PR #1454, closed the five B3-tagged records). -All 38 open records still resolved to a live `file:line` at -`5cc0888964e26276d1aca145e83270a2c1b9febd` when that sweep was run — it was a -manual pass, not something a command reproduces. What the tooling does check: +The 2026-08-25 sweep resolved every record then open to a live `file:line` at +`5cc0888964e26276d1aca145e83270a2c1b9febd` — a manual pass, not something a +command reproduces, and not repeated for records opened since. What the +tooling does check: ``` node .superpowers/render-ledger.mjs --check # the ledger's schema is valid diff --git a/docs/plans/beta-product-requirements-2026-08-23.md b/docs/plans/beta-product-requirements-2026-08-23.md index c99d1eb3..7254eac7 100644 --- a/docs/plans/beta-product-requirements-2026-08-23.md +++ b/docs/plans/beta-product-requirements-2026-08-23.md @@ -51,14 +51,14 @@ Companion documents: ## Capacity and compatibility -| ID | Requirement | -| ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| BPR-030 | The beta reference profile supports at least 250 registered users, 100 simultaneous connections, and 25 concurrent voice participants per server, backed by published measurements on stated hardware. | -| BPR-031 | A server owner upgrades the server before users install the corresponding client update. | -| BPR-032 | An upgraded server supports the current advertised protocol epoch and the previous two epochs (`N/N-1/N-2`). Patch releases that retain an epoch remain compatible; prerelease and release metadata declare their epoch explicitly. The server-bundled browser client matches its server and is not an independently versioned compatibility generation. A new client is not required to support an older server. | -| BPR-033 | Connected users receive a clear update notification and can install the compatible client release. Clients outside the compatibility window fail safely with an actionable update requirement. | -| BPR-034 | One client connects to one server at a time. Saved profiles remain isolated and easy to switch; background multi-server aggregation is outside beta. | -| BPR-035 | One server-local account may have multiple simultaneous device sessions, with a device/session list, new-login notice, individual revocation, and sign-out-everywhere. | +| ID | Requirement | +| ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| BPR-030 | The beta reference profile supports at least 250 registered users, 100 simultaneous connections, and 25 concurrent voice participants per server, backed by published measurements on stated hardware. | +| BPR-031 | A server owner upgrades the server before users install the corresponding client update. | +| BPR-032 | An upgraded server supports its current advertised protocol epoch; patch releases that retain an epoch remain compatible; prerelease and release metadata declare their epoch explicitly; clients outside the accepted set are refused with a coded frame naming which side to update. _Amended 2026-08-31 (owner decision; shipped slim 2026-08-29, recorded in [b2-protocol-trust-compat-2026-08-28.md](b2-protocol-trust-compat-2026-08-28.md) §B2-2 and accepted at that scope by HP-2 condition 1): supersedes the original three-epoch window (`N/N-1/N-2`). The wire today also accepts the legacy epoch-0 handshake beside epoch 1, and a wider window returns by decision when a real epoch bump needs one._ The server-bundled browser client matches its server and is not an independently versioned compatibility generation. A new client is not required to support an older server. | +| BPR-033 | Connected users receive a clear update notification and can install the compatible client release. Clients outside the compatibility window fail safely with an actionable update requirement. | +| BPR-034 | One client connects to one server at a time. Saved profiles remain isolated and easy to switch; background multi-server aggregation is outside beta. | +| BPR-035 | One server-local account may have multiple simultaneous device sessions, with a device/session list, new-login notice, individual revocation, and sign-out-everywhere. | ## Identity, registration, and recovery diff --git a/docs/plans/beta-requirements-traceability-2026-08-23.md b/docs/plans/beta-requirements-traceability-2026-08-23.md index 79a0e96d..bef7a86c 100644 --- a/docs/plans/beta-requirements-traceability-2026-08-23.md +++ b/docs/plans/beta-requirements-traceability-2026-08-23.md @@ -74,14 +74,14 @@ ## Capacity and compatibility -| ID | Short label | Primary phase | Prerequisites | Minimum verification and closure evidence | -| ------- | -------------------------------------- | ------------- | --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| BPR-030 | 250/100/25 reference profile | B6 | B3 benchmarks/simulation; B5 completed services | Reproducible load run on stated hardware sustains 250 registered users, 100 simultaneous connections, and 25 concurrent voice participants; publish configuration, duration, p50/p95/p99 latency, errors, CPU, memory, disk/database waits, network, reconnect, and recovery behavior. | -| BPR-031 | Server upgrades first | B2 | B1 protocol owner and release metadata | Update-state tests prove the old server never directs users to an incompatible new client; server upgrade exposes signed compatible-client metadata; operator and client wording describes the sequence. | -| BPR-032 | Protocol epochs N/N-1/N-2 | B2 | B1 generated protocol gate; BPR-031 | Fixtures for epochs N, N-1, and N-2 connect and exercise required journeys; N-3 rejects safely; patch versions within an epoch interoperate; prerelease/release metadata declares epoch; bundled browser version always matches server. | -| BPR-033 | Update notice and safe incompatibility | B7 | BPR-031 and BPR-032; signed update metadata | Connected clients in-window receive a clear notice and can verify/install the compatible release; incompatible clients show an actionable non-destructive requirement; tampered, missing, offline, rollback, and user-deferral cases pass. | -| BPR-034 | One active server connection | B7 | BPR-040; isolated profile storage; platform contracts | Instrumented unit/E2E tests prove only one live server transport/media session exists; switching tears down old resources, isolates credentials/cache/notifications, preserves profiles, and never aggregates background servers. | -| BPR-035 | Multiple device sessions | B7 | B4 session inventory/revocation and login events; BPR-034 | Two or more devices remain active for one account; list labels/current-device state are correct; new-login notice appears; individual revoke affects only its target; sign-out-everywhere revokes all tokens and live connections. | +| ID | Short label | Primary phase | Prerequisites | Minimum verification and closure evidence | +| ------- | ------------------------------------------------ | ------------- | --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| BPR-030 | 250/100/25 reference profile | B6 | B3 benchmarks/simulation; B5 completed services | Reproducible load run on stated hardware sustains 250 registered users, 100 simultaneous connections, and 25 concurrent voice participants; publish configuration, duration, p50/p95/p99 latency, errors, CPU, memory, disk/database waits, network, reconnect, and recovery behavior. | +| BPR-031 | Server upgrades first | B2 | B1 protocol owner and release metadata | Update-state tests prove the old server never directs users to an incompatible new client; server upgrade exposes signed compatible-client metadata; operator and client wording describes the sequence. | +| BPR-032 | Protocol epoch policy (slim; amended 2026-08-31) | B2 | B1 generated protocol gate; BPR-031 | The accepted epochs connect and exercise required journeys on a real socket; out-of-window clients are refused safely with a coded, actionable frame; patch versions within an epoch interoperate; prerelease/release metadata declares epoch; bundled browser version always matches server. Evidence at the slim scope: `TestAuth_ProtocolEpoch`, `TestEpoch1Fixtures`, `TestReleaseProtocolEpoch` (HP-2 Q2 / condition 1). | +| BPR-033 | Update notice and safe incompatibility | B7 | BPR-031 and BPR-032; signed update metadata | Connected clients in-window receive a clear notice and can verify/install the compatible release; incompatible clients show an actionable non-destructive requirement; tampered, missing, offline, rollback, and user-deferral cases pass. | +| BPR-034 | One active server connection | B7 | BPR-040; isolated profile storage; platform contracts | Instrumented unit/E2E tests prove only one live server transport/media session exists; switching tears down old resources, isolates credentials/cache/notifications, preserves profiles, and never aggregates background servers. | +| BPR-035 | Multiple device sessions | B7 | B4 session inventory/revocation and login events; BPR-034 | Two or more devices remain active for one account; list labels/current-device state are correct; new-login notice appears; individual revoke affects only its target; sign-out-everywhere revokes all tokens and live connections. | ## Identity, registration, and recovery @@ -97,14 +97,14 @@ ## Privacy, deletion, and retention -| ID | Short label | Primary phase | Prerequisites | Minimum verification and closure evidence | -| ------- | -------------------------------------------------- | ------------- | ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| BPR-050 | Hybrid privacy and media E2EE | B2 | B1 protocol ownership; private threat model | Storage inspection confirms the trusted server can deliver/search/moderate/backup text and files; authenticated media interoperability and adversarial membership/rekey/removal tests demonstrate participant E2EE for voice, video, and screen share; docs state the boundary accurately. | -| BPR-051 | Plain server-operator trust disclosure | B2 | BPR-050; B1 docs source of truth | Setup, privacy, backup, moderator, and client disclosures say the machine owner can access stored text/files and distinguish transport/at-rest controls from E2EE; technical review and user comprehension check find no contradictory claim. | -| BPR-052 | Erase all user-authored data | B4 | B3 data ownership inventory; BPR-042; backup fixtures | Deletion traverses profile, credentials, sessions, messages, reactions, uploads, thumbnails/cache, request/report references, and every later data class; pre/post database and storage inventory is empty for the subject; interruption resumes safely; B7/B9 UI confirms impact and completion. | -| BPR-053 | Unlinkable integrity history and anti-resurrection | B4 | BPR-052; cryptographic mapping and backup design | After deletion, audit/moderation rows retain only allowed event category, time, action class, and integrity proof; subject/content mapping key is cryptographically erased; correlation attempts fail; restore of an older backup reapplies the durable deletion marker and cannot resurrect data. | -| BPR-054 | Indefinite default and configurable retention | B4 | B3 scheduler/lifecycle; BPR-052/BPR-053 | Fresh and upgraded servers default to indefinite history; server/channel policies handle precedence, clock boundaries, restart, batches, attachments, cache/search, reports/audit, deletion, and disk pressure; owner UI/docs preview and confirm effects. | -| BPR-055 | No automatic telemetry | B4 | B1 dependency inventory; local diagnostics design | Network capture across install, startup, use, crash, update check, offline, and support workflows shows no automatic product/usage reporting; support bundle requires user action and passes secret/content review; any future crash option defaults off and records consent. | +| ID | Short label | Primary phase | Prerequisites | Minimum verification and closure evidence | +| ------- | -------------------------------------------------- | ------------- | ----------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| BPR-050 | Hybrid privacy and media E2EE | B2 | B1 protocol ownership; private threat model | Storage inspection confirms the trusted server can deliver/search/moderate/backup text and files; authenticated media interoperability and adversarial membership/rekey/removal tests demonstrate participant E2EE for voice, video, and screen share; docs state the boundary accurately. | +| BPR-051 | Plain server-operator trust disclosure | B2 | BPR-050; B1 docs source of truth | Setup, privacy, backup, moderator, and client disclosures say the machine owner can access stored text/files and distinguish transport/at-rest controls from E2EE; technical review and user comprehension check find no contradictory claim. The comprehension check is tracked as a B10/R-08 release-scorecard row (added 2026-08-31); HP-2 Q3 holds the blanks it fills. | +| BPR-052 | Erase all user-authored data | B4 | B3 data ownership inventory; BPR-042; backup fixtures | Deletion traverses profile, credentials, sessions, messages, reactions, uploads, thumbnails/cache, request/report references, and every later data class; pre/post database and storage inventory is empty for the subject; interruption resumes safely; B7/B9 UI confirms impact and completion. | +| BPR-053 | Unlinkable integrity history and anti-resurrection | B4 | BPR-052; cryptographic mapping and backup design | After deletion, audit/moderation rows retain only allowed event category, time, action class, and integrity proof; subject/content mapping key is cryptographically erased; correlation attempts fail; restore of an older backup reapplies the durable deletion marker and cannot resurrect data. | +| BPR-054 | Indefinite default and configurable retention | B4 | B3 scheduler/lifecycle; BPR-052/BPR-053 | Fresh and upgraded servers default to indefinite history; server/channel policies handle precedence, clock boundaries, restart, batches, attachments, cache/search, reports/audit, deletion, and disk pressure; owner UI/docs preview and confirm effects. | +| BPR-055 | No automatic telemetry | B4 | B1 dependency inventory; local diagnostics design | Network capture across install, startup, use, crash, update check, offline, and support workflows shows no automatic product/usage reporting; support bundle requires user action and passes secret/content review; any future crash option defaults off and records consent. | ## Messaging, content, and safety diff --git a/docs/plans/repo-health-roadmap-2026-08-23.md b/docs/plans/repo-health-roadmap-2026-08-23.md index dc95741d..4cd14f41 100644 --- a/docs/plans/repo-health-roadmap-2026-08-23.md +++ b/docs/plans/repo-health-roadmap-2026-08-23.md @@ -332,7 +332,14 @@ the structural review. reviewable and active path references are complete. - Generated sources and analysis artifacts have explicit reproducible owners. - The protocol schema generates and verifies both consumers from the root. -- Every dev integration commit has exact-SHA CI. +- Every dev integration commit carries full-matrix evidence: the required + matrix runs on the pull-request head, and `strict: true` makes the squash + commit's tree the tree that matrix tested. + `scripts/verify-integration-tree.sh` proves it per squash SHA; + `verify-gate-evidence.mjs --selftest` pins the strict flag. _(Reworded + 2026-08-31, owner decision — previously "exact-SHA CI", which dev pushes + never ran; PR-head evidence with enforced tree identity is the accepted + form.)_ - Issues, Discussions, pull requests, and private security reporting match the approved community model. - Full B0 evidence remains green after the migration. @@ -344,7 +351,8 @@ the structural review. - root-command output and direct server-command parity; - docs link checker and repository lint results; - generated-source drift check; -- exact-SHA workflow and protected-release evidence. +- identical-tree integration evidence (see the exit gate) and + protected-release evidence. ### Safe parallelism @@ -408,7 +416,9 @@ service expansion. Security details remain in private review. - Clients from epochs N, N-1, and N-2 pass the server compatibility matrix; N-3 fails safely and actionably. The server-bundled browser client matches - the server epoch rather than becoming an independent generation. + the server epoch rather than becoming an independent generation. _(HP-2 + accepted this condition at the slim one-epoch scope — owner decision + 2026-08-29, formalized 2026-08-31 in BPR-032 as amended.)_ - Protocol and update metadata changes are generated, documented, and downgrade-tested. - Effective permission and resource-existence sibling cases have parity tests. @@ -757,10 +767,11 @@ service. 15. _(added 2026-08-28)_ R-09: the exact-SHA gate already runs at tag time (the `gate-evidence` job in `release.yml`, B1-7); `environment: release` lands in B2-0. B6 rehearses one tag against both before HP-6. -16. _(added 2026-08-28)_ Add the browser-hosting flag to - `GET /api/v1/server-info` (defined in B2-2) alongside workstream 6's - default-off hosting switch, so one endpoint answers "what is this - server, and is the browser client on". +16. _(added 2026-08-28; amended 2026-08-31)_ Add `GET /api/v1/server-info` + with the browser-hosting flag alongside workstream 6's default-off + hosting switch, so one endpoint answers "what is this server, and is + the browser client on". B2-2's slim decision (2026-08-29) dropped the + endpoint from B2 — this workstream introduces it, it does not extend it. Public IP certificates are feasible only for eligible stable public addresses and currently require short-lived certificate handling. Private or reserved IP @@ -852,9 +863,10 @@ without regressing the current application. 13. _(added 2026-08-28)_ Delete the two Rust commands nothing invokes, `probe_credential_store` and `ptt_get_key` ([platform-contracts.md](../architecture/platform-contracts.md)). -14. _(added 2026-08-28)_ Workstream 8 consumes B2's - `protocol_epoch_unsupported` frame and `GET /api/v1/server-info`; it - defines no new contract. +14. _(added 2026-08-28; amended 2026-08-31)_ Workstream 8 consumes B2's + `protocol_epoch_unsupported` frame and the `GET /api/v1/server-info` + endpoint B6 workstream 16 adds (B2-2 shipped without it); it defines no + new contract. 15. _(added 2026-08-28)_ Re-run Stryker (C-16) before workstream 6 decomposes modules, so the mutation baseline is honest. 16. _(added 2026-08-29)_ Workstreams 1–3, 6 and 7 execute from @@ -948,8 +960,9 @@ behavior. LAN/offline path uses publicly trusted or local-CA certificates only — never a TOFU shim ([platform-contracts.md](../architecture/platform-contracts.md), hard case one). -12. _(added 2026-08-28)_ The browser client reads `GET /api/v1/server-info` - (B2-2, flag from B6) for the hosting flag and epoch; no separate +12. _(added 2026-08-28; amended 2026-08-31)_ The browser client reads + `GET /api/v1/server-info` (endpoint and flag from B6 workstream 16 — + B2-2 shipped without it) for the hosting flag and epoch; no separate discovery endpoint. Service workers, camera/microphone, Web Push, and screen capture require secure @@ -1108,7 +1121,10 @@ re-verifies every BPR. 4. Test in-place upgrade from representative 1.2.0-alpha data, attachments, configuration, credentials, and client settings, plus rollback within the declared boundary. -5. Re-run protocol epochs N, N-1, and N-2 plus actionable N-3 rejection. +5. Re-run the accepted protocol epochs plus actionable out-of-window + rejection — the slim scope of the 2026-08-29 B2-2 decision (BPR-032 as + amended 2026-08-31); the matrix widens only if a later epoch bump + reintroduces a window. 6. Re-run the full Windows x64/ARM64 and Linux x64/ARM64 desktop matrix, server artifacts, multi-architecture Docker, browser engines, Android phone/tablet, and iPhone/iPad matrix. @@ -1130,6 +1146,12 @@ re-verifies every BPR. written. Exempt `main` from `cancel-in-progress` before the count starts. 14. _(added 2026-08-28)_ The 14-day soak runs on named hosts: the owner's LAN self-hosted instance and one Docker instance. +15. _(added 2026-08-31)_ Record BPR-051's non-developer comprehension read on + the R-08 release scorecard: a non-developer reads `docs/trust-model.md` + §"The short answer" and their answer to "who can read my messages?" fills + the HP-2 Q3 blanks (and the B2-7 evidence block — both must agree). + Owner decision 2026-08-31: tracked as a release-gate row so a missing + reader blocks the beta, not B3–B9 work. ### Hold point HP-10 — Human go/no-go diff --git a/scripts/verify-gate-evidence.mjs b/scripts/verify-gate-evidence.mjs index 08626581..8850f142 100644 --- a/scripts/verify-gate-evidence.mjs +++ b/scripts/verify-gate-evidence.mjs @@ -36,6 +36,25 @@ export function requiredContexts(scriptSrc) { return [...block[1].matchAll(/"([^"]+)"/g)].map((m) => m[1]); } +// The identical-tree evidence model (G-03 as amended 2026-08-31) leans on +// required_status_checks.strict: with strict off, a PR that is behind dev can +// be squash-merged into a tree no CI run ever saw, and the PR-head evidence +// this gate trusts stops describing what actually landed. strict: true is what +// makes "the required matrix ran on the merged tree" a construction rather +// than a habit — scripts/verify-integration-tree.sh spot-proves it per squash +// SHA — so losing the flag must fail on a pull request, not in a later audit. +export function strictUpToDate(scriptSrc) { + const block = scriptSrc.match(/"required_status_checks"\s*:\s*\{([\s\S]*?)\}/); + if (!block) { + throw new Error(`no "required_status_checks" object found in ${PROTECTION_SCRIPT}`); + } + const strict = block[1].match(/"strict"\s*:\s*(true|false)/); + if (!strict) { + throw new Error(`no "strict" key found under required_status_checks in ${PROTECTION_SCRIPT}`); + } + return strict[1] === "true"; +} + // checkRuns is the API's check_runs array, already collected across pages. // Returns the reasons this commit is not releasable; empty means it is. export function evaluate(required, checkRuns) { @@ -138,6 +157,18 @@ function selftest() { real.includes("Server Build & Test (ubuntu-latest)"), "an ampersand name survives parsing", ); + assert( + strictUpToDate(readFileSync(join(ROOT, PROTECTION_SCRIPT), "utf8")), + "strict: true is pinned — identical-tree integration evidence relies on it", + ); + assert( + strictUpToDate('"required_status_checks": { "strict": true, "contexts": ["A"] }'), + "strict true parses", + ); + assert( + !strictUpToDate('"required_status_checks": { "strict": false, "contexts": ["A"] }'), + "strict false is detected, not glossed as true", + ); const req = ["A", "B"]; const ok = (name, extra = {}) => ({ diff --git a/scripts/verify-integration-tree.sh b/scripts/verify-integration-tree.sh new file mode 100644 index 00000000..faa0ae8e --- /dev/null +++ b/scripts/verify-integration-tree.sh @@ -0,0 +1,51 @@ +#!/usr/bin/env bash +# Integration evidence for a dev squash commit (G-03 as amended 2026-08-31). +# +# dev is squash-merge-only and its pushes deliberately run no ci.yml matrix +# (the pull_request trigger already ran it on the PR head), so the squash +# commit itself carries only CodeQL runs. What makes the PR-head evidence +# transfer to the squash commit is required_status_checks.strict: an +# up-to-date PR's head names the same tree the squash commit lands. This +# script turns that construction into a per-commit statement a phase-exit or +# hold-point evidence block can cite as a command with output, instead of an +# assumption: +# +# bash scripts/verify-integration-tree.sh [...] +# +# For each squash commit: parse the pull-request number from the "(#N)" +# subject suffix every squash merge carries, fetch refs/pull/N/head from +# origin, and assert both commits name the same git tree. Exits non-zero if +# any commit fails. Needs network access to origin; verify-gate-evidence.mjs +# --selftest is what keeps the strict flag itself pinned. +set -euo pipefail + +if [ "$#" -lt 1 ]; then + echo "usage: bash scripts/verify-integration-tree.sh [...]" >&2 + exit 2 +fi + +fail=0 +for sha in "$@"; do + if ! subject=$(git log -1 --format=%s "$sha" 2>/dev/null); then + echo "FAIL ${sha}: unknown commit (fetch the branch that carries it first)" >&2 + fail=1 + continue + fi + if [[ "$subject" =~ \(#([0-9]+)\)$ ]]; then + pr="${BASH_REMATCH[1]}" + else + echo "FAIL ${sha}: subject does not end in (#N), so it is not the squash of a PR: ${subject}" >&2 + fail=1 + continue + fi + git fetch -q --no-tags origin "refs/pull/${pr}/head" + head_tree=$(git rev-parse "FETCH_HEAD^{tree}") + squash_tree=$(git rev-parse "${sha}^{tree}") + if [ "$head_tree" = "$squash_tree" ]; then + echo "PASS ${sha} (PR #${pr}): squash tree == PR head tree ${head_tree}" + else + echo "FAIL ${sha} (PR #${pr}): squash tree ${squash_tree} != PR head tree ${head_tree} — the merged tree was never CI-tested as-is" >&2 + fail=1 + fi +done +exit "$fail"