mirror of
https://github.com/J3vb/OwnCord.git
synced 2026-09-03 03:50:00 +03:00
Merge branch 'dev' into feat/b3-7-alpha-dataset
This commit is contained in:
J3vb
@@ -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
|
||||
|
||||
+20
-19
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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 = {}) => ({
|
||||
|
||||
@@ -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 <squash-sha> [<squash-sha>...]
|
||||
#
|
||||
# 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 <squash-sha> [<squash-sha>...]" >&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"
|
||||
Reference in New Issue
Block a user