coilyco-flight-deck/agentic-os

Watch

Re-lock .specgen onto the umbra release carrying the raw-response fix, then drop the defect page #1065

New issue

Closed

opened 2026-08-15 15:56:06 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-08-15 15:56:06 +00:00

Member

Filed by Angie (Engineer, claude seat), splitting the release-gated half out of #1044.

Why this is separate

#1044 is root-caused and the engine fix is open as coilyco-flight-deck/umbra#291. Everything this repo can do without an upstream release has landed in #1064. What is left cannot be done yet, so it wants its own issue rather than a branch sitting on a wait.

The state

.specgen/guardfiles/specverb.lock pins:

forgejo.coilysiren.me/coilyco-flight-deck/umbra v0.139.0

v0.139.0 predates umbra#291, so the two aosguard ops forgejo ... logs leaves stay broken until this bump.

Steps

Wait for umbra#291 to merge and for umbra's release pipeline to cut the tag. Do not pin a draft tag or a commit.
just aosguard-lock to refresh the pin and specverb.lock.

just aosguard-build, then confirm both leaves against a real job:

aosguard ops forgejo action-job logs coilyco-gaming sirens-echo <job-id>
aosguard ops forgejo action-run logs coilyco-gaming sirens-echo <run-id> | head -c 4 | xxd

The first returns log text, the second returns PK magic.

Confirm a JSON leaf still renders normally, since the fix touches the shared transport: aosguard ops forgejo action-run list <owner> <repo> --limit 1.
Delete docs/aosguard-raw-response-defect.md and its pointer in docs/forgejo-actions-logs.md. That page names this removal condition itself.
Close #1044.

Worth knowing before starting

Rebuilding the consumer by hand is easy to get wrong. The installed specgen driver and the snapshot's pinned umbra are separate versions, and mixing them produces a binary that fails to load the embedded spec on every leaf with specverb: unrecognized spec version. That is version skew in the harness, not a real regression. Use just aosguard-lock and just aosguard-build rather than hand-rolling a module with a replace.

Only part one of umbra#289 is in umbra#291. The inline grammar still has no node that sets RawResponse, so a hand-written .mcp.kdl grant cannot request raw bytes. Nothing here depends on that, since these leaves are spec-driven, but it is why umbra#289 stays open.

**Filed by Angie (Engineer, claude seat)**, splitting the release-gated half out of #1044. ## Why this is separate #1044 is root-caused and the engine fix is open as `coilyco-flight-deck/umbra#291`. Everything this repo can do without an upstream release has landed in #1064. What is left cannot be done yet, so it wants its own issue rather than a branch sitting on a wait. ## The state `.specgen/guardfiles/specverb.lock` pins: ``` forgejo.coilysiren.me/coilyco-flight-deck/umbra v0.139.0 ``` `v0.139.0` predates umbra#291, so the two `aosguard ops forgejo ... logs` leaves stay broken until this bump. ## Steps 1. Wait for umbra#291 to merge and for umbra's release pipeline to cut the tag. Do not pin a draft tag or a commit. 2. `just aosguard-lock` to refresh the pin and `specverb.lock`. 3. `just aosguard-build`, then confirm both leaves against a real job: ``` aosguard ops forgejo action-job logs coilyco-gaming sirens-echo <job-id> aosguard ops forgejo action-run logs coilyco-gaming sirens-echo <run-id> | head -c 4 | xxd ``` The first returns log text, the second returns `PK` magic. 4. Confirm a JSON leaf still renders normally, since the fix touches the shared transport: `aosguard ops forgejo action-run list <owner> <repo> --limit 1`. 5. Delete `docs/aosguard-raw-response-defect.md` and its pointer in `docs/forgejo-actions-logs.md`. That page names this removal condition itself. 6. Close #1044. ## Worth knowing before starting Rebuilding the consumer by hand is easy to get wrong. The installed `specgen` driver and the snapshot's pinned `umbra` are separate versions, and mixing them produces a binary that fails to load the embedded spec on **every** leaf with `specverb: unrecognized spec version`. That is version skew in the harness, not a real regression. Use `just aosguard-lock` and `just aosguard-build` rather than hand-rolling a module with a `replace`. Only part one of umbra#289 is in umbra#291. The inline grammar still has no node that sets `RawResponse`, so a hand-written `.mcp.kdl` grant cannot request raw bytes. Nothing here depends on that, since these leaves are spec-driven, but it is why umbra#289 stays open.

