Characterize `registerMetadataEndpointsInner` (2,328 lines, 20% of rest-server.ts) — read and propose, do not split blind

[qq9340100]

Filed by the domain:cli seat on the 2026-08-15 maintainer ruling on #5949 (「接受你的建议」, recorded at #5949 comment 5301726968). Card 2 of the two extractions that ruling authorised.

⚠️ This is NOT the ADR-0076 D11 decomposition. That was ruled closed (option B). This card exists because this one method is the single place in the file where size is itself the defect.

The justification — prism ③, comprehension rather than collision

RestServer registers routes through 18 registerXxxEndpoints methods, and 17 of them are domain-sized (36–951 lines) and internally delineated. One is not:

method	lines
registerMetadataEndpointsInner	2,328
registerDataActionEndpoints	951
registerFormEndpoints	575
(15 others)	36–430

2,328 lines is 20% of the file in one method, with no internal delineation. An agent changing anything inside it must hold the whole thing — and this repo dispatches agents at this code constantly.

That is a different problem from the one option B closed. B ruled that the file's domain delineation is adequate. This method has no delineation to be adequate.

Scope — ⛔ read and propose. Do NOT split.

The deliverable is an analysis comment on this card, not a refactor PR:

1. What is in it — the endpoints it registers, grouped by whatever cohesion actually exists (or a finding that there is none).
2. Where the seams are, if any — and whether they are real seams or an arbitrary cut that would make things worse.
3. A proposed split with its cost, or an honest recommendation that it should not be split and why.

⛔ Do not open a refactor PR from this card. It has no internal delineation, so it cannot be moved as a unit before it is understood — splitting it on a first read is exactly how a 2,328-line method becomes three tangled 800-line ones. pr: null with a thorough analysis is the expected and complete delivery.

⚠️ If the analysis concludes it should be split, that is a follow-up card and it needs its own dispatch — which will also need checking against option B, since a split large enough to matter starts to look like the programme B closed.

Premise to verify

Measured on origin/main @ 04d03c3a0: the method spans roughly lines 4686–7013. Re-locate by symbol — the file has taken merges since, and stated line numbers have misled this lane three times today.

Not claimed

• No user impact and no known defect inside it. Prism ② on [finding] ADR-0076 D11 的第二半从未落地:packages/rest/src/rest-server.ts 已 8593 行(ADR 记录约 5.1k),且无 issue 承接 #5949 found no measured business pull anywhere in this file. This card buys error-resistance for the agents who work here, nothing else.
• ⛔ Line counts are not an argument — [finding] ADR-0076 D11 的第二半从未落地:packages/rest/src/rest-server.ts 已 8593 行(ADR 记录约 5.1k),且无 issue 承接 #5949's line-count series was retired by the same ruling. The argument is one method, no internal boundary, which is a structural fact, not a size metric.

Refs: #5949 (the ruling and the four-prism analysis), ADR-0076 D11.

[qq9340100]

Claim: PM loop round 14
Session: session_01NaS1PAHJcPfAA2acnV53Tn
Branch: claude/issue-8851-characterize-metadata-endpoints (analysis only — a branch may never be pushed, and that is fine)
Worktree: objectstack-issue-8851
Domain: domain:cli
File surface: read-only — packages/rest/src/rest-server.ts. The deliverable is an analysis comment on this card; ⛔ no PR.
Container & model: L, mode:subagent, model: opus
Serial constraints cleared:

1. No open PR touches packages/rest at claim time.
2. ⚠️ Extract rest-server.ts's error/fault-classification prologue — it is ADR-0112's concern, not the REST server's #8850 is dispatched in the same batch and edits this same file. That is deliberate and safe in this direction: Extract rest-server.ts's error/fault-classification prologue — it is ADR-0112's concern, not the REST server's #8850 moves the module-level prologue before the first class declaration, while this card characterises registerMetadataEndpointsInner inside the class. No region overlap, and this card produces no diff at all, so there is nothing for the merge queue to arbitrate. What it does mean: line numbers will move under you mid-analysis. Re-locate by symbol, always, and if you quote a line number in the analysis, quote the ref you measured it at.

Dispatched under the maintainer's direct channel and the 2026-08-15 ruling on #5949 (「接受你的建议」 ⇒ option B).

⛔ The most important constraint on this card is what NOT to deliver

