Step 1 is complete: the rename and the three documentation fixes are in, and every check passes.

Checks run

check	result
forge build	ok
forge test with the verifier's fuzz seed	109 passed, 0 failed, 11 skipped (fork tests, no RPC)
forge fmt --check	clean
python3 tools/gen_template.py --check	12 artifacts byte-exact
python3 -m unittest discover -s tools	7 passed

Composer size. The names fit with room to spare, so nothing was shortened.

contract	before	after	EIP-170 headroom
Composer	23,455 B	23,377 B	1,199 B (required at least 600)
Registry	23,027 B	23,055 B	1,521 B
Renderer	11,791 B	11,712 B	regenerated template only

What changed

• Contracts. Registry is now ERC721("Sworn", "SWORN"). Composer's traitName table and the catalogSpec names carry the final names. Trait 1105 keeps First thousand since no final name was given for it. No id, rule, window, threshold or address moved.
• Fix 3. Registry.upgrade now reverts NotASharedFact(1201) for Top Weights, the same error a community T3 spec gets. The unit test and the fuzz test in test/Adversarial.t.sol were updated to expect it.
• Generator and card. FAMILIES, the metadata name prefix Sworn #<id>, and the description (now opening with "Sworn is an ownerless onchain registry...") in tools/gen_template.py; the product label and the thirteen family labels in the card SVG. The blob, offsets, TemplateData.sol and all nine goldens were regenerated.
• Docs. README, CONCEPT, CATALOG, TEMPLATES, INTEGRATION and DISCLOSURE name Sworn and the final families. CATALOG section 7 has its final-name column filled. Fix 1: INTEGRATION check 7 now says the golden test asserts the questionHash of the canonical document, not of the body. Fix 2: the CATALOG section 5 guard row says the T5 target must be zero.
• New tests in test/Rename.t.sol: name and symbol, all 25 names against the final table, catalog spec names equal the table with rules unchanged, no working name survives, unknown ids still revert, the tokenURI carries Sworn #1 and the thirteen family trait types, 1201 refused by upgrade but accepted by requestSharedFact, and the Composer headroom floor.

Left as is, deliberately. The CHAINTRAITS_FORK_RPC environment variable name, the LICENSE copyright line and the fixture file names under templates/fixtures are identifiers rather than display names, so they were not renamed. The X handle row of the name table is marked as not given, since the brief did not supply one.

Implemented all five Registry rules, updated tests, and revised the four required documents.

• forge build and forge fmt --check pass.
• Seeded forge test: 124 passed, 11 fork tests skipped.
• Runtime sizes: Registry 23,364 B; Composer 23,377 B, both below 24,576 B.

Live fork verification was blocked by RPC errors: pinned historical state was pruned; alternative endpoints returned HTTP 403.

Implemented the burn rule, deployment updates, tests, and documentation.

• Build and formatting checks pass.
• Supplied-seed tests: 145 passed, 15 opt-in skips.
• Four pinned fork tests passed separately.
• Registry: 24,495 bytes—81 bytes below EIP-170.
• Composer and Renderer bytecode unchanged.

Documented limitation: the specified preview gas cap skips the burn at the pinned mainnet block. No deployment performed.

Step 4 is complete and verified.

What was built

• tools/gen_template.py now contains the normative hive SVG in Python (hive_svg) and writes two data libraries: src/TemplateData.sol for the JSON envelope (21 slots, 22 slices, the image as one slot) and the new src/HiveData.sol with every string the Renderer needs, each stored once and pre-percent-encoded: the 65 cell hexagons, the 8 HONEY/ABOVE pairs, P(V), the 6 ring corners, the 62 interpolated path end points, the 13 cell centres, plus the markup fragments, colours and opacities, with ASCII-hex start tables and index constants.
• template/card.svg and its SVG value slots are gone. The 13 JSON attribute slots stay, and the three old goldens differ from the committed ones only in the image value (checked by parsing both).
• Goldens regenerated for direct, oracle and width, and added newcomer (3), outsider (4), honey (5), collector (6) and fullhouse (7), all with synthetic 0x…c1a1 claimants. --check verifies all 28 generated files byte-equal.
• tools/test_gen_template.py has 18 tests, including the requested step table at 32, 39, 40, 53, 70, 100, 200, 1000, 5000, 8191, 8192, 65535 giving 0, 0, 2, 5, 9, 13, 21, 39, 58, 63, 64, 64.

One scope note. The acceptance criteria require forge test to pass, and the golden tests compare the Renderer's bytes to the new goldens, so I brought src/Renderer.sol onto the new data: image(card) selects and concatenates HiveData strings with no trigonometry, and preimage splices the 21 slots. The Card struct, the tokenURI/preimage signatures, Registry and Composer are untouched. Step 5 can restructure the Renderer freely; the goldens pin what it must produce. Two existing tests that asserted on the old text grid (Rename.t.sol, ReviewChanges.t.sol) now assert on the hive.

Checks run

