The lost enum variants were never lost: they survive in the sibling repo, and 29 of 31 are restored

[gHashTag]

I asked whether twelve variant-less enum declarations could be recovered or should be deleted. Both premises were wrong: there are 31, not twelve, and all 31 are recoverable — the variant names survive in full, one repository over.

Where they went

git log --follow on every affected file shows they were born empty at 90bc797ec (2026-04-09). Nothing in this repo ate them. The loss happened one step earlier, in the .tri → .t27 conversion that created these files.

The ancestors are in /Users/playom/trinity-fpga, dated 2026-02-28 — six weeks before the conversion, so the ancestry direction is established by date rather than assumed. Those upstream YAML specs carry the variant names in full:

specs/tri/tri_http.tri:7      -> [GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS]
specs/tri/tri_logging.tri:7   -> [debug, info, warn, error]
specs/tri/tri_terminal.tri:7  -> [black, red, green, yellow, blue, magenta, cyan, white, default]

The ancestry is proved, not asserted

Two independent fingerprints that agree:

1. Field lists match exactly, including order — the converter copied plain struct fields verbatim. 9/9 structs for swarm_agents, 6/6 sacred_governance, 5/5 eternal_monitor and batch_runner, 4/4 autonomous_lifecycle, 3/3 faculty_board, 2/2 http, 1/1 filesystem and logging.
2. The line-3 header comment is a verbatim lift of a description: string from the ancestor — 15 of 17 hit; the two misses are a file with an empty header and one whose header came from a neighbouring description.

And the loss mechanism is demonstrable, not inferred. specs/tri/utils/exit_codes.t27 is the control: its upstream variants: bullets are written - success: 0, with a value, and the converter kept every one. Bullets without a value were dropped. That is the bug, visible in a case where it did not fire.

The test written to catch this was passing green

enum : , does not emit nothing. It emits struct { enum: void } — a one-field struct. So specs/tri/net/http.t27's

then @typeInfo(HttpMethod).@"struct".fields.len >= 1

passed, on the marker field. The assertion was true of a type that could not represent GET, POST or anything else, and method_to_string had nothing to switch on.

That is the third time this week a test has passed for a reason unrelated to what it claimed. It is also why "leave them" was the most expensive option of the three: an empty declaration is not visibly empty.

Done

29 of 31 repaired, each verified by running. Deleting — the only option that looked defensible before the ancestry was established — would have destroyed meaning that exists in writing and broken ~40 sibling declarations that reference these types by name; swarm_agents alone has 8 fields typed AgentType/AgentStatus/TaskStatus.

Measured: ast-check valid 293 → 294, errors 591 → 590, 0 specs worse, parse gate holds at 105. The run scan is still going and its figure is absent here rather than guessed.

[gHashTag]

The run scan finished, cache isolated and corpus clean:

	before	after
compiled and ran	206	211
assertions actually executed	878	902
ASSERTION FAILED	8	7
of those, running zero tests	31	31

Both repairs show up where they should. The 24 new assertions are mostly lsp/protocol's 15 length tests plus the enum variant lists becoming assertable; the failure count drops by one because msgpack and its neighbours stopped tripping on a shape that no longer exists, while lsp_completion_request_create joins as the deliberate one.

Worth stating plainly: the 902 is not simply "24 more checks". Fifteen of those tests assert a string literal's length against the same literal in the same file — comptime-known, no behaviour exercised. That is exactly the claim the type used to make and no more, and it is the honest replacement for what []const u8 dropped. The enum restorations are the substantive half: HttpMethod can now represent GET, which it could not while it was struct { enum: void }.