Record CI wall clock, forgectl's mainnet metrics, and Phase 1's missing release flow

[Peeja]

⏭️ Safe to merge without waiting for CI — all of it

Refreshed on every push. Checks are not required yet, so this is advice, not a gate.

One file changed: MONOREPO_TODO.md. Nothing in the repository reads it.

$ git diff --name-only origin/main HEAD
MONOREPO_TODO.md
$ grep -rn "MONOREPO_TODO" --include='*.yml' --include='*.sh' --include='*.go' --include=Makefile .
.github/scripts/check-base-images.sh:12:# not installed yet (MONOREPO_TODO.md), so that half is inert. This check is

One hit, and it is prose inside a comment — no workflow, guard, Go package or Makefile target consumes the file. ci, images, e2e and itest will all pass and none of them could have done otherwise.

What this costs if it's wrong: the checks still run; we just don't wait. If an ignored check goes red after merge, main is red.

---

Three entries. The first re-homes work that would otherwise exist only on a closed branch; the other two are findings from reading main while working out what comes next.

1. CI wall clock — the measurement survives the PR that produced it

#21 built test sharding, ran it green, and was closed for simplicity. Its A/B is the evidence base for every remaining option, so it belongs here rather than only on a closed branch and the wiki:

	unsharded	sharded (closed)
itest workflow	30m43s	23m07s
test binary	1267.853s	628.841 + 462.731 + 204.654s
runner-minutes	29m29s	42m04s

Total test work unchanged at +2.2% — nothing got cheaper, it got spread.

The live options are ordered, and each says what is measured versus assumed: the layer cache (open separately; needs re-measuring after one warm run, since the first run post-merge is cold by construction), versitygw's self-imposed 3s lockWaitTime across 38 call sites, build-once-and-load, and — if sharding is revived — bin-packing against measured durations rather than name order.

The shared stack is parked, and the arithmetic that made it look attractive is recorded as wrong: shard 3 ran four tests, so four boots, in 204.654s, which puts a boot at ≤~51s rather than the ~80s taken from 1257/13.

2. ⚠️ forgectl's mainnet metrics stop when the polyrepo is archived

forgectl is the only imported service that had genuinely scheduled workflows, and they are operational rather than CI:

workflow	schedule	runs
metrics-payments.yaml	every 30 min	forgectl metrics payments --payer … --otlp-endpoint …
metrics-faults.yaml	every 12 h	forgectl metrics faults …

Both target environment: mainnet and push to an OTLP endpoint, taking the payer address and endpoint from repository secrets.

Nothing is broken today — they run in fil-forge/forgectl, which still exists; the copies that came in with the subtree never ran. The hazard is the archival step: whenever that repo is archived or its workflows disabled, mainnet fault and payment metrics stop silently — a dashboard goes flat and nothing fails. Reproducing them here needs a mainnet environment and two secrets configured on this repository, which is a person's job. Sequence it with the archival, not after.

Checked: the seven services pruned earlier carry no equivalent risk. The only schedule: keys among every file that prune deleted were dependabot intervals.

3. Phase 1 needs machinery this repository does not have

The plan says to cut tags "via the existing release.yml flow". There is no release.yml — main has ci, e2e, images, itest, and none tags, releases or publishes. The plan treated old forge at f60dd59 as a starting point that already had that apparatus; this repo was built from subtree imports instead.

What survived is uneven: version.json in 8 of 10 (not forgectl, not smelt), .goreleaser.yaml in 4, Dockerfile.release in 4.

The Dockerfile.release files are goreleaser-shaped, not repo-shaped — COPY <svc> /usr/bin/<svc> copies a pre-built binary from goreleaser's dist/ context. So "nothing builds them" cannot be fixed by adding a CI job; the release flow has to exist first. hilt and swarf have one with no .goreleaser.yaml at all, so they're doubly orphaned.

And a trap worth seeing before it bites: at the monorepo root, hilt is a directory. COPY hilt /usr/bin/hilt is unambiguous in dist/, and copies an entire source tree if that file is ever built with the repository root as context — which is the context every other Dockerfile here uses.

The sequencing constraint the plan doesn't state

A submodule tag has to be <svc>/vX.Y.Z in the repository the module path names. Module paths are already github.com/fil-forge/forge/*, so a tag pushed to fil-forge/forge-2 sits where no module path resolves — go get github.com/fil-forge/forge/piri@piri/v1.2.3 looks in fil-forge/forge, the old repo, and finds nothing.

Any tag cut before the rename has to be cut again after it. The rename gates the tagging half of Phase 1. The tag scheme, the workflow itself and compat.yml do not wait on it.

Worth your eye

The forgectl metrics item is the one with a real-world consequence and a deadline attached to someone else's action, so it's the one I'd most want you to confirm I've read correctly. The rest is reconnaissance.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CGAGAib517Ae1kg8SCdcEt

---

Generated by Claude Code