Reconcile the recorded state with production and with upstream - #39
Conversation
The committed table said 3 of 36 protocols were readable. The manifest the overlay serves says 6 of 38: dunes and zrc20 joined the registry, and zerdinals, zrunes and zrc20 are now verified read only with complete coverage. Regenerated from the live manifest with generate-protocol-coverage.mjs --from, so the table and the recorded JSON agree and the --check gate passes. Nothing here is hand edited. This is a documentation change and a small one, but a stale coverage table is the kind of stale that gets quoted: it undercounts what works and it hides which authorities moved. The remaining 32 are recorded as BLOCKED because that is what they are. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ly say upstream-base.json carried an empty modifiedSubsystems list and an empty knownUpstreamConflicts list while UPSTREAM.md described eleven modified subsystems. The machine-readable file and the human-readable one disagreed, and the machine-readable one was the one that was wrong. Both now carry the same eleven subsystems, plus the three files where an upstream sync predictably conflicts, plus the mirror sha this fork was measured against. UPSTREAM.md gains the reconciliation itself. The 40 commits upstream has added since the recorded mirror were read and classified: 36 dependency bumps, 2 toolchain, 2 infrastructure, and nothing that changes product behaviour or fixes a defect this fork carries. Upstream's bumps do not describe this fork's exposure, because this fork has its own lockfiles, so the exposure was measured rather than inferred. The backend has zero advisories. The frontend has eleven, ten of them in build tooling that never reaches a browser. The eleventh ships: echarts 5.4.3 carries GHSA-fgmj-fm8m-jvvx, a moderate XSS advisory fixed only in echarts 6.1.0, a major version upstream has not taken either. Moving a charting library across a major version touches every chart on every chain, so it is recorded with its exact identity and left as the next dependency task rather than slipped into a release unreviewed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
bitcoinuniverseadmin
changed the title
|
Heads up on an overlap, and a suggestion for the order. #40 rewrites both files this touches. It found the same drift you did, from the other direction: That PR replaces the generator with one that pins the manifest by provenance, holds this repository's own surfaces to it, and compares the pin against what a deployment serves in the production smoke run. It also regenerates the README readable list, which was naming three readable protocols while six were readable. Your UPSTREAM.md and upstream-base.json work does not overlap with any of it. Suggested order: merge this one first. Re-recording the roster is a single command in mine ( One thing to know if this merges alone: the manifest it records comes from the live endpoint, which does not yet carry the identity fields ( |
A release record of readings rather than intentions: the fee arithmetic verified against a live node, the Dogecoin coverage figures, the throughput and disk measurements that show the inscription reindex cannot finish, the lag defect and what it was reporting, the listener that was public and now is not, the origin's headers, the dependency exposure measured rather than inferred, and the protocol coverage production actually serves. It ends with what was not reached and why, because a release record that only lists successes is the kind that gets quoted later by someone who needed the other half. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The record said the volume exhausts before the reindex could finish. Measured across 90 minutes of indexing, free space did not move: nearly all of that I/O rewrites pages in place rather than growing the file. Throughput alone is the blocker. The second reading also refines the rate to about 33 blocks an hour rather than 16. Both numbers put the remaining work in years, so the conclusion is unchanged, but a record that overstates one of its own measurements is worth less than one that does not. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Cancelled this PR's in-flight run to free two ultra runners, because it could not have passed. Its #40 fixes both halves: the deep pass is split into three shards so the job finishes in about 23 minutes instead of 95, and the screenshot uploads only run on failure so a green run writes nothing. Re-run this against develop once that lands and it should go green without any change on your side. |
|
Second correction on top of my earlier note, and this one was my fault. #40 split the deep visual pass into three shards that each built their own copy, which took a run from two concurrent Angular production builds to five, on a fleet that runs more than one runner per host. Everything that started a build in the same ninety second window was killed with exit code 137, out of memory, including on pull requests that touched nothing but scripts. That is what put #48 is merged and fixes it: the frontend job keeps its build under a commit-keyed cache and the shards take it, so a run is back to two concurrent builds. Verified on its own run, 33340340913: all eight jobs green, every shard's fallback build step skipped because the cache hit, whole run 48 minutes. Merge develop into this branch now and it should go green. Still expected to fail and still not required: Sorry for the churn. Say the word and I will do the develop merge for you. |
|
The CI repairs are all merged now, so this should go green on a develop merge with no change to your work. What landed since your last run:
#42 went through all eight jobs green after its author merged develop, which is the shape to expect here. Still failing and still not required: I have left this branch alone because it is yours. Merge develop into it when you are ready, or say the word and I will do it. |
The two coverage files conflicted because develop re-recorded them from the deployed overlay after the roster contract landed: seven readable protocols rather than six, with the schema, registry version, source repository and source commit the pin now carries. Those take develop's version. Nothing else on this branch is touched. The upstream reconciliation, the pinned upstream base and the release evidence record are the work this branch exists for and they carry through unchanged. Verified on the merged tree: the roster gate passes, its twenty-five cases pass, and the text gate passes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Merged develop into this branch, since I offered twice and it had not moved in six and a half hours. A merge commit, no rebase, no force push. The two PROTOCOL-COVERAGE files conflicted and take develop version: it re-recorded them from the deployed overlay after the roster contract landed, so the pin now carries seven readable protocols rather than six, plus the schema, registry version, source repository and source commit. Your UPSTREAM.md, upstream-base.json and the 172 line RELEASE-EVIDENCE-2026-08-30.md carry through untouched, which is the work this branch exists for. Verified on the merged tree before pushing: the roster gate passes with 38 protocols and 7 readable, its 25 cases pass, and the text gate passes. CI is running. The three If it comes back green I intend to merge, because the frontend deployment is blocked on the remaining PRs and the hourly production smoke has been red since 00:39Z purely because develop is ahead of what is deployed. Say so if you would rather land it yourself. |
1 participant
Two records that had drifted from reality, corrected from evidence rather than
by hand.
1. Protocol coverage
The committed table claimed 3 of 36 protocols were readable. The manifest
the overlay serves at
/api/v1/universe/protocolssays 6 of 38.Regenerated from the live manifest:
The other 32 stay BLOCKED, because that is what they are. Most are not missing
code: their indexer repositories exist with real implementations, and the gap
is that the service is not configured in the overlay's source list on the
indexer host.
2. Upstream
upstream-base.jsoncarried an emptymodifiedSubsystemsand an emptyknownUpstreamConflictswhileUPSTREAM.mddescribed eleven modifiedsubsystems. The two disagreed, and the machine-readable one was wrong. They now
carry the same eleven, plus the three files where an upstream sync predictably
conflicts, plus the mirror sha measured against.
upstream/masteris 40 commits ahead of the mirror recorded at fork time.All 40 were read and classified:
Nothing upstream added changes product behaviour or fixes a defect this fork
carries.
Exposure, measured rather than inferred
Upstream's bumps do not describe this fork's exposure, because this fork has
its own lockfiles. So it was measured:
browser (
browser-sync,less,image-size,webpack-dev-server,immutable,sockjs,uuid, the two@angular-devkitpackages).The one that ships
echarts5.4.3 carries GHSA-fgmj-fm8m-jvvx,a moderate XSS advisory, CVSS 6.1. echarts draws every chart in the explorer.
The fix is echarts 6.1.0, a major version. Upstream is still on 5.x, so
there is nothing upstream to take. Moving a charting library across a major
version touches every chart on every chain and needs the full visual matrix
behind it. It is recorded with its exact identity and left as the next
dependency task rather than slipped into a release unreviewed.
This closes the release criterion that
UPSTREAM.mdandupstream-base.jsonmust agree. They now do, and both agree with what upstream and
npm auditactually say.
🤖 Generated with Claude Code