check	result
forge build	passes; Renderer 21,570 B runtime, 3,006 B headroom
forge test with the verifier's fuzz seed	155 passed, 0 failed, 15 opt-in fork skips
forge fmt --check	passes
python3 tools/gen_template.py --check	28 artifacts byte-equal
python3 -m unittest discover -s tools	18 tests OK

Documentation: README gained "The card image" (drawing rules, data layout, goldens, sizes), CONCEPT.md section 5 describes the hive, and test/NOTES.md records the step with its assumptions (image reads only tokenId, top and communityCount; out-of-catalog tops are clamped, never reverted) and operational notes (pure Renderer, a drawing change means regenerate and redeploy). Slither, Mythril and the fork suites were not run.

I didn't have to rewrite the Renderer: the generator-and-goldens step had already moved it onto the new hive data. I checked src/Renderer.sol against the specification and it matches, so I added the missing reports and tests. With the verifier's seed, forge build and forge fmt --check pass and forge test gives 159 passed, 0 failed, 15 fork tests skipped (those are opt-in and weren't run).

What the Renderer does:

• Per family: it draws the outline, the filled zones, the two clip paths and clipped rings for part-filled families, the rare-id dot, and the empty rings, from the level lv, the tier count n and the ring count k.
• Frame and overflow path: it draws the faint frame. The overflow path appears only when communityCount is above 39. Its length is 64 steps from 8192 upward; below that it is min(64, bitlen(count ** 8) - 41) (exponentiation).
• Token id: the token id text comes last.
• Unchanged: the JSON metadata outside the image is byte-for-byte the same, and Registry, Composer and Types are untouched.

Measurements:

	value
Renderer runtime size	21,570 B (3,006 under the 24,576 limit)
tokenURI gas, synthetic_width	10,810,085
tokenURI gas, synthetic_fullhouse	9,147,472
tokenURI gas, synthetic_honey	9,589,924

Tests added in test/Goldens.t.sol:

• The gas report, with each call required to stay under 30M gas.
• The runtime size report, with a check that a fresh deployment has identical code.
• No path at a count of 39 and a path at 40.
• Identical images at 8192 and at the largest possible count, so count ** 8 never overflows.
• 40 and 53 render differently, which confirms exponentiation rather than XOR.

The existing tests already cover the rest: all 8 goldens are compared byte-for-byte through Renderer.tokenURI, and the steps table is checked onchain. To share the card setup, I moved the width, honey and fullhouse cards into helper functions.

Operational note: reading one card's metadata costs about 9–11M gas. Marketplaces and indexers calling tokenURI need an RPC whose call gas limit is above that; most public RPCs allow 30M or more. This is written up in test/NOTES.md. Nothing was deployed, and the Renderer still takes no constructor arguments and has no storage.

There are untracked files in the repository root (shell profiles, .claude/, .idea, .vscode, .mcp.json) that I didn't create. I left them alone, and they shouldn't be part of the submission.

The review is done and .imd-findings.json holds one finding plus a 20-row coverage record. The tree is otherwise unchanged (git status is clean apart from the findings file, which is ignored).

What I checked and found correct

• (B) Renderer vs the normative SVG. The generator's drawing in tools/gen_template.py matches the objective line by line: element order, literals, the .1f formatting, HONEY/ABOVE, the ring count per slot, the opacity table, and the steps rule with its guard at 8192. A differential test then compared the Renderer's percent-encoded image against the Python output for 49 cards: random tops, every boundary count (0, 13, 26, 39, 40, 53, 8191, 8192, 2^32, 2^256-1), all-empty, all-full and all-partial cells. All 49 were byte-equal by keccak.
• No other metadata byte changed. The direct, oracle and width preimages at the step-3 commit and now differ only in the image value, with identical key order.
• (A) Rename and rules. The Composer diff is names only. The Registry diff outside the burn rule is the rename, the Intake price check, the 6.4 IMD spec fee, the 1201 error split, one trait per sponsored call, nine per IDMD token, membership on both pool paths, and the shared UTC-day limit. upgrade stays non-payable with no daily limit and no burn call. New storage is exactly the per-token counter, the per-wallet day and the executor address. No receive or fallback exists, and every path forwards or refunds msg.value.
• Sizes and checks. Registry 24,495 B (81 B headroom), Composer 23,377 B, Renderer 21,570 B. forge test passes 159 tests with 15 fork skips, and gen_template.py --check reports 28 artifacts equal.

Finding (low)

• Code-less executor blocks all pool claims at src/Registry.sol:718. The try/catch catches a revert but not the return-data decoding, so an executor address with no code (or one returning fewer than three words) reverts claimSponsored and upgradeSponsored for every wallet. That contradicts DISCLOSURE.md's "a failing executor never blocks a claim", and the constructor validates the other seven addresses but accepts any executor value. Reproduced with Base's mocks and executor 0xBEEF: the claim reverts instead of being recorded with BurnSkipped code 1. It is low because the real BurnExecutorV2 cannot lose its code, so only a wrong deployment argument reaches it, but an ownerless registry has no way to repair it afterwards.