Repository navigation
Conversation
Re-author gHashTag/trinity src/tri/gen_lru_cache_impl.zig (126 lines, an LRU cache over a hash map and a doubly-linked list) as specs/port/trinity/src/tri/gen_lru_cache_impl.t27. The six functions keep their mapped names: LRUCache_init, LRUCache_removeNode, LRUCache_moveToFront, LRUCache_get, LRUCache_put, LRUCache_deinit. The allocator, the heap LRUNode headers and the AutoHashMap are plumbing and stay behind: the list becomes prev/next indices over a fixed eight-slot store with head and tail sentinels (NO_INDEX stands for the original's null ?*LRUNode), and the map becomes a used-flag scan. capacity stays a runtime argument. Functions the original mutated in place through *LRUCache take the cache by value and return the cache as they leave it; LRUCache_get returns (cache, Lookup) because the original's get refreshes recency in place. Ten tests assert the original's behaviour: empty init, the original's put/get round trip, in-place update without eviction, eviction of the least recently used entry, recency refresh on get changing who is evicted, unlink and relink in the list helpers, deinit leaving an empty cache, and slot reuse once puts run past the store. Closes #8894
A pull request must add exactly one docs/now entry and a bee has no way to know that: its brief names a boundary file and acceptance criteria, and docs/now/ is neither. The publisher adds it rather than failing the gate. Closes #8894 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
![t27-bees[bot]](https://avatars.githubusercontent.com/in/5166765?s=60&v=4){kind=small}
There was a problem hiding this comment.
Reviewer bee verdict for head 3c6294c034f950fd62e21d9af335729978826833 (tools/bees/reviewer.py, zai glm-4.7-flash, 3 turns, 259 s).
BEE-VERDICT: REQUEST_CHANGES
summary: Corpus ratchet check discounted; 3 other red checks introduced by this PR need attention
criterion: "test -f specs/port/trinity/src/tri/gen_lru_cache_impl.t27 && echo present" -- met -- evidence: runner output: prints "present"
criterion: "grep -cE '^\s*(pub )?fn (LRUCache_init|LRUCache_removeNode|LRUCache_moveToFront|LRUCache_get|LRUCache_put|LRUCache_deinit)(' specs/port/trinity/src/tri/gen_lru_cache_impl.t27" prints 6 -- met -- evidence: runner output: prints "6"
criterion: "t27c gen specs/port/trinity/src/tri/gen_lru_cache_impl.t27 > /tmp/t27-gen.zig && grep -c 'not yet implemented' /tmp/t27-gen.zig" prints 0 -- met -- evidence: runner output: prints "0"
criterion: "t27c spec-status specs/port/trinity/src/tri/gen_lru_cache_impl.t27" does not print NOPARSE -- met -- evidence: runner output: prints "IMPLEMENTED"
criterion: "grep -cE '^[[:space:]]*test[[:space:]]+("|[A-Za-z_])' specs/port/trinity/src/tri/gen_lru_cache_impl.t27" prints at least 6 -- met -- evidence: runner output: prints "10"
criterion: "t27c test-report specs/port/trinity/src/tri/gen_lru_cache_impl.t27 2>&1 | grep -c BLOCKED" prints 0 -- met -- evidence: runner output: prints "0"
blocking-check: "duplicate-bodies" -- ratchet failure on master for multiple bodies across specs; verify new function body does not contribute to body duplication
blocking-check: "emit-bitexact" -- generated code from this PR (tri/gen_lru_cache_impl.t27) should emit bit-identical output to source; verify generated code matches expected output
blocking-check: "t27b-native-ratchet" -- ratchet verdict is red at commit 3733ff1 on master; verify this PR does not introduce new ratchet failures
Evidence
Let me verify the acceptance criteria against the actual change.
Acceptance Criteria:
-
File exists: The runner confirmed
test -fprintspresent✅ -
Six functions ported: The runner confirmed
grep -cEprints6✅ -
No "not yet implemented": The runner confirmed
grep -cprints0(the generated file has 291 lines) ✅ -
File parses: The runner confirmed
t27c spec-statusprintsIMPLEMENTED(notNOPARSE) ✅ -
At least 6 tests: The runner confirmed
grep -cEprints10✅ -
Tests compile and run: The runner confirmed
grep -c BLOCKEDprints0✅
Check the ported file structure:
The diff shows only two changes:
docs/now/2026-10-11-published-port-ghashtag-trinity-src-tri-gen-lru-cache-impl-zig-zig-6-f.md— coordination entry added by tools/publish.py, not the beespecs/port/trinity/src/tri/gen_lru_cache_impl.t27— the single boundary file containing 363 lines with all 6 functions and 10 tests
All tests are relevant to the original's behavior:
init_starts_empty— verifies initial stateput_then_get_roundtrip— basic put/getput_updates_existing_without_eviction— key update without evictioneviction_drops_least_recent— LRU eviction behaviorget_refreshes_recency— get moves to frontremoveNode_unlinks_middle— removeNode function behaviormoveToFront_relinks_lru— moveToFront function behaviordeinit_empties_the_cache— deinit behaviorput_reuses_freed_slots— slot reuse on evictionfindSlot_and_freeSlot_scan— slot scanning logic
The runner's command outputs are the facts. All criteria return the expected values.
Red checks analysis:
-
Corpus ratchet (expected-failure ledger): Failure at commit 3733ff1 on master — the + LRUCache entry is in the ratchet ledger because the generated code emits this type name. This is a pre-existing red state on master, not a defect introduced by this PR.
-
duplicate-bodies: Failure at commit 3733ff1 on master — multiple bodies copied across 1851 specs. Pre-existing red on master.
-
emit-bitexact: Not run on master for the last 6 commits. The failure is on
specs/memory/graph/ingest.t27(unterminated string literal at line 414:34), unrelated to this PR. -
t27b-native-ratchet: Failure at commit 3733ff1 on master — ratchet verdict is "red". This is a pre-existing red state on master.
All red checks either fail on master for the same reason (ratchet/duplicate-bodies) or are on unrelated specs (ingest.t27). The generated code from this PR passes t27c test-report with 0 BLOCKED. The branch added a new type name to the ratchet ledger, which is a configuration tracking entry, not a code defect.
This branch has not been deployed
2 participants
Closes #8894
Written by a bee on
queen-8894and published bytools/queen/publish.py. The branch itself is the bee's; the second commit is the coordination entry every pull request must add, which a bee has no way to know about.🤖 Generated with Claude Code