# Registration checklist implementation evidence

The user authorized sequential implementation without Railspike on `fix/profile-registration-cost`, with a checklist update in each item commit. Retraction behavior follows the coordination handoff; no retraction simplification is implemented by this work.

REG-01 completed in `517844c7e`, following initial runner commit `56cbe951d`. See the [baseline](profile_registration_baseline.md) and retained results.

REG-02 adds duration breakdowns for profile/post loading, approval derivation, count derivation, profile updates, activity refresh and transaction commit. Both signed registration and historical linking retain existing timings and add lock hold duration. Identity-update metrics report profile/post counts, profile rows updated, activity statement count, activity row updates and process peak memory. These integer counts are returned separately from Server-Timing durations. They count SQL operations/matched rows, including repeat updates, rather than distinct semantic changes.

Full-rebuild selection reports the bounded reason `incremental_unavailable` or `incremental_update_failed`; diagnostics do not copy raw exception text or private material. Fallback behavior itself is unchanged. Benchmark reports retain these metrics, with existing success/integrity/source-preservation checks.

Verification: six focused benchmark/server-timing/identity fallback/parity checks passed, plus the execution-lock test covering successful return, timing fields, and release after callback failure. Both real-data benchmark cases passed. Fresh registration updated 3,846 profile rows and issued 3,847 activity updates; the activity loop took 15,512.7 ms of a 16,355.3 ms lock hold. Historical linking issued the same number of updates; its activity loop took 16,420.7 ms of a 17,185.4 ms lock hold. Approval derivation took 326.2/299.1 ms. [Full measured results](profile_registration_instrumented_results.json) retain counts, memory, and all durations. These are local runs on the matched QDB snapshot, not production-host measurements.

No schema identity, query semantics, dependencies, or public UI changed in REG-02. Whole-suite and production verification are not claimed.

REG-03: [acceptance targets](profile_registration_acceptance.md) recorded in `16d7fc2b1`; numerical targets are future gates, not current production claims. REG-02 commit: `65ab757a3`.

REG-04: added activity author index and schema version 26, updated the schema reference, and verified migration from the actual schema-25 identity at normal startup. The author update plan now uses `activity_author_identity_idx`. Six focused checks passed (startup, rebuild script, metadata, baseline harness and identity parity). An actual `./v3 rebuild` with isolated fixture/database/static paths completed and produced schema 26 with the expected query plan. Both QDB-scale write flows passed after rebuilding their working copies. Activity-loop time fell from 15,512.7/16,420.7 ms to 93.5/202.1 ms; whole operation times were 1,284.7/2,710.7 ms. All-profile updates remain, and the final latency targets are not yet met. The first indexed benchmark retained rebuild allocations; its process peak-memory numbers are not isolated registration memory. The harness now runs optional setup rebuilding in a child process, verified on the small fixture, to remove that contamination in subsequent runs. No production deployment or new dependencies.

REG-04 commit: `01cd88c47`. REG-05 adds `posts_author_identity_idx` and schema 27. Seven transaction-rollback samples on a copied QDB database reduced median author-link lookup from 5.490 to 0.044 ms and anonymous-anchor lookup from 6.509 to 0.085 ms. Plans changed from `SCAN posts` to `MULTI-INDEX OR`, using both primary-key and author indexes; row counts were unchanged. A prior-schema-26 startup regression verifies the index, and an overlapping-branch update verifies that a matching post is updated once. The schema-25 regression now removes both indexes to represent that older layout. Seven focused checks passed; a literal isolated `./v3 rebuild` completed. Source data and production were not changed. No dependencies added.

REG-05 commit: `ee5f0733d`. REG-06 audit confirmed the builder consumes the canonical schema and candidate/high-traffic validation uses its schema identity. The first audit found an outdated expected-object list in ReadModelSchemaTest (33/34 passed); it now includes both new indexes. The repeated audit passed 34/34 across schema, metadata, candidate creation/promotion/failure, high-traffic publication, absent-target snapshots, prior-version startup, real registration and user-directory invalidation. Literal CLI rebuild checks were already completed under REG-04/05 and were not repeated without cause. Schema and query semantics were not changed by this audit. Production migration and the full repository suite remain later gates.