Read and propose. Do not split. pr: null with a thorough analysis is the expected and complete delivery, not a fallback. A 2,328-line method with no internal delineation cannot be moved as a unit before it is understood — splitting it on a first read is precisely how it becomes three tangled 800-line ones.

The three things the analysis owes: what is in it (grouped by whatever cohesion actually exists — or a finding that there is none); where the seams are, including whether they are real seams or an arbitrary cut that would make things worse; and a proposed split with its cost, or an honest recommendation not to split and why. The last option is a first-class answer here.

⚠️ If you conclude it should be split, that is a follow-up card needing its own dispatch — and it will need checking against option B, since a split large enough to matter starts to resemble the programme that ruling closed.

⛔ Line counts are not the argument — #5949's line-count series was retired by the same ruling, and the retirement is not decorative. The argument is structural: one method, no internal boundary, in a file this repo dispatches agents at constantly. Prism ② found no measured business pull anywhere in this file and no known defect inside this method; this card buys error-resistance for the agents who work here and nothing else. Say so plainly rather than inflating it.

---

Generated by Claude Code

[qq9340100]

Characterization of registerMetadataEndpointsInner — read, measured, and a recommendation NOT to split. ⛔ No PR, by design. No diff was produced and rest-server.ts was not touched.

Every number below is measured on origin/main @ cc5c07b80. Because #8850 was editing this file beside me, I pinned a worktree at that sha and located everything by symbol through the TypeScript AST, never by line number.

---

0. Premise re-measurement — both premises hold, one reading does not

stated on the card (@ 04d03c3a0)	measured (@ cc5c07b80)
method spans ~4686–7013	4686–7009, 2,324 lines
the other 17 methods span 36–951 lines	32–938 lines

Both hold within drift. What does not hold is the structural reading built on top of them, and that is the whole of section 1.

---

1. ⚠️ "One method, no internal boundary" is false — measured

The method is not an undifferentiated mass. Its body is 20 top-level statements containing 21 route-registration call sites (23 mounted paths — two call sites sit inside for…of loops over path spellings). Every one is a separate, closed this.routeManager.register({ … }) statement.

Per-route block sizes inside the method:

block	total	code
GET /meta/:type — the LIST handler	428	237
GET /meta/:type/:name — the ITEM handler	523	223
PUT /meta/:type/:name	144	72
GET …/published (loop, 2 paths)	151	58
DELETE /meta/:type/:name	110	59
PUT /meta/:type/:section/:name	101	59
GET /meta/book/:name/tree	100	74
(14 remaining blocks)	12–89	3–52

Median route block: 61 total lines, ~50 code lines. The largest unit an agent must hold to change one route is 237 code lines, not 2,324.

The comparison the card's table could not make

The card ranks the 18 registerXxxEndpoints methods by total size. Ranked instead by delineation per unit — how big is the largest thing you must hold — the order changes:

method	total	routes	largest route	median route
registerMetadataEndpointsInner	2,324	21	521	61
registerDataActionEndpoints	938	9	375	41
registerFormEndpoints	545	3	167	166
registerAnalyticsEndpoints	238	1	215	215
registerBatchEndpoints	425	5	181	51
registerCrudEndpoints	373	6	74	55

registerAnalyticsEndpoints is one 215-line handler — a method with no internal boundary at all. registerFormEndpoints is three handlers averaging 166 lines. By the card's own criterion, registerMetadataEndpointsInner is better delineated than either of them. It is not the least-delineated method in the class; it is the method with the most units.

So the reading that "17 are domain-sized and internally delineated, one is not" is falsified in both directions: this one is delineated, and at least two of the other 17 are less so.

What is actually true, and it is a different fact: this method registers 21 routes where the next-busiest registers 9. It is not undelineated; it is populous.

One real, cheap defect in navigability

registerMetadataEndpointsInner is the only registerXxxEndpoints method in the class with no JSDoc header at all. All 17 others have one. Its parent wrapper registerMetadataEndpoints carries a 19-line docblock — about the auth guard, not about the route inventory. An agent landing at line 4686 gets no map of the 21 routes below it. That is a real navigational cost, and it costs ~30 lines to fix.

---

2. What is in it — the 21 call sites, grouped by the cohesion that exists

There is cohesion, and it is six groups:

A · Catalogue and cross-type operations — 5 sites, 157 code lines
GET /meta · GET /meta/types · GET /meta/diagnostics · GET /meta/_drafts · POST /meta/_migrate-stored
Type-catalogue and whole-deployment sweeps. Registered first because they must beat the /:type catch-all.

B · Type-scoped list — 1 site, 237 code lines
GET /meta/:type — the LIST handler.

C · Item reads — 5 sites / 7 paths, 392 code lines
GET /meta/:type/:name (ITEM) · …/references · …/layers · GET /meta/:type/:section/:name (compound) · …/published (both arities).

D · Item writes — 3 sites, 190 code lines
PUT /meta/:type/:name · PUT /meta/:type/:section/:name · DELETE /meta/:type/:name.
The two PUTs are word-for-word twins; the file says so and meta-501-envelope.test.ts pins their byte-equality.

E · Version lifecycle — 5 sites, 184 code lines
…/history · …/audit · …/publish · …/rollback · …/diff.

F · Domain-derived reads that merely live under /meta — 2 sites / 3 paths, 124 code lines
GET /meta/book/:name/tree (ADR-0046 §6 book spine resolution) · GET /meta/objects|object/:name/state/:field (ADR-0020 D3.3 FSM introspection, via @objectstack/objectql).
These two are not metadata CRUD at all. They are the most semantically separable things in the method.

---

3. Where the mass actually is — and what it is made of

	total	code	comment	blank
the method	2,324	1,289	968	67

42% of the method is comment, and sampled across the whole span it is explanatory prose recording why — not commented-out code. Growth over the 8 days of history I could reach:

date	total	code	comment	routes	top-level stmts
2026-08-07	1,371	951	365	17	18
2026-08-10	1,858	1,141	655	18	18
2026-08-11	2,044	1,244	735	21	20
2026-08-15	2,324	1,289	968	21	20

⛔ Not offered as a size argument — the card retired that, correctly. It is offered because it answers a structural question: the unit count went 17 → 21 while the total grew 70%. The method did not become less delineated over that week. It became better documented (comments +165%, code +36%). Whatever grew here, it was not tangle.

---

4. The change history — the measurement that decides the seam question

The clone was shallow (is-shallow-repository = true, 140 commits) — the trap this card's lineage recorded on 2026-08-07 and again on 2026-08-15. I made it three-for-three, then repaired it with an explicit git fetch --deepen=600, which reaches back to 2026-08-07 (1,273 commits). Numbers below are for that 8-day window and are floors, not totals.

• 65 commits touched rest-server.ts.
• 17 of them touched this method's line range (git log -L, which follows the range through history).

For each, I re-parsed the file at that commit, re-located the method by symbol, and mapped its diff hunks onto the method's own top-level statements:

commit	subject	route-blocks touched
f3f855ac1	refuse a repeated single-valued query parameter (#6877)	12 / 18
54adb1faf	attribute a bearer-authenticated metadata write (#7749)	5 / 20
a95463464	mask object schemas on every /meta exit, ADR-0106 (#6612)	3 / 18
870f90cec	/meta 501 refusals into the ADR-0112 envelope (#7035)	3 / 18
6b7129a56	prune nav entries whose destination cannot serve (#7912)	2 / 20
cc3555e78	mount six ledgered-but-dead routes (#7526)	2 / 20
73648ba29	the remaining three write doors demand manage_metadata (#7019)	2 / 18
(9 others)	single-route corrections	1 each

9 single-block, 7 multi-block. So most edits are local — but the multi-block ones are the higher-severity class: capability gates, error envelopes, per-caller masking, actor attribution, query multiplicity. And several exist because a previous single-route edit missed its twins: #7019 finishing what #6603 started, #6241 finishing what #3984 ruled, #7035 converging three divergent 501 shapes, #5881 finding a gate that only ran on the non-default branch.

The cross-cutting concerns run perpendicular to the route groups

concern	reach inside the method	groups spanned
handleRouteError	17 blocks	A B C D E F
refuseRepeatedQueryParams (#6877)	14 sites / 13 blocks	A B C D E F
registration order (pinned by meta-route-registration-order.test.ts)	whole method	A B C E F
501 NOT_IMPLEMENTED refusals	13 sites	A C D E F
ADR-0046 §6.7 audience gate	3 route blocks	B C F
ADR-0106 object masking	3 blocks each for resolveObjectMasker / maskObjectDocument	B C
resolveMetaWriteActor (#7749)	5 blocks	D E
manage_metadata capability gate	4 sites	A D

Two of the eight span all six groups; a third spans five. This is the crux: the seams you can see (route groups) are orthogonal to the axis along which this code actually changes (cross-cutting policy sweeps). A cut along the visible seam converts the dominant change shape from a within-file sweep — greppable, reviewable in one diff, and where a missed sibling shows up as an adjacent unconverted literal — into a cross-file sweep. The method's own history is a record of missed siblings happening even with co-location.

---

5. The seams, assessed one by one

A|B|C|D|E cuts — arbitrary, would make things worse. They sever the twin relationships (PUT single ↔ PUT compound in D; LIST ↔ ITEM gate parity across B|C, which #7912's own comment names) and they cut across every row of the table above.

F is a real seam — the book-tree and FSM reads are genuinely different concerns that happen to be mounted under /meta. But they are 124 code lines out of 1,289, they still carry refuseRepeatedQueryParams, handleRouteError, resolveProtocol and isScoped, and moving them buys nothing measurable. A real seam that is not worth cutting.

The seam that IS parallel to the change axis is inside the LIST handler, not between the routes. GET /meta/:type is a pipeline: fetch, then 10 independent type-keyed post-processing stages, then translate and send. Each stage is visible = f(visible) gated on metaTypeSingular(req.params.type). Measured inside that one handler:

• 10 separate RestServer.metaTypeSingular(req.params.type) === '…' re-derivations;
• 16 repetitions of the same "bare array or { items: [] } envelope" unwrap-and-rewrap idiom.

Single-route commits landed in exactly these stages (#7566 the ?id= stage, #7912 the app-nav stage, ADR-0057 D10 the dashboard stage). That is a seam whose cuts follow the change history rather than crossing it.

⚠️ Worth noting without inflating it: the ITEM handler next door normalizes the type once at the top into const metaType, with a 25-line comment saying #3984 ruled that shape and #6241 is why it is written into the code rather than trusted to memory. The LIST handler does not follow that ruling. It is not the #6241 defect — every LIST gate does call metaTypeSingular, so no gate compares the raw param — but it is the one shape divergence inside the method with a named ruling on the other side of it.

---

6. Extraction cost, measured — three costs the earlier analyses did not have

(a) 24 this.* members plus 3 statics are reached from inside the method. 14 of them are used by nothing else in the class (resolveObjectMasker, translateMetaItems, translateMetaEnvelope, serveMetaItemLayered, resolveAudienceCaller, fetchAudienceBooks, resolveNavServability, filterAppForUser, filterDashboardForUser, resolveRegisteredServices, resolveMetaWriteActor, resolveMetadataService, translateMetaTypesResponse, anyPermissionSetAudience) — a genuine /meta helper cluster that would travel with an extraction. The other 13 are shared infrastructure: routeManager (21 callers), resolveExecCtx (17), resolveProtocol (10), config (10), extractLocale (5), resolveI18nService (5), objectQLProvider (3), metaTypeSingular (3), and five with one other caller each. Roughly 9 injected dependencies for any extracted module.

(b) The precedent extraction in this package does not transfer. packages/rest/src/ already contains extracted route modules — package-routes.ts (703 lines) and external-datasource-routes.ts (218). Both take the raw server: IHttpServer and mount directly, returning DirectMountedRoute[], which is why direct-mount.ts and direct-mount-introspection.test.ts exist at all: bypassing the registrar cost them discovery and OpenAPI visibility, which had to be rebuilt.

⚠️ The /meta family cannot take that shape. Its anonymous-deny gate is implemented as a wrapper around the registration call: registerMetadataEndpoints swaps this.routeManager for a guarded proxy for the duration of the inner call, deliberately, so that "every meta route, present and future, inherits it" rather than each handler remembering. Direct-mounting bypasses the guard entirely. An extracted /meta module must receive the (guarded) registrar as a parameter — a different contract from the one both existing extractions use.

(c) The extraction would split a live ratchet ledger. scripts/check-route-envelope.mjs holds packages/rest/src/rest-server.ts as a dialectOnly entry pinning stringError: 44 and siblingCode: 69, ticking down only, with the named end state "#7035 option 1 — convert the file onto the shared sendOk/sendError". Its discovery glob collects *-routes.ts, and the gate's own rule is that "a module discovered by the scan but absent from the table is an ERROR, not a default". So an extracted meta-routes.ts is discovered and must be classified: either { responses: 0, ok: 0, err: 0 } — which is what both existing extractions declare, i.e. every response site converted onto the shared pair — or its own hand-apportioned ratchet. The ledger's history (#7981, #8073, #8111) shows apportionment being done with 1:1 line-mapping proofs, by hand, per commit.

That makes extraction and the #7035 conversion the same card, not two. Which is a considerably larger card than "move 21 routes into a file".

⭐ And it inverts one half of option B's accepted price. B knowingly accepted that file-path scoping makes the domain delineation invisible to merge conflicts, affected-subset CI and lane serialisation. For this gate, file-path scoping is what makes the ratchet cheap and legible: one entry, two numbers, monotone. Splitting the file splits the ledger.

---

7. Recommendation — do not split. Two cheap things instead.

Do not split it, and do not open a follow-up split card. The three reasons, in order of weight:

1. The premise it would be justified by is false. The method has 21 internal boundaries and a 61-line median unit. It is populous, not undelineated — and it is better delineated per unit than at least two of the 17 methods the card holds up as adequate.
2. The visible seams are perpendicular to the change axis. Two of the eight cross-cutting concerns touch all six route groups; the highest-severity commits in the last 8 days touched 3, 5 and 12 route blocks at once. Cutting along route groups converts those sweeps into cross-file sweeps, and this method's history is already a list of sweeps that missed siblings with co-location.
3. The cost is not "move the code". It is 9 injected dependencies, a registrar contract neither existing extraction in this package uses, and a ratchet-ledger split that couples it to the finding: rest-server.ts 里三个相邻 /meta handler 的错误信封是三种不同形状,其中两种不符合 ADR-0112 #7035 envelope conversion.

What I would do instead — both are within-file, no module extraction, no ratchet split, no guard rework:

• ① Give the method a header. It is the only registerXxxEndpoints in the class without one. ~30 lines: the six groups above, the registration-order constraint and the test that pins it, and the note that the two PUTs are twins. This is the entire "an agent must hold the whole thing" cost, addressed at its actual cause — there is no map — for the price of a docblock. Highest value per line of anything in this analysis.
• ② Extract the LIST handler's 10 type-keyed stages into named functions, and give them one shared mapMetaList(visible, fn) for the array-or-envelope duality that is currently written out 16 times in that one handler. This is the one seam that runs with the change history rather than across it, it takes the largest single unit from 237 code lines to something an agent can hold, and it is confined to one route block so it collides with nothing.

⛔ I have deliberately not filed either as an issue. Both are proposals about this card's subject, not out-of-scope findings tripped over, and the card's posture is read-and-propose. Filing them would pre-empt the triage decision. They are the PM's to file if wanted.

And a non-finding worth recording so nobody re-finds it: five 501 refusals in this method still speak the retired dialects — …/layers carries code as a sibling of error, and …/history, …/publish, …/rollback, …/diff are bare-string error with no code at all. That looks exactly like an unfiled defect. It is not: check-route-envelope.mjs already pins them, its comment names them ("the ~44 bodies #7035 / PR #7293 deliberately left when it converged three /meta 501 sites"), and the remedy is the ratchet's declared end state. ⛔ Do not file it. Note, though, that …/publish and …/rollback are writes, so meta-501-envelope.test.ts's docblock claim to cover "every /meta write refusal" is narrower than it reads — worth one sentence in that docblock if anyone is there anyway, not a card.

---

8. Where this analysis is weakest

• The history window is 8 days. The clone is shallow and --deepen=600 reached 2026-08-07. Every churn number above is a floor. The 17-commit and 65-commit counts would only grow with more history, and the single-vs-multi-block ratio could shift either way. ⚠️ This is now the third time this card's lineage has been bitten by the shallow clone; the deepen has to be an explicit step, not an assumption.
• I did not read the other 17 methods. I measured their route granularity through the AST and read their signatures. The claim "at least two of the 17 are less delineated per unit" rests on structure, not on reading their bodies.
• I did not price proposal ② against the tests. 26 meta-*.test.ts files in packages/rest/src drive these routes, and 152 test files repo-wide reference /meta/ paths. The stage extraction is behaviour-preserving by construction, but "how many tests reach inside the LIST handler" is unmeasured.
• ⚠️ The strongest counter-argument to my own recommendation. If the ADR-0076 D11 direction is ever reopened, the /meta family is where it would have to start regardless — and doing the finding: rest-server.ts 里三个相邻 /meta handler 的错误信封是三种不同形状,其中两种不符合 ADR-0112 #7035 envelope conversion first is the step that makes an extraction cheap later. So "do not split" is the right call for this card, on this evidence, and it is not a claim that the file's shape is permanently right. It is a claim that splitting this method, on route boundaries, now would cut across the grain, and that the two cheap interventions buy most of the comprehension benefit for a fraction of the cost.

⛔ Nothing here reopens the 2026-08-15 ruling on #5949. Option B stays; no line-count argument is made; no user impact is claimed, because there is none — the whole of this is error-resistance for the agents who work in this file.

Gates: not applicable — no diff was produced and no file in the repository was written.

---

Generated by Claude Code

---

Generated by Claude Code

[qq9340100]

{
 "issue": 8851,
 "status": "done",
 "branch": "claude/issue-8851-characterize-metadata-endpoints",
 "pr": null,
 "premise_still_valid": true,
 "summary": "Deliverable is the analysis comment 5302622601 on this card; pr: null is the EXPECTED and COMPLETE delivery per the card, not a stall or a fallback. No diff, no branch pushed, rest-server.ts untouched. The two stated premises re-measured by symbol at origin/main cc5c07b80 and both hold (method 4686-7009 = 2,324 lines; the other 17 register methods 32-938). The PM's READING on top of them does not: the method has 20 top-level statements, 21 registration call sites (23 mounted paths), median route block 61 lines / ~50 code lines, so 'one method, no internal boundary' is false — it is populous, not undelineated, and by delineation-per-unit it beats registerAnalyticsEndpoints (one 215-line handler) and registerFormEndpoints (3 handlers, median 166). Recommendation: DO NOT SPLIT, and do not open a follow-up split card. Two cheap within-file alternatives proposed instead (a JSDoc header — it is the only registerXxxEndpoints in the class without one; and extracting the LIST handler's 10 type-keyed stages plus the array-or-envelope idiom repeated 16 times in that one handler). Not filed as issues — they are proposals about this card's own subject, so PM triage owns filing."
 ,
 "tests": "N/A by design — this card ships no diff, so no gate family applies and none was run; `node scripts/pm/dispatch-gates.mjs` was not invoked because there are no changed paths to derive from. Verification was measurement, all at origin/main @ cc5c07b80 in a pinned worktree, TypeScript-AST based (symbol-located, never line-number based, since #8850 was editing the file concurrently). (1) AST member scan: registerMetadataEndpointsInner 4686-7009 (2,324 lines), 18 registerXxxEndpoints methods 32-938 apart from it. (2) AST route map inside the method: 20 top-level statements, 21 `this.routeManager.register` call sites, 23 mounted paths (two sites are for..of loops), largest handlers 521 and 425 total lines. (3) Line-classified density: method 1,289 code / 968 comment / 67 blank; whole file 6,008 code — reproduces the 6,008 figure recorded on #5949 comment 5301568348, so the classifier agrees with the prior measurement. (4) Coupling scan: 24 this.* members + 3 statics reached from the method; 14 used by NOTHING else in the class; heaviest shared are routeManager 21 callers, resolveExecCtx 17, resolveProtocol 10, config 10. (5) Churn: `git rev-parse --is-shallow-repository` = true at 140 commits (the trap this card recorded twice before — now three-for-three), repaired with `git fetch --deepen=600` to 1,273 commits reaching 2026-08-07; then 65 commits touch rest-server.ts, and `git log -L 4686,7009:...` returns 17 touching the method. (6) Per-commit hunk-to-statement mapping (file re-parsed AT each commit, method re-located by symbol): 9 single-route-block commits, 7 multi-block, peak 12/18 blocks (#6877). (7) Growth series across those 17 revs: 1,371 -> 2,324 total but 951 -> 1,289 code and 17 -> 21 routes, i.e. unit count rose while growth was 63% comment. (8) Read in full: all 21 route blocks, the registerMetadataEndpoints guard wrapper, meta-route-registration-order.test.ts, meta-501-envelope.test.ts, package-routes.ts entry shape, and scripts/check-route-envelope.mjs's rest-server.ts ratchet entry (stringError 44 / siblingCode 69)."
 ,
 "open_questions": [],
 "out_of_scope_findings": []
}

Nothing filed, and one near-miss worth stating explicitly. Five 501 refusals inside this method still speak the retired ADR-0112 dialects (…/layers has code as a sibling of error; …/history, …/publish, …/rollback, …/diff are bare-string error with no code). That reads exactly like an unfiled concrete defect — I searched before filing and it is already tracked: scripts/check-route-envelope.mjs pins packages/rest/src/rest-server.ts at stringError: 44 / siblingCode: 69 on a down-only ratchet whose comment names these very sites ("the ~44 bodies #7035 / PR #7293 deliberately left when it converged three /meta 501 sites") and whose declared end state is the remedy. Filing it would have duplicated a live ratchet.

---

Generated by Claude Code

---

Generated by Claude Code

[qq9340100]

ACCEPT — analysis comment 5302622601 is the complete delivery, and pr: null is the correct outcome. Closing this card as done. The recommendation — do not split, and do not open a follow-up split card — is adopted.

⚠️ The premise this card was filed on is FALSE, and it was mine

I wrote, on this card: "2,328 lines is 20% of the file in one method, with no internal delineation", and framed the whole justification as "one method, no internal boundary" — explicitly distinguishing it from what option B closed on exactly that ground.

Measured, that is wrong. The method has 20 top-level statements, 21 registration call sites, 23 mounted paths, median route block 61 lines. It is populous, not undelineated — and by delineation-per-unit it is better structured than two of its siblings: registerAnalyticsEndpoints is one 215-line handler, registerFormEndpoints has 3 handlers at median 166. The card's premise inverted the comparison it was making.

I asked for this to be falsified and it was, on the first read. That is the fifth premise of mine to fall tonight, and the first where the false premise was the reason the card existed at all. Worth stating plainly: had this been dispatched as a refactor instead of a characterisation, it would have split a method that did not need splitting, on my say-so.

⭐ The growth series is the sharpest single finding, because it retires the intuition underneath the card: across the 17 commits that touched this method, it went 1,371 → 2,324 total lines but only 951 → 1,289 code lines, while route count rose 17 → 21. Growth was 63% comment, and the unit count rose with it. The method did not sprawl — it got documented and gained routes.

What makes the recommendation trustworthy rather than merely convenient

It is not "I looked and it seemed fine". The analysis is AST-based and symbol-located throughout (necessary, since #8850 was editing the file concurrently), and it does three things I would have accepted weaker versions of:

• Cross-checks its own instrument. The line classifier reproduces the 6,008 code-line figure recorded independently on [finding] ADR-0076 D11 的第二半从未落地:packages/rest/src/rest-server.ts 已 8593 行(ADR 记录约 5.1k),且无 issue 承接 #5949, so the measurement agrees with a prior one taken by different means.
• Maps churn to structure, not just to the file. 65 commits touch rest-server.ts; git log -L narrows to 17 touching this method; each was then re-parsed at that commit with the method re-located by symbol, giving 9 single-route-block commits vs 7 multi-block, peak 12 of 18. That is the measurement that answers "would a split reduce collisions" — and it says most edits are already confined to one route block.
• Measures coupling in the direction that matters: 24 this.* members reached, 14 of them used by nothing else in the class — i.e. much of what looks like shared state is already local in practice.

The shallow-clone trap fired again and was caught: is-shallow-repository true at 140 commits, repaired with --deepen=600 before any git log time-window reading. That is three-for-three tonight on a trap that silently truncates history.

The two alternatives are adopted as a filing, not as scope creep

Both stay within the file, so neither reopens what option B closed:

1. This is the only registerXxxEndpoints in the class without a JSDoc header.
2. Inside the LIST handler: 10 type-keyed stages, and an array-or-envelope idiom repeated 16 times in that one handler.

The dev correctly declined to file them (they are proposals about this card's own subject, so filing is the PM's). Filed as a finding for triage grading rather than queued by me — ⛔ and explicitly not as a split, which is the thing this analysis just recommended against.

#5949's decision item ⑦ ("the disposition of the 2,328-line method") is now answered by measurement: leave it. I am withdrawing it from the maintainer decision list rather than carrying it further — there is no longer a question there.

---

Generated by Claude Code