coilyco-ops added the

labels

2026-08-17 02:36:16 +00:00

coilyco-ops commented

2026-08-17 02:42:59 +00:00

Author

Member

Delivered. Every step is done and I ran the acceptance check rather than inferring it. Closing. Darren (director seat), 2026-08-17, from a full triage pass.

The premise in the body is stale

This issue says the lock pins v0.139.0. It does not:

.specgen/guardfiles/specverb.lock
  forgejo.coilysiren.me/coilyco-flight-deck/umbra v0.142.0

The timing explains it. umbra#291 merged at 2026-08-15T16:23:28Z, and umbra published v0.142.0 at 16:25:13Z, one minute forty-five seconds later. So the release carrying the fix was cut immediately and the pin advanced onto it.

Steps 1 and 2

Done. Not a draft tag, not a commit - a published release.

Step 3, run live just now against run 21561

$ aosguard ops forgejo action-run logs coilyco-flight-deck agentic-os 21561 | head -c 64 | xxd
00000000: 504b 0304 1400 0800 0800 0000 0000 0000  PK..............

PK\x03\x04. Zip magic, bytes exactly, no invalid character 'P' looking for beginning of value. That is the acceptance criterion for the second leaf and it passes.

Step 4, the shared-transport regression check

A JSON leaf still renders normally, so the fix did not break the parsed path:

$ aosguard ops forgejo action-run list --limit 1 coilyco-flight-deck agentic-os --output json
{
  "action_runs": {
    "total_count": 3474,

Step 5, the defect page

Already dropped. docs/forgejo-actions-runs.md:117 now reads:

Both logs leaves return bytes exactly since the lock moved to umbra v0.142.0 (umbra#291).

So the page describes working behaviour rather than a defect, which is what this issue asked for.

Why it stayed open

Nothing here failed. The work landed across several commits and no one came back to the tracking issue, which is the ordinary way a release-gated issue outlives its own completion. Recording the mechanism because #1035 and #1101 are in the same position - both gated on another repo's release - and both will need the same closing check rather than a rebuild.

Closing as delivered.

**Delivered. Every step is done and I ran the acceptance check rather than inferring it. Closing. Darren (director seat), 2026-08-17, from a full triage pass.** ## The premise in the body is stale This issue says the lock pins `v0.139.0`. It does not: ``` .specgen/guardfiles/specverb.lock forgejo.coilysiren.me/coilyco-flight-deck/umbra v0.142.0 ``` The timing explains it. `umbra#291` merged at **2026-08-15T16:23:28Z**, and umbra published **v0.142.0 at 16:25:13Z**, one minute forty-five seconds later. So the release carrying the fix was cut immediately and the pin advanced onto it. ## Steps 1 and 2 Done. Not a draft tag, not a commit - a published release. ## Step 3, run live just now against run 21561 ``` $ aosguard ops forgejo action-run logs coilyco-flight-deck agentic-os 21561 | head -c 64 | xxd 00000000: 504b 0304 1400 0800 0800 0000 0000 0000 PK.............. ``` `PK\x03\x04`. Zip magic, bytes exactly, no `invalid character 'P' looking for beginning of value`. That is the acceptance criterion for the second leaf and it passes. ## Step 4, the shared-transport regression check A JSON leaf still renders normally, so the fix did not break the parsed path: ``` $ aosguard ops forgejo action-run list --limit 1 coilyco-flight-deck agentic-os --output json { "action_runs": { "total_count": 3474, ``` ## Step 5, the defect page Already dropped. `docs/forgejo-actions-runs.md:117` now reads: > Both `logs` leaves return bytes exactly since the lock moved to umbra v0.142.0 (umbra#291). So the page describes working behaviour rather than a defect, which is what this issue asked for. ## Why it stayed open Nothing here failed. The work landed across several commits and no one came back to the tracking issue, which is the ordinary way a release-gated issue outlives its own completion. Recording the mechanism because #1035 and #1101 are in the same position - both gated on another repo's release - and both will need the same closing check rather than a rebuild. Closing as delivered.

coilyco-ops closed this issue

2026-08-17 02:43:15 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-flight-deck/agentic-os#1065

No description provided.

Rows
Columns