REG-06 commit: `dceb127c4`. REG-07 adds a NULL-safe changed-value predicate to profile updates and retains the changed profile set for REG-08. Schema 28, specification and schema-27 startup regression accompany the query change. SQLite AFTER UPDATE observer triggers independently verify no unrelated profile writes for fresh registration (zero profile updates) and one changed profile for historical linking. Actual isolated `./v3 rebuild` passed. The broader selection passed 18/19 tests; the remaining ApprovalSeedCommandTest assertion expects removed UI copy, "This is your profile." It reproduced unchanged in a clean worktree at pre-change `dceb127c4`. The identity parity, schema, instrumentation and other approval-seed checks passed. That unrelated pre-existing assertion is recorded, not silently fixed or counted as a pass. No dependencies or retraction behavior changed.

REG-07 commit: `e5aea3c9c`. REG-08 replaces the all-profile activity iteration with the changed-profile set, passes derived approval values directly, and adds a NULL-safe activity changed-value predicate. The initial new-identity attribution pass remains; unchanged existing authors are not rewritten. SQLite observer triggers verify this independently of reported counters, and fixture statement counts are at most two. Schema 29/spec and schema-28 startup regression accompany the query change. Six focused checks passed, including identity/full-build parity and transitive approval-seed attribution; isolated `./v3 rebuild` completed. Full-site profile/post loading and approval derivation still remain for later items. No dependencies or retraction policy changed.


REG-08 commit: `989385bb7`. REG-09 rebuilt an isolated schema-29 database from the exact pinned QDB canonical head with literal `./v3 rebuild`, then ran five independent pairs without in-process rebuilding. All ten writes were incremental, passed SQLite quick checks and preserved the source inputs. Both author-index query plans remain in use; post linking uses MULTI-INDEX OR. [Full samples and plans](profile_registration_targeted_results.json) include revision, source hash, counts and timing scope.

| Local metric | Fresh signed | Historical link |
| --- | ---: | ---: |
| Original median wall time (3 runs), ms | 18,910.4 | 18,325.1 |
| Targeted median wall time (5 runs), ms | 1,183.9 | 944.8 |
| Median execution-lock hold, ms | 1,152.2 | 944.4 |
| Maximum observed lock hold, ms | 1,694.0 | 1,004.8 |
| Median profile loading, ms | 9.4 | 9.4 |
| Median post loading, ms | 71.9 | 51.1 |
| Median approval derivation, ms | 300.6 | 298.5 |
| Median count derivation, ms | 12.5 | 8.1 |
| Activity update statements | 1 | 2 |
| Profile rows updated | 0 | 1 |
| Process peak memory, MiB | 36 | 36 |

Each operation still considers 3,846 profiles and 18,760/18,761 posts. Conditional profile updates avoid value writes but still execute per profile. Fresh registration misses the sub-second median target; all observed holds are below two seconds. Local Git cost also varies substantially. The packed benchmark clones, local scheduling/cache state, absence of concurrent readers and limited sample count prohibit treating these results as production acceptance. The historical case reports zero activity updates, which does not establish correct anonymous-bootstrap attribution; canonical/full-rebuild parity for that case remains required under REG-12/20. This checkpoint verifies intermediate cost reduction only. No dependencies or application behavior changed in REG-09.

Reproduction: use the baseline runner with `--repository-root=state/benchmarks/qdb-20261024/matched-repository`, `--database-path=state/benchmarks/qdb-schema29/read_model.sqlite3`, `--site=qdb`, and a fresh `--output-dir` per run. The source database was built with `FORUM_SITE_ID=qdb FORUM_STATIC_HTML_ROOT="$PWD/state/benchmarks/qdb-schema29/static" ./v3 rebuild "$PWD/state/benchmarks/qdb-20261024/matched-repository" "$PWD/state/benchmarks/qdb-schema29/read_model.sqlite3"`. Original downloaded schema-25 data remains unchanged.


2026-10-25 merge checkpoint: the user requested merging completed work. REG-01–09 are the completed registration slice; REG-10–24 and optional availability decisions remain open. Reverification passed 25/25 focused checks: benchmark input preservation and real registration, schema/metadata, identity parity, startup migration from versions 25–28, status command and health indicators. Previously recorded full-rebuild checks and QDB benchmark evidence remain applicable. This is not full-suite, concurrency or production-host acceptance; the previously recorded obsolete approval-copy assertion remains unresolved.

The accompanying status correction reports lock observation accurately, distinguishes queued-worker rebuilds from manual/web writes, avoids recommending another rebuild while locks are held, and replaces local-development restart advice for hosted frontends. The recovery runbook explains lock-holder inspection and why deleting a lock file is unsafe. Existing status/health integration checks passed. Dependency delta: zero. Deployment is separate from this local merge: schema 29 requires rebuilding the configured read model; schedule the rebuild rather than letting the first visitor trigger it. The prepared high-traffic model must likewise be prepared against the new schema before using it. No production commands were executed.