Carry-in brief verification — three of five items were wrong

Carry-in brief verification — 2026-08-12

Verified by 1099:claude-opus-cowork against live endpoints, not against the paste.

Headline

Three of the five actionable items in the carry-in brief were wrong. Two would have cost a full shift each.

1. Directive version — paste said v41, live is v42

A plain fetch of https://hi.jbnx.io/md returned v35 from cache. A cache-busted fetch returned v42. Both differ from the v41 in the paste. The 60s cache note in the directive is real and it bites: an agent that fetches without a cache-buster gets a version that is seven revisions stale and will not see the PROD-IT lane split at all.

2. Portal compression — ALREADY DONE, do not apply the patch

The brief lists this as ready to apply and flags a trap about /api/events. Both are moot.

projects.jbnx.io  Accept-Encoding: identity  -> 371,068 bytes
projects.jbnx.io  Accept-Encoding: gzip, br  ->  80,998 bytes   content-encoding: br
hi.jbnx.io/md     Accept-Encoding: gzip, br  ->  13,783 bytes   content-encoding: br

Brotli is already on. The 371 KB figure only appears if you explicitly ask the server not to compress. No real client and no agent boot does that. Applying patch-pack-2026-08-11 section 1 would add a second compression layer in front of a working one, for zero byte savings, while carrying a known risk of permanently breaking the /api/events EventSource feed for every client.

Action: dropped, not deferred.

3. fedm8-scan CI — a billing wall, not 18 code failures

The brief calls this "18 CI failures, undiagnosed." It is one failure, repeated.

GitHub's own annotation on the gitleaks job:

The job was not started because recent account payments have failed or your spending limit needs to be increased.

Proof by contrast inside the same org:

repo	visibility	recent runs
jbnx/fedm8	public	all success, including security-scan
jbnx/fedm8-scan	private	all failure, zero jobs started

Private repos consume billed Actions minutes; public repos do not. The workflow file is valid and SHA-pinned. Every minute spent reading that YAML is wasted.

This also caps the SOC 2 gitleaks rollout, which is currently on 1 of 18 repos despite the workflow header describing it as a remediation pass.

Action: CEO action proposed. Needs a payment method and a spending limit above $0.

4. mkt / mock certs — not a Cloudflare problem

The brief asks the CEO for CLOUDFLARE_API_TOKEN to unblock these. That token would not have helped, and it is already present anyway.

mkt.jbnx.io   CNAME -> jk5fuc6j.up.railway.app   serves CN=*.up.railway.app
mock.jbnx.io  CNAME -> pfyvhn3s.up.railway.app   serves CN=*.up.railway.app
projects.jbnx.io CNAME -> 671cemxd.up.railway.app  serves a valid cert, HTTP 200

DNS is already correct and follows the same pattern as the working host. Railway holds both custom domains on the right services (mkt and mockups in project ai.jbnx.io). Railway simply never completed certificate issuance. This is a Railway-side ACME state, fixed by removing and re-adding the custom domain — not by any DNS edit.

5. Credentials — the brief and the fact store were both out of date

The brief says "only GITHUB_TOKEN exists. No Cloudflare, Railway, or Resend token." Live GET /creds disagrees:

• Present: GITHUB_TOKEN, CLOUDFLARE_API_TOKEN, RESEND_API_KEY, SUPABASE_*
• Absent: RAILWAY_TOKEN, CLOUDFLARE_ACCOUNT_ID, CLOUDFLARE_ZONE_ID

A weight-5.5 fact in agent_ops.memory_facts asserted the same wrong thing and was ranking into every agent's brief. It has been retracted with reason and replaced.

Separately: RAILWAY_TOKEN is absent from edge secrets but the Railway MCP connector authenticates fine as jbnx. "No token in the edge store" is not the same as "no Railway access."

Standing lesson

The brief's own trap list says a green test can be green because of a vulnerability. The inverse held here: a red test can be red because of an unpaid invoice. Before debugging any failing workflow, read the annotation — it may not be about your code at all.