diff --git a/CHANGELOG.md b/CHANGELOG.md index fa51af4b..4a3c40a3 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1185,6 +1185,52 @@ Reader and unwired writer on one panel — still the reason not to separate them Pin 731 → 727. **80 above the banner, still no map.** +Thirty-ninth follow-on on the same version: **SCALE-SEAM (100)** — *the element-connection pair, and +a destination named at the strength the evidence supports*. + +Two methods out of `client.ts` (`648 → 642`) into the existing `apps/web/src/api/model.ts`: +`elementConnections` and `connectElements`. No new mixin. **What they answer: what is physically +joined to what, and record a joint.** + +### The backend names its own writer + +The `/element-connections` route docstring reads: *"Author edges with the `connect_elements` recipe +(`POST /edit` with `{guid_a, guid_b}`)."* Reader and writer, one relationship type +(`IfcRelConnectsElements`), both marked B5. That is the (96) shape and it is what carries the pair. + +### The destination argument is weaker, and is labelled as such + +`model.ts` owns `modelGraphStats` — whose `by_rel` counts the IFC relationship graph **by relation**, +and `IfcRelConnectsElements` is one of those relations — plus `graphNeighbors`, which walks it. So +this pair is one relation of a graph the file already reads, plus its authoring verb. + +**That is a specialisation, not an identity.** `modelGraphStats`/`graphNeighbors` are generic +traversal over every `IfcRel*`; these two are one relation with a verb attached. Recorded as the best +available home rather than a derived one — *the pairing is evidenced, the placement is a judgement, +and collapsing the two would be the overstatement this sequence keeps catching.* + +### Two candidates rejected on checkable grounds + +**`connections.ts` is the trap.** It is *data-source* connections — SQL, ACC, Procore — and shares +nothing with this but the English word. (97) found two version stacks behind one word; this is the +same collision in a **destination** rather than a source, and it is the file a name-based search +would have landed on first. + +**`elements.ts`** holds element *attributes* and views — properties, 5D, colouring, QA, costs. A +relationship between two elements is not an attribute of either. + +`addBasePlate` and `addShearTab` did **not** come despite sharing `services/data/src/aec_data/connections.py` +with these: a backend module is a HOW, the grouping (89) had to reject, and those two author +*physical* assemblies (plates, bolts) rather than `IfcRelConnectsElements` edges. + +### Found while deriving + +`add_connection_assembly` (B5, `IfcRelConnectsWithRealizingElements`) has **no client method +anywhere** in `apps/web/src` — a backend recipe with no web exposure, the same class (93) recorded +for three MEP recipes. Noted, not fixed. + +`client.ts` is 60 methods above the STAYING banner and 4 below. + Thirty-eighth follow-on on the same version: **SCALE-SEAM (99)** — *the content half of a shelf the destination's own first line already claimed*. diff --git a/apps/web/src/api/client.ts b/apps/web/src/api/client.ts index c8533528..d4b11b81 100644 --- a/apps/web/src/api/client.ts +++ b/apps/web/src/api/client.ts @@ -178,16 +178,6 @@ export class ApiClient extends withDetailing(withAnnotate(withCreDeal(withClient ahead: number; on_track: number; behind: number; worst: string | null; note: string; }>(`/projects/${pid}/progress/actuals`, { method: "POST", body: JSON.stringify({ actuals, planned }) }); } - /** B5: record a physical connection between two elements (IfcRelConnectsElements, LOD-350 coordination). */ - connectElements(pid: string, guidA: string, guidB: string, description?: string, publish = true) { - return this.editIfc(pid, "connect_elements", { guid_a: guidA, guid_b: guidB, ...(description ? { description } : {}) }, publish); - } - /** B5: the element-to-element connection graph (IfcRelConnectsElements) — pairs + per-element degree. */ - elementConnections(pid: string) { - return this.json<{ count: number; elements_connected: number; max_degree: number; - connections: { a: string; a_class: string; b: string; b_class: string; description: string | null }[] }>( - `/projects/${pid}/element-connections`); - } /** W11 F0: establish the view-keyed representation contexts (Model+Plan; Body/Axis/Box/Annotation/ * FootPrint) the drawing pipeline needs. Idempotent. */ ensureContexts(pid: string, publish = false) { @@ -545,7 +535,7 @@ export class ApiClient extends withDetailing(withAnnotate(withCreDeal(withClient // through (87) worked through, and they are recorded here as DECIDED rather than pending. // // **THIS IS NOT THE END OF SCALE-SEAM, and a previous version of this banner implied it was.** - // 62 methods still sit ABOVE this line — `disciplineTree`, `classify`, `specManual`, `editUndo`, + // 60 methods still sit ABOVE this line — `disciplineTree`, `classify`, `specManual`, `editUndo`, // `energyModel`, `propmapPlan`, `camReconciliation` and the rest. They were never inside the // CX-1 banner, so no map has ever covered them. The UNFILED map described the TAIL of this file, // not the file. @@ -620,6 +610,10 @@ export class ApiClient extends withDetailing(withAnnotate(withCreDeal(withClient // `authoring.ts`, leaving 62. Role-for-role parallel with the family shelf already there; that // file's first line had claimed "family/content shelf" while holding no content method. // + // (100) took the ELEMENT-CONNECTION pair — `elementConnections`/`connectElements` — to + // `model.ts`, leaving 60. The route docstring names its own writer. `connections.ts` is the trap: + // that file is DATA-SOURCE connections and shares only the word. Reasoning in `model.ts`. + // // the four that stay enumOptions, searchAll, attachmentUrl, templates enumOptions(pid: string) { return this.json>>(`/projects/${pid}/enum-options`); diff --git a/apps/web/src/api/model.ts b/apps/web/src/api/model.ts index 5ded9222..18ff25aa 100644 --- a/apps/web/src/api/model.ts +++ b/apps/web/src/api/model.ts @@ -138,6 +138,38 @@ * * SCALE-SEAM ⓭ adds E57 scan ingest — *can we bring this scan in?* Status plus convert. * Admin audit/error stayed. + + * **SCALE-SEAM (100) adds the ELEMENT-CONNECTION pair** — `elementConnections` (the + * `IfcRelConnectsElements` graph: pairs, per-element degree) and `connectElements` (the verb that + * adds an edge). *What is physically joined to what, and record a joint.* + * + * **The pair is bound by the backend naming its own writer**, the (96) shape: the + * `/element-connections` route docstring reads *"Author edges with the `connect_elements` recipe + * (`POST /edit` with `{guid_a, guid_b}`)."* Reader and writer, one relationship type, both marked + * B5. That link is strong and is what carries the pair. + * + * **The DESTINATION argument is weaker than the pairing argument, and is stated at that strength.** + * This file owns `modelGraphStats`, whose `by_rel` counts the IFC relationship graph *by relation* — + * and `IfcRelConnectsElements` is one of those relations — plus `graphNeighbors`, which walks it. + * So this pair is one relation of the graph this file already reads, plus its authoring verb. *That + * is a SPECIALISATION, not an identity: `modelGraphStats`/`graphNeighbors` are generic traversal + * over every `IfcRel*`, while these two are one relation with a verb attached.* Recorded as the + * best available home rather than a derived one. + * + * **Two candidates were rejected on checkable grounds.** `connections.ts` is the trap: it is + * DATA-SOURCE connections — SQL, ACC, Procore — and shares nothing with this but the English word. + * *(97) found two stacks behind one word; this is the same collision in a destination rather than a + * source.* And `elements.ts` holds element ATTRIBUTES and views (properties, 5D, colouring, QA, + * costs); a relationship between two elements is not an attribute of either. + * + * *`addBasePlate` and `addShearTab` did NOT come, though they share `connections.py` with these.* + * A backend module is a HOW — the grouping (89) had to reject — and those two are W11 B6 authoring + * PHYSICAL assemblies (plates, bolts), not `IfcRelConnectsElements` edges. Different output, + * different question, same file on the server. + * + * *Recorded while deriving this: `add_connection_assembly` (B5, + * `IfcRelConnectsWithRealizingElements`) has NO client method anywhere in `apps/web/src` — a + * backend recipe with no web exposure, the same class (93) recorded for three MEP recipes.* * * SCALE-SEAM ⓳ adds publish history — *what changed between publishes?* Version list, * element diff, cost delta, and the submit/approve/reject review gate. They were **not** @@ -871,5 +903,15 @@ export function withModel>(Base: TBase) { setManufacturerInfo(pid: string, guids: string[], opts: { manufacturer?: string; model_label?: string; production_year?: string; serial?: string; barcode?: string } = {}, publish = true) { return this.editIfc(pid, "set_manufacturer_info", { guids, ...opts }, publish); } + /** B5: record a physical connection between two elements (IfcRelConnectsElements, LOD-350 coordination). */ + connectElements(pid: string, guidA: string, guidB: string, description?: string, publish = true) { + return this.editIfc(pid, "connect_elements", { guid_a: guidA, guid_b: guidB, ...(description ? { description } : {}) }, publish); + } + /** B5: the element-to-element connection graph (IfcRelConnectsElements) — pairs + per-element degree. */ + elementConnections(pid: string) { + return this.json<{ count: number; elements_connected: number; max_degree: number; + connections: { a: string; a_class: string; b: string; b_class: string; description: string | null }[] }>( + `/projects/${pid}/element-connections`); + } }; } diff --git a/apps/web/src/api/surface.test.ts b/apps/web/src/api/surface.test.ts index e1584a59..b206257d 100644 --- a/apps/web/src/api/surface.test.ts +++ b/apps/web/src/api/surface.test.ts @@ -256,6 +256,8 @@ describe("the API client's public surface", () => { "elementDetailing", "classify", "applyDetailingRules", "validateDetailing", "attachDocument", // (99) the content shelf -> authoring.ts, joining the family triple it parallels. "contentCatalog", "placeContent", "importContent", + // (100) the IfcRelConnectsElements reader + its writer -> model.ts. + "elementConnections", "connectElements", ]) { expect(surface.has(k), `${k}() vanished — a call site is now broken`).toBe(true); } diff --git a/docs/roadmap.md b/docs/roadmap.md index 61972eb3..7a601efe 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -3135,7 +3135,7 @@ verbs, with a command bar as the escape hatch to everything); and **role-shaped banner is renamed UNFILED → STAYING and now says exactly that; the next slices work the 126, and there is no map for them yet. - **(88)–(99) took sixty-four of those 126 — 62 remain, and there is STILL no map.** A new + **(88)–(100) took sixty-six of those 126 — 60 remain, and there is STILL no map.** A new `apps/web/src/api/operations.ts` holds the operate-phase cluster: *the building is built and running.* Maintenance (`cmmsGeneratePm`, `cmmsKpis`), consumption (`energyActual`, `energyBenchmarkStatus`, `esgSummary`), condition and capital (`fcaIndex`, `fcaPortfolio`, @@ -3390,6 +3390,30 @@ verbs, with a command bar as the escape hatch to everything); and **role-shaped true, and this one had been wrong for as long as it had existed.* It is the smallest possible instance of the drift these instructions keep warning about. + **(100) took the ELEMENT-CONNECTION pair to `apps/web/src/api/model.ts`** — + `elementConnections` (the `IfcRelConnectsElements` graph) and `connectElements` (the verb that adds + an edge). **The pair is bound by the backend naming its own writer**, the (96) shape: the + `/element-connections` route docstring says *"Author edges with the `connect_elements` recipe."* + + **The DESTINATION argument is weaker than the pairing argument, and is recorded at that strength.** + `model.ts` owns `modelGraphStats`, which counts the IFC relationship graph BY RELATION — + `IfcRelConnectsElements` being one — and `graphNeighbors`, which walks it. So this is one relation + of a graph the file already reads, plus its verb: **a specialisation, not an identity.** *The + pairing is evidenced; the placement is a judgement. Collapsing the two into one confident sentence + is the overstatement this sequence keeps catching, so they are stated separately.* + + *Two candidates rejected on checkable grounds.* **`connections.ts` is the trap** — it is + DATA-SOURCE connections (SQL, ACC, Procore) and shares only the English word; **(97) found two + version stacks behind one word, and this is the same collision in a destination rather than a + source**, on the very file a name-based search lands on first. And `elements.ts` holds element + ATTRIBUTES and views, whereas a relationship between two elements is not an attribute of either. + `addBasePlate`/`addShearTab` also did not come despite sharing `connections.py`: a backend module is + a HOW, and those author PHYSICAL assemblies rather than relationship edges. + + *Found while deriving, recorded not fixed:* `add_connection_assembly` (B5, + `IfcRelConnectsWithRealizingElements`) has **no client method anywhere** in `apps/web/src` — a + backend recipe with no web exposure, the class (93) recorded for three MEP recipes. + **(93) finished SCALE-SEAM ⑲.** Two methods to the existing `apps/web/src/api/mep.ts` — `connectMep` and `addMepFitting` — which that file has claimed by name since ⑲ under the note *"call `editIfc` (`/edit`) and stay"*. **That note recorded the symptom without diagnosing the diff --git a/services/api/test_file_sizes.py b/services/api/test_file_sizes.py index ff9ecb9b..fa956542 100644 --- a/services/api/test_file_sizes.py +++ b/services/api/test_file_sizes.py @@ -82,7 +82,7 @@ def check(label, ok, detail=""): #: straight back while the work still read as done. **An extraction without a ratchet is a #: rearrangement.** Set at the post-extraction count so it can only come down from here. "apps/web/src/portal/portal.ts": 1_238, # executive portfolio -> panels/portfolio.ts (1_353 -> 1_238), REL-4. Chosen by grepping every candidate's this.* refs FIRST: the two mid-sized methods call five and two SIBLING renders, so only this one is a leaf. # the dead module catalog DELETED (1,400 -> 1,352); unreachable since 2026-06-24, and its star was the only caller of toggleFav in the app # REL-4 renderDeveloperHome -> homes/developerHome.ts (1,473 -> 1,400) - "apps/web/src/api/client.ts": 648, # SCALE-SEAM (99): THE CONTENT SHELF — what pre-made content can I place, and place it? (665 -> 648). contentCatalog + placeContent + importContent to authoring.ts. WITNESS IS A ROLE-FOR-ROLE PARALLEL with the family shelf already there, read off the signatures not the shared word "shelf": familyCatalog/contentCatalog (catalog reader, both {count, ...Record<..>}), placeFamily/placeContent (placer), importFamilies/importContent (async multipart importer). Three roles, three methods each. A parallel between two method TRIPLES is structural; "both are shelves" would be a word, the grouping (88) and (89) rejected. SMALL FINDING: authoring.ts line 1 had said "the family/content shelf" while the file held ZERO content methods — a docstring describing an intended scope as fact. Corroboration that was FALSE, not evidence. # SCALE-SEAM (98): DETAILING CARRIERS — what informational carriers are attached to this element, write them, and which are missing? (687 -> 665). New detailing.ts: elementDetailing + classify + applyDetailingRules + validateDetailing + attachDocument. WITNESS IS A 1:1 AND TOTAL FIELD-TO-WRITER MAP, the (96) shape: element_detailing walks HasAssociations and branches on exactly two relationship types, and detailing.py holds exactly two writers — classifications[] <- classify (IfcRelAssociatesClassification), documents[] <- attachDocument (IfcRelAssociatesDocument). The other two are those same writes automated (rule engine) and audited (gap report). NOT CLAIMED: attachOmDocument, moved to model.ts in (96), wraps the SAME detailing.attach_document and also lands in documents[], so "all the writers of this reader" is false; the map is total over detailing.py, not over the codebase. ADJACENCY IS NOT EVIDENCE: these five were contiguous, so unlike (95) a positional split would also have found them. # SCALE-SEAM (97): THE UNDO STACK — what has been done to this model, and can I take it back? (698 -> 687). editHistory/editUndo/editRedo to authoring.ts, because editIfc — already there — is the PUSH they pop: authoring.py records the pre-edit version on every /edit call "so this edit can be undone", _restore_version pops it, edit_history.state() reads its depths. TYPE-LEVEL: both writers return {restored, state:{can_undo,can_redo}} and state IS the reader's type minus depths. HYPOTHESIS TESTED AND WITHDRAWN: "undo restores the prior model version" makes model.ts look right, but modelVersions reads /projects/{pid}/versions out of bim.py while undo pops a DIFFERENT stack in the edit_history sidecar. Two stacks, one word. # SCALE-SEAM (96): AS-BUILT/TURNOVER — its aggregate READER plus the two writers still feeding it (711 -> 698). lod500 + setManufacturerInfo + attachOmDocument to model.ts, rejoining verifyAsbuilt/recordAsbuiltDimension from (94). TWO BOUNDING WITNESSES: openAsBuiltPanel calls exactly five API methods (read off the brace closure, not grepped), two already moved; and asbuilt_summary's response type names its writer set field by field. test_lod500.py CORROBORATES but does NOT bound — it reaches three recipes and omits record_asbuilt_dimension, a known member, so it cannot establish a boundary. NOT CLAIMED: attachDocument (staying) takes a purpose param and can also produce with_om_docs, so "every writer of with_om_docs moves" is false. # SCALE-SEAM (95): ELEMENT STATE — what state are the model's elements in, and set it? (727 -> 711). Two read/write pairs to model.ts: lodSummary/setLod (element maturity 100-500) and phasing/setPhase (new/existing/demolish/temporary). IDENTICAL RETURN SHAPE — both {total, ed, prop, counts: Record<...>}; both writers (pid, guids, , publish) -> editIfc; both readers consumed by viewer/tools/modelStatePanels.ts; both writers UNWIRED and ADJACENT on clientCallers.test.ts's UNCALLED allowlist. AND lodSummary WAS A SIBLING SEPARATED FROM ITS OWN FAMILY: model.ts already held /model/lod/census, /lod/handover-readiness and /lod/assessment while the BASE distribution /projects/{pid}/lod stayed in client.ts. THE MATRIX DISAGREES AND IT LOSES, which is worth stating rather than eliding: authoring_matrix.py files set_lod under `data` and set_phase under `lifecycle` because it categorises by the IFC OUTPUT each recipe writes — an LOD stage tag against Massing_Phasing.Status. Different psets, same question. THAT IS (89)'S "STORAGE IS A HOW" TRAP: "they write different property sets" has the same shape as "they are all module records", and neither is a question. THIS ALSO MEETS (94)'S OBJECTION RATHER THAN OVERRIDING IT: that slice declined setPhase because taking the writer would have stranded phasing() in client.ts, the reader/writer split (87) had to undo. Both halves move together here, so nothing is separated. NOT CONTIGUOUS — the pairs sat at 271-279 and 293-301 with ensureContexts and queryElements between; (88) recorded that as the strongest case for grouping by what methods ANSWER, since no prefix or positional split would find them together. 76 above the banner now, still no map. # SCALE-SEAM (94): the as-built pair ㊻ COULD NOT SEE (731 -> 727). verifyAsbuilt (stamps Massing_AsBuilt, the LOD-500 reliability layer) and recordAsbuiltDimension (a field-verified dimension + variance vs design) to model.ts, which since ㊻ has held "field-install verification — is this element installed as designed?" with verificationCoverage, setVerification and verificationDeviations. Both answer exactly that question and NEITHER IS NAMED IN ㊻'S HEADER. WHY ㊻ MISSED THEM: it split on the /verification/* ROUTE PREFIX, and these two go through editIfc so they carry no route to be found by. A ROUTE-PREFIX SPLIT CANNOT SEE A RECIPE-BASED SIBLING OF THE SAME QUESTION. They were also unmovable at the time — editIfc is declared on the Authoring mixin rather than HttpCore, so a mixin typed Ctor does not compile. THIRD slice found to have left work behind for that reason, after ⑲'s MEP pair (taken by (93)). THE MATRIX ARGUED FOR A THIRD METHOD AND IT WAS DECLINED: authoring_matrix.py's `lifecycle` category is exactly these two plus set_phase — a COMPLETE category, the very signal that decided (92)'s annotate slice. setPhase stays because it answers a different question (tag a construction phase: new/existing/demolish/temporary — element state in the build sequence, not install-versus-design) AND because its read half phasing() is still in client.ts; taking a writer and leaving its reader is the split (87) had to undo. A COMPLETE CATEGORY IS ONE VOTE, NOT A VERDICT — and "lifecycle" is a word (88) already caught misleading once, in a different way. withModel now declares NeedsEditIfc and must compose outside withAuthoring; probe-checked with an isolated file applying withModel to bare HttpCore, which fails TS2345 naming NeedsEditIfc. THE FIRST ATTEMPT AT THAT CHECK WAS WORTHLESS AND READING IT IS THE ONLY REASON I KNOW: it rebalanced parens wrongly and went red with TS1005 syntax errors, so it proved nothing about composition order while looking exactly like a pass of the mutation test. THE BANNER NOTE IN client.ts WAS CONDENSED, and that is the ratchet working: the first draft added 9 lines of prose while the extraction removed 8, netting +1 — an extraction slice that grows the file has failed its purpose. The reasoning lives once, in model.ts's header, rather than twice. REVIEW OF #411 FOUND AN OVERSTATEMENT I HAD ASKED IT TO LOOK FOR: the PR description scoped the claim as "two known missed members, not necessarily all members" while model.ts said "finishes that question" and surface.test.ts said "completing its verification question". HEDGING IN THE REVIEW REQUEST WHILE THE ARTIFACT OVERSTATES IS NOT SCOPING — it puts the caveat where a reviewer sees it and the overstatement where every later reader will, which is worse than a plain overstatement because it looks like discipline. Fourth instance of one defect across four slices, and the first where the correct wording already existed and simply did not reach the code. Both corrected. AND THE COMPOSITION-ORDER CONSTRAINT IS NOW A TEST RATHER THAN A CLAIM: apps/web/src/api/compositionOrder.test.ts asserts with @ts-expect-error that withAnnotate, withMep and withModel all reject a bare HttpCore base. I had reported it as mutation-checked, but the check was a scratch file I deleted, so nobody could verify it — A VERIFICATION THAT LEAVES NO ARTIFACT IS A CLAIM, NOT A CHECK. Mutation-checked in turn: relaxing withMep to Ctor fails TS2578 'Unused @ts-expect-error directive' naming the line. 80 above the banner now, still no map. # SCALE-SEAM (93): the two MEP recipes ⑲ HAD TO leave behind (733 -> 731). connectMep + addMepFitting to mep.ts, whose own header since ⑲ said they "call editIfc (/edit) and stay" — A NOTE THAT RECORDED THE SYMPTOM WITHOUT DIAGNOSING THE CAUSE. They could not come because editIfc is declared on the Authoring mixin rather than on HttpCore, so a mixin typed Ctor cannot see it and the extraction does not compile. (92) found that; (93) applies it. A METHOD LEFT BEHIND FOR A REASON NOBODY WROTE DOWN STAYS BEHIND INDEFINITELY — ⑲'s note read as a placement decision and was a compiler error. NeedsEditIfc moved from annotate.ts into types.ts so both mixins share ONE definition: two hand-copied signatures are exactly the drift the #409 review had to check by hand, since a copy subtly WIDER than the real editIfc typechecks at the mixin and still breaks at a call site. Mutation-checked: composing withMep inside withAuthoring fails with TS2345 naming NeedsEditIfc. EVIDENCE IS WEAKER THAN (92)'S AND IS STATED AS SUCH: this is NOT a complete authoring_matrix category (create-mep has 11 members, edit-mep 3, of which these are one each). The boundary is "MEP recipe exposed as a TYPED client method" — exactly these two. TWELVE MEP recipes remain in the matrix (11 create-mep + 3 edit-mep, less these two): nine are driven from viewer code through the generic recipe path in draftCatalog.ts and mepSection.ts, and THREE (add_sprinkler, auto_connect_mep, set_system_predefined) are referenced nowhere in apps/web/src at all — backend recipes with no web exposure, recorded rather than fixed. THIS SAID "the other nine" UNTIL REVIEW, AND IT IS THE THIRD CONSECUTIVE SLICE WITH ONE DEFECT IN A THIRD DISGUISE: nine was the number I had ENUMERATED (the viewer-driven ones), twelve is the number that REMAIN. (91) claimed no test_cre_* file reached outside its set while three reached out as fixtures; (92) claimed test_annotation.py exercised four recipes and no others while two more were tag-host fixtures; this enumerated a subset and wrote "the other". A reviewer found all three. THE FIX IS NOT TO BE MORE CAREFUL — IT IS TO DERIVE THE COMPLEMENT, set(all) - set(moved), and only then describe what is in it. test_mep_systems.py covers both AMONG other MEP recipes (corroborates family, does not bound the set) and test_guards.py is cross-cutting — said explicitly because the "no others" error was made in each of the two preceding slices. addMepFitting is callerless and stays on clientCallers.test.ts's allowlist: moving a method does not change its called-ness. 82 above the banner now, still no map. # SCALE-SEAM (92): ANNOTATION — put a note, a dimension, a cloud or a tag ON the model. Four methods to a new annotate.ts (746 -> 733): addAnnotation, addDimension, addRevisionCloud, addTag, all authoring real IfcAnnotation entities at world [E,N] through editIfc. THE SET IS BOUNDED BY TWO SOURCES SOMEBODY ELSE AUTHORED, not by the marker. (i) authoring_matrix.py, the curated recipe->category map behind the public authoring-coverage endpoint, has an `annotate` category holding EXACTLY these four of its 99 recipes across 15 categories — a complete category, nothing left behind and nothing pulled in. (ii) test_annotation.py exercises all four annotation recipes and no other recipe as its SUBJECT (it calls add_wall and add_column once each as fixtures, to give add_tag a host). That qualification was missing until review, and it is the SECOND CONSECUTIVE SLICE to make the error — (91) claimed no test_cre_* file reached outside its set while test_cre_tier3 reached three routes as fixtures. Both times the claim counted what a test TARGETS and ignored what it SETS UP. A "nothing else" claim about a test must say whether it means assertions or every call the file makes. THE `UX-2` MARKER DOES NOT BOUND THE SET, AND THAT DISTINCTION IS THE POINT: (91)'s `CRE-` occurred only in client.ts so it drew its own boundary, while UX-2 occurs 12 times across three files (client.ts, viewer/app.ts, viewer/tools/annotationSection.ts) and marks a FEATURE WORKSTREAM — it corroborates purpose and is silent on membership. Two markers, two strengths; treating every prefix as a set boundary is how a cluster gets the wrong members. Third corroboration: viewer/tools/annotationSection.ts, the UI these serve, makes exactly four api.* calls and they are these four. NOT markup.ts, the obvious guess: that is 2D SHEET markup (a pin at a sheet x/y carrying a note, stored as a markup record, promotable to RFI, route-group /drawings/markup), while these author MODEL CONTENT that travels with the IFC. A comment layer over a drawing and drawing content authored into the model are different questions sharing the word "annotation". NOT authoring.ts, which is the harder call because it DEFINES editIfc and holds seven recipes, and its header claims "the endpoints that WRITE to the model rather than read from it" — which would take all 24 recipes still in client.ts. A DESCRIPTION BROAD ENOUGH TO TAKE EVERYTHING IS NOT A SEAM: its demonstrated practice is narrower than its sentence, having declined detailing at 8, property-override layers at 33 ("those compose properties, they do not write recipes") and groups at 7. mep.ts settled the principle already — its methods "use editIfc (/edit) and stay" — and the matrix proves it, splitting those 24 recipes across NINE categories, so editIfc cannot be the seam. AND A TECHNICAL FINDING THAT PROBABLY EXPLAINS THE WHOLE BACKLOG: this is the first mixin to call editIfc WITHOUT DECLARING IT (authoring.ts calls it seven times but defines it, so it never needed a base type promising it — which is how eleven slices passed these recipes without hitting this). editIfc is declared on the Authoring mixin rather than on HttpCore, so a mixin typed Ctor cannot see it and the extraction does not compile — the same shape authoring.ts records blocking the SSE methods. annotate.ts declares the requirement in its type (NeedsEditIfc) and must be composed outside withAuthoring; mutation-checked by composing it inside, which fails with TS2345 naming editIfc rather than failing at runtime. Moving editIfc down into HttpCore would unblock the other 20 recipes and is left for the next recipe slice. **(93) TESTED THAT FORECAST AND IT DOES NOT HOLD.** httpCore.ts's own header says it owns the base URL, the bearer token and the low-level fetch helpers, "keeping transport concerns separate from the endpoint surface", and all eight of its methods are transport; editIfc is a DOMAIN endpoint (POST /projects/{pid}/edit). Moving it there would contradict that file's stated purpose and the layering SCALE-SEAM exists to establish. The answer is the NeedsEditIfc pattern, now shared from types.ts. I wrote that forecast as a plan one slice after (91) recorded that a placement forecast is a hypothesis for the next slice to TEST — and phrasing it as a plan is exactly what makes it read as settled. 84 above the banner now, still no map. # SCALE-SEAM (91): the R20 CRE DEAL DESK — should we transact on this income property, and on what terms? Thirteen methods to a new creDeal.ts (867 -> 746), one contiguous run: verify the seller's numbers (normalizeT12 — the tie-out is a gate; rentRollScrub — a check without its inputs reports not-run; netEffectiveRent; tieredComps; competitiveSupply), decide (holdSell, decisionGate), set the terms (clausePlaybook + reviewContractClauses, loanCovenants, dealAuthority). THREE INDEPENDENT SIGNALS, DERIVED, AND THEY AGREED — more than any slice in this sequence has had. (i) The source marks them: ten CRE- codes, and grepping apps/web/src showed those eleven occurrences are the ONLY ones in the whole web tree, all in client.ts. (ii) A 1:1 router match: every route these thirteen call (eleven distinct paths — the playbook and the authority table each have a read and a write half on one path) is served by aec_api/routers/realestate.py and by no other router, and its ten (R20) docstrings name the same ten codes — paired @router. line to def beneath it, not read top-to-bottom. (iii) One question runs through all thirteen. A marker alone would NOT have been enough: four shared-word traps (entitlements, view, carbon, lifecycle) are why CRE- counts as one vote of three and the router match carries the weight. THE BOUNDARY THAT DECIDES rent-roll: proforma.ts already holds GET /rent-roll and two of these sit under it on /rent-roll/scrub and /rent-roll/net-effective, so a prefix split would take all three. The backend states the boundary — the plain rent roll carries no CRE- code, no (R20), and its docstring calls it the operating rent roll "from the lease module (the hold phase)", while these two POST a body of numbers the counterparty supplied. What are we earning and is their number true are different questions sharing a prefix. AND (88)'S FORECAST WAS TESTED, NOT EXECUTED, AND IT LOST: (88) left camReconciliation with a note saying it "goes with rentRollScrub, netEffectiveRent and normalizeT12 when a rent-roll slice takes them". This is that slice and it did not take it — no CRE- code, no (R20), and /cam/reconciliation is served by operations.py, not realestate.py; a CAM true-up bills a completed operating year to sitting tenants. A placement forecast is a hypothesis for the next slice to test, not an instruction to carry out — phrased as a plan it reads as settled and invites the next reader to execute it without re-deriving anything. The note at the method now says what was measured. REVIEW OF #408 FOUND TWO THINGS AND THE SECOND WAS BIGGER THAN THE FIRST. (a) The fourth-corroboration caveat named one of test_cre_tier3's out-of-set routes and truncated its path; there are three (POST /proforma/scenarios, POST /proforma/scenarios/{sid}/review, GET /projects/{pid}/reports/ic_memo.pdf), all fixtures rather than assertions, so that claim holds for ASSERTED routes only. (b) The no-behaviour-change claim rested on apps/web/src/api/surface.test.ts, which spot-checks a name list none of the thirteen was on plus a floor of 751 on the total client surface — and the surface MEASURES 788. Losing one of the thirteen leaves 787 and passes; losing the whole mixin leaves 775 and passes. The count guarded nothing, which is precisely the slack that file's own comment at the 696 floor predicted would accumulate as endpoints are added; the review asserted the opposite ("losing any one reduces the count below 751"), off by 37. All thirteen are named there now and mutation-checked both ways (renaming holdSell fails naming it; restoring passes). A FLOOR THAT NEW WORK KEEPS CLEARING STOPS BEING A RATCHET WITHOUT EVER GOING RED — the same decay this item already records for client.ts > 1200 and for the banner-string proxy, now found in a third gate. The fix is to name the group, not to raise the floor. 88 above the banner now, still no map. # SCALE-SEAM (90): the CLIENT PORTAL — how does someone with no account see this project and answer back? Eight methods to a new clientPortal.ts (906 -> 867): the owner half mints/lists/revokes share tokens and reads what came back, the recipient half is the token-authenticated public surface (page + digest URLs, comment, approve/acknowledge/decline). The TOKEN is the seam — minted on one side, IS the credential on the other, revoking closes both — so splitting owner from recipient would put a capability and its only means of exercise in different files. aec_api/routers/client_portal.py groups the same set: 8 of its 9 routes, checked. The ninth (/shared/{token}/model.frag) has no client method BY DESIGN — the server-rendered share page fetches it, not this SPA. FOUND ON THE WAY, NOT FIXED HERE: that route serves geometry only to a token minted with show_model, an opt-in the backend treats as independent of show_payments — and createShareToken never sends it, nor does the returned row type carry it. Every token this product mints has it false, so the public 3D viewer is dark from the UI. Left alone because an extraction slice's claim is that no behaviour changed; recorded in the mixin header at the method. AND THE EXTRACTION SCRIPT HAD A REAL BUG, caught by docComments.test.ts rather than by me: its brace counter only terminated when j>i, so a ONE-LINE method consumed one line too many and swallowed the NEXT method's doc comment. sharedPageUrl and sharedDigestUrl are one-liners; the first draft dragged spaceUtilBenchmarks's SPACE-UTIL doc out of this file and duplicated sharedPageUrl's. Reverted and re-extracted. Seven of these eight carry /** */ docs, which the walk-back did not handle either until this slice — (88) and (89) survived only because their methods used // banners. THE GATE FOUND WHAT MY OWN ORPHAN CHECK MISSED: mine treated a following comment as an acceptable neighbour, which is exactly the case that defines the defect. 101 above the banner now, still no map. # SCALE-SEAM (89): TWO clusters, two new mixins, eight methods (953 -> 906). The four /resilience/* to resilience.ts — what could the ENVIRONMENT do to this project, asked of the site (flood/SFHA/design flood elevation), the civil design (runoff, detention) and the programme (weather-sensitive activities, delay days), plus the composite that folds all three into one rating. TENSION NAMED RATHER THAN SMOOTHED: resilienceWeather reads ACTIVITIES with trade/start/finish/percent, which is schedule.ts vocabulary and a subject-matter split would send it there; it stays because climateRisk consumes its weather_delay_days in the same composite as the flood and runoff numbers, and separating an input from the rollup that eats it is the split (87) had to undo. AND THE BANNER OVER-CLAIMED FOR THE SIXTH TIME: "climate & water resilience (flood + stormwater)" named TWO of the four beneath it, weather and the composite filed at whatever header was nearest — same defect as ⓽'s AI-drafting banner, (81)'s ifcClassify under a G704 header and (82)'s RACI banner describing 4 of 13. The four /responsibility/* to responsibility.ts — who is ACCOUNTABLE for what. aec_api/routers/responsibility.py holds those four routes AND NOTHING ELSE, a 1:1 router correspondence, checked rather than assumed. NOT filed on modules.ts even though that router's own docstring says the rows ARE ordinary module records whose CRUD lives there: storage is a HOW, and "they are all module records" is (85)'s "they are all multipart uploads" one layer down. Four methods is a small file and that is fine — risk/dealMemory/assetRights hold two each. ResponsibilityMatrix's type import left client.ts with them; it had no other reader. 109 above the banner now, still no map. # SCALE-SEAM (88): the OPERATE-PHASE cluster, and the FIRST slice from the 126 methods that were never in any map (1015 -> 953). Nine to a new operations.ts — cmms x2, energyActual, energyBenchmarkStatus, twinReadiness, fca x2, reserveStudy, esgSummary — answering "how is this asset performing in service, and what will it need?". Checked against the backend rather than assumed: all nine are served by aec_api/routers/operations.py, whose docstring names the same cluster. THREE DID NOT COME, and the words say otherwise on every one. lifecycle/lifecycleSeed are DESIGN lifecycle (RIBA/AIA stage gates, design_fee_pct, soft_costs) — the fourth shared-word trap after entitlements, view and carbon. projectCarbon is EMBODIED carbon, a design estimate, while esgSummary GHG comes from meters. camReconciliation shared reserveStudy's banner AND its backend router and still stayed: it allocates recoverable opex across TENANTS and returns balance_due per suite, a lease answer, so it waits for the rent-roll slice with rentRollScrub, netEffectiveRent and normalizeT12. Its banner is rewritten in client.ts rather than left naming a method that has gone. AND THE STAYING BANNER CITED esgSummary as an example of work still above the line — a banner offering, as evidence of what is unfinished, a method this slice moved. Corrected, and it now says to re-derive rather than read. # SCALE-SEAM (87): the CX-1 residue is FINISHED — 13 methods to elements/entitlements/proforma/estimate/modules/procurement/schedule/evm.ts (1131 -> 1015), and five more types out of client.ts into types.ts. TWO CORRECTIONS OF MY OWN EARLIER WORK. (i) ⓽ moved bidLevelingDetail to procurement.ts reasoning about procurementLevel and never noticed bidLeveling, the SUMMARY its detail belongs to, sitting in the same file — a rollup separated from its detail, the exact split (83) and (84) refused. Reunited. (ii) modules.ts carried a "compliance expiry" banner since SCALE-SEAM ④ (v0.3.803) whose method never came: complianceExpiring stayed in client.ts while its LABEL sat above addEnumOption. docComments.test.ts could not see it — its stranded check looks for /** */ above /** */, and this is a // banner above an undocumented method. AND THE BIG ONE: deriving the whole population showed client.ts has 130 methods, only 4 of them under the banner — 126 above it were never in any map. So (85)'s roadmap_status predicate ("--- UNFILED —" in client.ts) was ALSO a proxy: it would have declared SCALE-SEAM done with 126 methods outstanding. Replaced with a count of methods beyond the file's declared keep-list. # SCALE-SEAM (86): executivePortfolio + constructionPortfolio -> evm.ts, portfolioPrioritization -> proforma.ts, smart views -> elements.ts (1173 -> 1131). THE PORTFOLIO TRIO SPLIT 2/1: two REPORT status and are the cross-project form of evm.ts's projectHealth ("is the job on track across domains?"); the third RANKS deals and belongs with the pipeline in proforma.ts. And a shared WORD is not a shared domain for the third slice running: modules.ts already had a saved-views family (SavedViewDef = {q, state, sort}, a data-grid filter) and the name matched exactly, but a SmartView is {selector, mode: isolate|color|hide} that resolves to GUIDs — a saved SELECTION, so it went to elements.ts beside colorBy. # SCALE-SEAM (85): source-model ingest + the RVT bridge -> model.ts, raisePlan -> authoring.ts, takeoffDxf -> estimate.ts (1212 -> 1173). MECHANISM IS NOT A QUESTION: (84) had grouped these five as "how do I get a file into this project?", which is really "they are all multipart uploads" — a HOW. Read for what they answer and they split FOUR ways. rvtBridgeStatus did NOT go to entitlements.ts: that mixin is LAND-USE entitlements (planning approvals), a homonym. Also widened unfiledMap.test.ts, which matched only 2-space method indentation and so could not see authoring.ts (37 methods), assetRights, docqa or library — the async bug again, in the gate written to prevent it; it now asserts every mixin contributes at least one name. # SCALE-SEAM (84): dev budget + draws -> proforma.ts, pricing/traceability -> cost.ts, subcontractorBilling -> accounting.ts (1292 -> 1212), and the DevBudget* interfaces out of client.ts into types.ts, where a mixin can import them. THE TYPES DECIDED THE SPLIT: gmpReconciliation and syncGmpToHard look like cost.ts work (㉚ put the GMP stack there) but both return DevBudgetLine/DevBudgetSummary, and filing them there would have forced one type family into two mixins. cost.ts gmpBudget is the GC's own GMP; these two are the developer comparing against it. ALSO: (83) recorded the CX-1 banner as 44 methods using a regex that did not match `async` — it was 49. The right number was in the roadmap and (83) "corrected" it to a wrong one. Restored, and the UNFILED map is now derived by apps/web/src/api/unfiledMap.test.ts rather than proofread. # SCALE-SEAM (83): commissioning -> documents.ts, model checks + rebarCheckCage -> model.ts, qtoByFloor -> estimate.ts (1339 -> 1292). The "CX-1 commissioning loop" banner ran to the END of the file over 44 methods, three of them commissioning; with those three gone it named NOTHING, so it is replaced by an UNFILED map of the 35 that remain rather than narrowed. Two placements came from return shapes, not routes: qtoByFloor looks like a quantity and reads /qto/, but every line carries rate and amount and the payload has a grand_total, so it is priced takeoff; and rebarCheckCage came to model.ts while its two /rebar/ siblings did NOT, because a bar bending schedule is a quantity and an ACI cage check is the same question envelopeAudit asks. # SCALE-SEAM (82): model-quality audits -> model.ts, namingAudit -> documents.ts (1374 -> 1339). The RACI banner covered THIRTEEN methods and described four. namingAudit was on its way to model.ts until the return shapes were compared with documents.ts's namingConventions — same two subjects, containers and sheets, one stating the pattern and one reporting compliance. The banner is now split, and the three methods still under it that are not RACI are named as unfiled rather than left implicit. # SCALE-SEAM (81, unnumbered — the ⓵–⓾ glyph range is exhausted and the item carries no mark): turnover/G704 -> documents.ts, ifcClassify -> model.ts, market escalation -> cost.ts (1436 -> 1374). THIRD banner in three slices that over-claimed: ifcClassify sat under "turnover: substantial completion (G704)" separated by a blank line, a model question filed at whatever banner was nearest. # SCALE-SEAM ⓾: concept-render + aiReadiness -> ai.ts (1462 -> 1436). aiReadiness had been declined TWICE — by ai.ts at ㉑ on route grounds ("it is /ai-readiness"), and by documents.ts at ㉛ on semantic grounds ("it is an AI scorecard, not a CDE question"). The second characterisation is what moved it; the first is the superseded rule. MARKS widened to ⓾ (U+24FE), the last of the double-circled range. # SCALE-SEAM ⓽: drafting -> ai.ts, extractSheets -> drawingSheets.ts, bidLevelingDetail -> procurement.ts (1512 -> 1462). One banner, THREE questions: the "AI drafting" section labelled where the /draft/ run started and then carried on into sheet extraction and bid levelling — the exact failure procurement.ts's own header recorded at ⑥. No version bump (tag lag at bound). # v0.3.1143 follow-on SCALE-SEAM ⓺+⓻+⓼: preflight -> documents.ts, types+groups -> authoring.ts (1584 -> 1512). # v0.3.1143 follow-on SCALE-SEAM ⓷+⓸+⓹: license -> auth.ts, land -> entitlements.ts, pins -> topics.ts (1663 -> 1584). # v0.3.1143 follow-on SCALE-SEAM ⓴+⓵+⓶: clash import -> clash.ts, jobs -> routines.ts, projects -> auth.ts (1740 -> 1663). # v0.3.1143 follow-on SCALE-SEAM ⓱+⓲+⓳: inbox+escalations -> routines.ts, versions -> model.ts (1814 -> 1740). # v0.3.1143 follow-on SCALE-SEAM ⓮+⓯+⓰: roster+audit -> auth.ts, presence -> sync.ts (1867 -> 1814). # v0.3.1143 follow-on SCALE-SEAM ⓫+⓬+⓭: health -> evm.ts, safety+field-log -> schedule.ts, E57 -> model.ts (1916 -> 1867). # v0.3.1143 follow-on SCALE-SEAM ❽+❾+❿: bidding -> procurement.ts, quality -> topics.ts, closeout -> documents.ts (1966 -> 1916). # v0.3.1143 follow-on SCALE-SEAM ❺+❻+❼: actions -> routines.ts, RFI register -> topics.ts, feasibility -> entitlements.ts (2_000 -> 1966). # v0.3.1143 follow-on SCALE-SEAM ❷+❸+❹: ask -> ai.ts, submittals -> procurement.ts, CO log -> contracts.ts (2_035 -> 2_000). # v0.3.1143 follow-on SCALE-SEAM ㊾+㊿+❶: reports -> documents.ts, T&M + WH-347 -> cost.ts (2_065 -> 2_035). CJK enclosed numbers end at ㊿; ❶ is 51. # v0.3.1143 follow-on SCALE-SEAM ㊻+㊼+㊽: verification -> model.ts, rent-roll -> proforma.ts, opendata permits -> entitlements.ts (2_127 -> 2_065). # v0.3.1143 follow-on SCALE-SEAM ㊸+㊹+㊺: view templates -> model.ts, selections -> contracts.ts, progress -> schedule.ts (2_194 -> 2_127). # v0.3.1143 follow-on SCALE-SEAM ㊵+㊶+㊷: layout+loads -> model.ts, optioneer -> authoring.ts (2_258 -> 2_194). leftover // banners deleted. # v0.3.1143 follow-on SCALE-SEAM ㊲+㊳+㊴: graph+layers -> model.ts, macros -> authoring.ts (2_323 -> 2_258). # v0.3.1143 follow-on SCALE-SEAM ㉞+㉟+㊱: structure -> model.ts, RFI -> topics.ts, logistics -> schedule.ts (2_440 -> 2_323). No version bump (tag lag at bound). # v0.3.1143 SCALE-SEAM ㉝: Last-Planner pull board -> schedule.ts (2_486 -> 2_440). # v0.3.1142 SCALE-SEAM ㉜: appraisal/listing -> proforma.ts (2_531 -> 2_486). # v0.3.1141 SCALE-SEAM ㉛: ISO 19650 CDE/BEP/info-requirements -> documents.ts (2_580 -> 2_531). # v0.3.1140 SCALE-SEAM ㉚: GMP / pay-app stack -> cost.ts (2_641 -> 2_580). # v0.3.1139 SCALE-SEAM ㉙: investor capital stack -> finance.ts (2_696 -> 2_641), nine methods, existing withFinance wrapper. # v0.3.1134: clash group -> clash.ts (2_731 -> 2_696). SOFT-CLASH-RULES added clashClearanceRules + clashMatrix; the pin refused them in this file so the whole /clash cluster moved. # v0.3.1124: the four refusal-aware response shapes moved to types.ts as named interfaces (2_769 -> 2_731, under the 2_752 pin they had broken). THE RATCHET DID ITS JOB: 18 lines of new response fields went into this file and it went red, which is the whole point — types.ts exists precisely so the type surface lives apart from the client, and its header says so. The pin comes DOWN 21 rather than up, and the file is now 20 lines below where main had it. # ㉘ SCALE-SEAM ㉘ construction accounting -> accounting.ts (2_816 -> 2_752), ten methods in TWO non-contiguous clusters ~700 lines apart, which is the strongest case for grouping by what methods ANSWER: no prefix split would have found them together, and `journalBatchExportUrl` builds the URL for the batch `createJournalBatch` creates. The 2_837 this replaces was ㉗'s; v0.3.1119 had already taken it to 2_816 under duress from this very check, without lowering the pin — so the ratchet had slack it had not been told about. + "apps/web/src/api/client.ts": 642, # SCALE-SEAM (100): THE ELEMENT-CONNECTION PAIR — what is physically joined to what, and record a joint? (648 -> 642). elementConnections + connectElements to model.ts. BOUND BY THE BACKEND NAMING ITS OWN WRITER (the (96) shape): the /element-connections route docstring says "Author edges with the connect_elements recipe (POST /edit with {guid_a, guid_b})". DESTINATION ARGUMENT IS WEAKER THAN THE PAIRING ARGUMENT AND IS STATED SO: model.ts owns modelGraphStats (counts the IFC relationship graph BY RELATION, and IfcRelConnectsElements is one) and graphNeighbors (walks it), so this is one relation of that graph plus its verb — a SPECIALISATION, not an identity. REJECTED ON CHECKABLE GROUNDS: connections.ts is DATA-SOURCE connections (SQL/ACC/Procore), sharing only the English word — (97) same collision, in a destination; elements.ts holds element ATTRIBUTES, and a relationship between two elements is not an attribute of either. addBasePlate/addShearTab did NOT come despite sharing connections.py: a backend module is a HOW, and they author PHYSICAL assemblies, not IfcRelConnectsElements edges. # SCALE-SEAM (99): THE CONTENT SHELF — what pre-made content can I place, and place it? (665 -> 648). contentCatalog + placeContent + importContent to authoring.ts. WITNESS IS A ROLE-FOR-ROLE PARALLEL with the family shelf already there, read off the signatures not the shared word "shelf": familyCatalog/contentCatalog (catalog reader, both {count, ...Record<..>}), placeFamily/placeContent (placer), importFamilies/importContent (async multipart importer). Three roles, three methods each. A parallel between two method TRIPLES is structural; "both are shelves" would be a word, the grouping (88) and (89) rejected. SMALL FINDING: authoring.ts line 1 had said "the family/content shelf" while the file held ZERO content methods — a docstring describing an intended scope as fact. Corroboration that was FALSE, not evidence. # SCALE-SEAM (98): DETAILING CARRIERS — what informational carriers are attached to this element, write them, and which are missing? (687 -> 665). New detailing.ts: elementDetailing + classify + applyDetailingRules + validateDetailing + attachDocument. WITNESS IS A 1:1 AND TOTAL FIELD-TO-WRITER MAP, the (96) shape: element_detailing walks HasAssociations and branches on exactly two relationship types, and detailing.py holds exactly two writers — classifications[] <- classify (IfcRelAssociatesClassification), documents[] <- attachDocument (IfcRelAssociatesDocument). The other two are those same writes automated (rule engine) and audited (gap report). NOT CLAIMED: attachOmDocument, moved to model.ts in (96), wraps the SAME detailing.attach_document and also lands in documents[], so "all the writers of this reader" is false; the map is total over detailing.py, not over the codebase. ADJACENCY IS NOT EVIDENCE: these five were contiguous, so unlike (95) a positional split would also have found them. # SCALE-SEAM (97): THE UNDO STACK — what has been done to this model, and can I take it back? (698 -> 687). editHistory/editUndo/editRedo to authoring.ts, because editIfc — already there — is the PUSH they pop: authoring.py records the pre-edit version on every /edit call "so this edit can be undone", _restore_version pops it, edit_history.state() reads its depths. TYPE-LEVEL: both writers return {restored, state:{can_undo,can_redo}} and state IS the reader's type minus depths. HYPOTHESIS TESTED AND WITHDRAWN: "undo restores the prior model version" makes model.ts look right, but modelVersions reads /projects/{pid}/versions out of bim.py while undo pops a DIFFERENT stack in the edit_history sidecar. Two stacks, one word. # SCALE-SEAM (96): AS-BUILT/TURNOVER — its aggregate READER plus the two writers still feeding it (711 -> 698). lod500 + setManufacturerInfo + attachOmDocument to model.ts, rejoining verifyAsbuilt/recordAsbuiltDimension from (94). TWO BOUNDING WITNESSES: openAsBuiltPanel calls exactly five API methods (read off the brace closure, not grepped), two already moved; and asbuilt_summary's response type names its writer set field by field. test_lod500.py CORROBORATES but does NOT bound — it reaches three recipes and omits record_asbuilt_dimension, a known member, so it cannot establish a boundary. NOT CLAIMED: attachDocument (staying) takes a purpose param and can also produce with_om_docs, so "every writer of with_om_docs moves" is false. # SCALE-SEAM (95): ELEMENT STATE — what state are the model's elements in, and set it? (727 -> 711). Two read/write pairs to model.ts: lodSummary/setLod (element maturity 100-500) and phasing/setPhase (new/existing/demolish/temporary). IDENTICAL RETURN SHAPE — both {total, ed, prop, counts: Record<...>}; both writers (pid, guids, , publish) -> editIfc; both readers consumed by viewer/tools/modelStatePanels.ts; both writers UNWIRED and ADJACENT on clientCallers.test.ts's UNCALLED allowlist. AND lodSummary WAS A SIBLING SEPARATED FROM ITS OWN FAMILY: model.ts already held /model/lod/census, /lod/handover-readiness and /lod/assessment while the BASE distribution /projects/{pid}/lod stayed in client.ts. THE MATRIX DISAGREES AND IT LOSES, which is worth stating rather than eliding: authoring_matrix.py files set_lod under `data` and set_phase under `lifecycle` because it categorises by the IFC OUTPUT each recipe writes — an LOD stage tag against Massing_Phasing.Status. Different psets, same question. THAT IS (89)'S "STORAGE IS A HOW" TRAP: "they write different property sets" has the same shape as "they are all module records", and neither is a question. THIS ALSO MEETS (94)'S OBJECTION RATHER THAN OVERRIDING IT: that slice declined setPhase because taking the writer would have stranded phasing() in client.ts, the reader/writer split (87) had to undo. Both halves move together here, so nothing is separated. NOT CONTIGUOUS — the pairs sat at 271-279 and 293-301 with ensureContexts and queryElements between; (88) recorded that as the strongest case for grouping by what methods ANSWER, since no prefix or positional split would find them together. 76 above the banner now, still no map. # SCALE-SEAM (94): the as-built pair ㊻ COULD NOT SEE (731 -> 727). verifyAsbuilt (stamps Massing_AsBuilt, the LOD-500 reliability layer) and recordAsbuiltDimension (a field-verified dimension + variance vs design) to model.ts, which since ㊻ has held "field-install verification — is this element installed as designed?" with verificationCoverage, setVerification and verificationDeviations. Both answer exactly that question and NEITHER IS NAMED IN ㊻'S HEADER. WHY ㊻ MISSED THEM: it split on the /verification/* ROUTE PREFIX, and these two go through editIfc so they carry no route to be found by. A ROUTE-PREFIX SPLIT CANNOT SEE A RECIPE-BASED SIBLING OF THE SAME QUESTION. They were also unmovable at the time — editIfc is declared on the Authoring mixin rather than HttpCore, so a mixin typed Ctor does not compile. THIRD slice found to have left work behind for that reason, after ⑲'s MEP pair (taken by (93)). THE MATRIX ARGUED FOR A THIRD METHOD AND IT WAS DECLINED: authoring_matrix.py's `lifecycle` category is exactly these two plus set_phase — a COMPLETE category, the very signal that decided (92)'s annotate slice. setPhase stays because it answers a different question (tag a construction phase: new/existing/demolish/temporary — element state in the build sequence, not install-versus-design) AND because its read half phasing() is still in client.ts; taking a writer and leaving its reader is the split (87) had to undo. A COMPLETE CATEGORY IS ONE VOTE, NOT A VERDICT — and "lifecycle" is a word (88) already caught misleading once, in a different way. withModel now declares NeedsEditIfc and must compose outside withAuthoring; probe-checked with an isolated file applying withModel to bare HttpCore, which fails TS2345 naming NeedsEditIfc. THE FIRST ATTEMPT AT THAT CHECK WAS WORTHLESS AND READING IT IS THE ONLY REASON I KNOW: it rebalanced parens wrongly and went red with TS1005 syntax errors, so it proved nothing about composition order while looking exactly like a pass of the mutation test. THE BANNER NOTE IN client.ts WAS CONDENSED, and that is the ratchet working: the first draft added 9 lines of prose while the extraction removed 8, netting +1 — an extraction slice that grows the file has failed its purpose. The reasoning lives once, in model.ts's header, rather than twice. REVIEW OF #411 FOUND AN OVERSTATEMENT I HAD ASKED IT TO LOOK FOR: the PR description scoped the claim as "two known missed members, not necessarily all members" while model.ts said "finishes that question" and surface.test.ts said "completing its verification question". HEDGING IN THE REVIEW REQUEST WHILE THE ARTIFACT OVERSTATES IS NOT SCOPING — it puts the caveat where a reviewer sees it and the overstatement where every later reader will, which is worse than a plain overstatement because it looks like discipline. Fourth instance of one defect across four slices, and the first where the correct wording already existed and simply did not reach the code. Both corrected. AND THE COMPOSITION-ORDER CONSTRAINT IS NOW A TEST RATHER THAN A CLAIM: apps/web/src/api/compositionOrder.test.ts asserts with @ts-expect-error that withAnnotate, withMep and withModel all reject a bare HttpCore base. I had reported it as mutation-checked, but the check was a scratch file I deleted, so nobody could verify it — A VERIFICATION THAT LEAVES NO ARTIFACT IS A CLAIM, NOT A CHECK. Mutation-checked in turn: relaxing withMep to Ctor fails TS2578 'Unused @ts-expect-error directive' naming the line. 80 above the banner now, still no map. # SCALE-SEAM (93): the two MEP recipes ⑲ HAD TO leave behind (733 -> 731). connectMep + addMepFitting to mep.ts, whose own header since ⑲ said they "call editIfc (/edit) and stay" — A NOTE THAT RECORDED THE SYMPTOM WITHOUT DIAGNOSING THE CAUSE. They could not come because editIfc is declared on the Authoring mixin rather than on HttpCore, so a mixin typed Ctor cannot see it and the extraction does not compile. (92) found that; (93) applies it. A METHOD LEFT BEHIND FOR A REASON NOBODY WROTE DOWN STAYS BEHIND INDEFINITELY — ⑲'s note read as a placement decision and was a compiler error. NeedsEditIfc moved from annotate.ts into types.ts so both mixins share ONE definition: two hand-copied signatures are exactly the drift the #409 review had to check by hand, since a copy subtly WIDER than the real editIfc typechecks at the mixin and still breaks at a call site. Mutation-checked: composing withMep inside withAuthoring fails with TS2345 naming NeedsEditIfc. EVIDENCE IS WEAKER THAN (92)'S AND IS STATED AS SUCH: this is NOT a complete authoring_matrix category (create-mep has 11 members, edit-mep 3, of which these are one each). The boundary is "MEP recipe exposed as a TYPED client method" — exactly these two. TWELVE MEP recipes remain in the matrix (11 create-mep + 3 edit-mep, less these two): nine are driven from viewer code through the generic recipe path in draftCatalog.ts and mepSection.ts, and THREE (add_sprinkler, auto_connect_mep, set_system_predefined) are referenced nowhere in apps/web/src at all — backend recipes with no web exposure, recorded rather than fixed. THIS SAID "the other nine" UNTIL REVIEW, AND IT IS THE THIRD CONSECUTIVE SLICE WITH ONE DEFECT IN A THIRD DISGUISE: nine was the number I had ENUMERATED (the viewer-driven ones), twelve is the number that REMAIN. (91) claimed no test_cre_* file reached outside its set while three reached out as fixtures; (92) claimed test_annotation.py exercised four recipes and no others while two more were tag-host fixtures; this enumerated a subset and wrote "the other". A reviewer found all three. THE FIX IS NOT TO BE MORE CAREFUL — IT IS TO DERIVE THE COMPLEMENT, set(all) - set(moved), and only then describe what is in it. test_mep_systems.py covers both AMONG other MEP recipes (corroborates family, does not bound the set) and test_guards.py is cross-cutting — said explicitly because the "no others" error was made in each of the two preceding slices. addMepFitting is callerless and stays on clientCallers.test.ts's allowlist: moving a method does not change its called-ness. 82 above the banner now, still no map. # SCALE-SEAM (92): ANNOTATION — put a note, a dimension, a cloud or a tag ON the model. Four methods to a new annotate.ts (746 -> 733): addAnnotation, addDimension, addRevisionCloud, addTag, all authoring real IfcAnnotation entities at world [E,N] through editIfc. THE SET IS BOUNDED BY TWO SOURCES SOMEBODY ELSE AUTHORED, not by the marker. (i) authoring_matrix.py, the curated recipe->category map behind the public authoring-coverage endpoint, has an `annotate` category holding EXACTLY these four of its 99 recipes across 15 categories — a complete category, nothing left behind and nothing pulled in. (ii) test_annotation.py exercises all four annotation recipes and no other recipe as its SUBJECT (it calls add_wall and add_column once each as fixtures, to give add_tag a host). That qualification was missing until review, and it is the SECOND CONSECUTIVE SLICE to make the error — (91) claimed no test_cre_* file reached outside its set while test_cre_tier3 reached three routes as fixtures. Both times the claim counted what a test TARGETS and ignored what it SETS UP. A "nothing else" claim about a test must say whether it means assertions or every call the file makes. THE `UX-2` MARKER DOES NOT BOUND THE SET, AND THAT DISTINCTION IS THE POINT: (91)'s `CRE-` occurred only in client.ts so it drew its own boundary, while UX-2 occurs 12 times across three files (client.ts, viewer/app.ts, viewer/tools/annotationSection.ts) and marks a FEATURE WORKSTREAM — it corroborates purpose and is silent on membership. Two markers, two strengths; treating every prefix as a set boundary is how a cluster gets the wrong members. Third corroboration: viewer/tools/annotationSection.ts, the UI these serve, makes exactly four api.* calls and they are these four. NOT markup.ts, the obvious guess: that is 2D SHEET markup (a pin at a sheet x/y carrying a note, stored as a markup record, promotable to RFI, route-group /drawings/markup), while these author MODEL CONTENT that travels with the IFC. A comment layer over a drawing and drawing content authored into the model are different questions sharing the word "annotation". NOT authoring.ts, which is the harder call because it DEFINES editIfc and holds seven recipes, and its header claims "the endpoints that WRITE to the model rather than read from it" — which would take all 24 recipes still in client.ts. A DESCRIPTION BROAD ENOUGH TO TAKE EVERYTHING IS NOT A SEAM: its demonstrated practice is narrower than its sentence, having declined detailing at 8, property-override layers at 33 ("those compose properties, they do not write recipes") and groups at 7. mep.ts settled the principle already — its methods "use editIfc (/edit) and stay" — and the matrix proves it, splitting those 24 recipes across NINE categories, so editIfc cannot be the seam. AND A TECHNICAL FINDING THAT PROBABLY EXPLAINS THE WHOLE BACKLOG: this is the first mixin to call editIfc WITHOUT DECLARING IT (authoring.ts calls it seven times but defines it, so it never needed a base type promising it — which is how eleven slices passed these recipes without hitting this). editIfc is declared on the Authoring mixin rather than on HttpCore, so a mixin typed Ctor cannot see it and the extraction does not compile — the same shape authoring.ts records blocking the SSE methods. annotate.ts declares the requirement in its type (NeedsEditIfc) and must be composed outside withAuthoring; mutation-checked by composing it inside, which fails with TS2345 naming editIfc rather than failing at runtime. Moving editIfc down into HttpCore would unblock the other 20 recipes and is left for the next recipe slice. **(93) TESTED THAT FORECAST AND IT DOES NOT HOLD.** httpCore.ts's own header says it owns the base URL, the bearer token and the low-level fetch helpers, "keeping transport concerns separate from the endpoint surface", and all eight of its methods are transport; editIfc is a DOMAIN endpoint (POST /projects/{pid}/edit). Moving it there would contradict that file's stated purpose and the layering SCALE-SEAM exists to establish. The answer is the NeedsEditIfc pattern, now shared from types.ts. I wrote that forecast as a plan one slice after (91) recorded that a placement forecast is a hypothesis for the next slice to TEST — and phrasing it as a plan is exactly what makes it read as settled. 84 above the banner now, still no map. # SCALE-SEAM (91): the R20 CRE DEAL DESK — should we transact on this income property, and on what terms? Thirteen methods to a new creDeal.ts (867 -> 746), one contiguous run: verify the seller's numbers (normalizeT12 — the tie-out is a gate; rentRollScrub — a check without its inputs reports not-run; netEffectiveRent; tieredComps; competitiveSupply), decide (holdSell, decisionGate), set the terms (clausePlaybook + reviewContractClauses, loanCovenants, dealAuthority). THREE INDEPENDENT SIGNALS, DERIVED, AND THEY AGREED — more than any slice in this sequence has had. (i) The source marks them: ten CRE- codes, and grepping apps/web/src showed those eleven occurrences are the ONLY ones in the whole web tree, all in client.ts. (ii) A 1:1 router match: every route these thirteen call (eleven distinct paths — the playbook and the authority table each have a read and a write half on one path) is served by aec_api/routers/realestate.py and by no other router, and its ten (R20) docstrings name the same ten codes — paired @router. line to def beneath it, not read top-to-bottom. (iii) One question runs through all thirteen. A marker alone would NOT have been enough: four shared-word traps (entitlements, view, carbon, lifecycle) are why CRE- counts as one vote of three and the router match carries the weight. THE BOUNDARY THAT DECIDES rent-roll: proforma.ts already holds GET /rent-roll and two of these sit under it on /rent-roll/scrub and /rent-roll/net-effective, so a prefix split would take all three. The backend states the boundary — the plain rent roll carries no CRE- code, no (R20), and its docstring calls it the operating rent roll "from the lease module (the hold phase)", while these two POST a body of numbers the counterparty supplied. What are we earning and is their number true are different questions sharing a prefix. AND (88)'S FORECAST WAS TESTED, NOT EXECUTED, AND IT LOST: (88) left camReconciliation with a note saying it "goes with rentRollScrub, netEffectiveRent and normalizeT12 when a rent-roll slice takes them". This is that slice and it did not take it — no CRE- code, no (R20), and /cam/reconciliation is served by operations.py, not realestate.py; a CAM true-up bills a completed operating year to sitting tenants. A placement forecast is a hypothesis for the next slice to test, not an instruction to carry out — phrased as a plan it reads as settled and invites the next reader to execute it without re-deriving anything. The note at the method now says what was measured. REVIEW OF #408 FOUND TWO THINGS AND THE SECOND WAS BIGGER THAN THE FIRST. (a) The fourth-corroboration caveat named one of test_cre_tier3's out-of-set routes and truncated its path; there are three (POST /proforma/scenarios, POST /proforma/scenarios/{sid}/review, GET /projects/{pid}/reports/ic_memo.pdf), all fixtures rather than assertions, so that claim holds for ASSERTED routes only. (b) The no-behaviour-change claim rested on apps/web/src/api/surface.test.ts, which spot-checks a name list none of the thirteen was on plus a floor of 751 on the total client surface — and the surface MEASURES 788. Losing one of the thirteen leaves 787 and passes; losing the whole mixin leaves 775 and passes. The count guarded nothing, which is precisely the slack that file's own comment at the 696 floor predicted would accumulate as endpoints are added; the review asserted the opposite ("losing any one reduces the count below 751"), off by 37. All thirteen are named there now and mutation-checked both ways (renaming holdSell fails naming it; restoring passes). A FLOOR THAT NEW WORK KEEPS CLEARING STOPS BEING A RATCHET WITHOUT EVER GOING RED — the same decay this item already records for client.ts > 1200 and for the banner-string proxy, now found in a third gate. The fix is to name the group, not to raise the floor. 88 above the banner now, still no map. # SCALE-SEAM (90): the CLIENT PORTAL — how does someone with no account see this project and answer back? Eight methods to a new clientPortal.ts (906 -> 867): the owner half mints/lists/revokes share tokens and reads what came back, the recipient half is the token-authenticated public surface (page + digest URLs, comment, approve/acknowledge/decline). The TOKEN is the seam — minted on one side, IS the credential on the other, revoking closes both — so splitting owner from recipient would put a capability and its only means of exercise in different files. aec_api/routers/client_portal.py groups the same set: 8 of its 9 routes, checked. The ninth (/shared/{token}/model.frag) has no client method BY DESIGN — the server-rendered share page fetches it, not this SPA. FOUND ON THE WAY, NOT FIXED HERE: that route serves geometry only to a token minted with show_model, an opt-in the backend treats as independent of show_payments — and createShareToken never sends it, nor does the returned row type carry it. Every token this product mints has it false, so the public 3D viewer is dark from the UI. Left alone because an extraction slice's claim is that no behaviour changed; recorded in the mixin header at the method. AND THE EXTRACTION SCRIPT HAD A REAL BUG, caught by docComments.test.ts rather than by me: its brace counter only terminated when j>i, so a ONE-LINE method consumed one line too many and swallowed the NEXT method's doc comment. sharedPageUrl and sharedDigestUrl are one-liners; the first draft dragged spaceUtilBenchmarks's SPACE-UTIL doc out of this file and duplicated sharedPageUrl's. Reverted and re-extracted. Seven of these eight carry /** */ docs, which the walk-back did not handle either until this slice — (88) and (89) survived only because their methods used // banners. THE GATE FOUND WHAT MY OWN ORPHAN CHECK MISSED: mine treated a following comment as an acceptable neighbour, which is exactly the case that defines the defect. 101 above the banner now, still no map. # SCALE-SEAM (89): TWO clusters, two new mixins, eight methods (953 -> 906). The four /resilience/* to resilience.ts — what could the ENVIRONMENT do to this project, asked of the site (flood/SFHA/design flood elevation), the civil design (runoff, detention) and the programme (weather-sensitive activities, delay days), plus the composite that folds all three into one rating. TENSION NAMED RATHER THAN SMOOTHED: resilienceWeather reads ACTIVITIES with trade/start/finish/percent, which is schedule.ts vocabulary and a subject-matter split would send it there; it stays because climateRisk consumes its weather_delay_days in the same composite as the flood and runoff numbers, and separating an input from the rollup that eats it is the split (87) had to undo. AND THE BANNER OVER-CLAIMED FOR THE SIXTH TIME: "climate & water resilience (flood + stormwater)" named TWO of the four beneath it, weather and the composite filed at whatever header was nearest — same defect as ⓽'s AI-drafting banner, (81)'s ifcClassify under a G704 header and (82)'s RACI banner describing 4 of 13. The four /responsibility/* to responsibility.ts — who is ACCOUNTABLE for what. aec_api/routers/responsibility.py holds those four routes AND NOTHING ELSE, a 1:1 router correspondence, checked rather than assumed. NOT filed on modules.ts even though that router's own docstring says the rows ARE ordinary module records whose CRUD lives there: storage is a HOW, and "they are all module records" is (85)'s "they are all multipart uploads" one layer down. Four methods is a small file and that is fine — risk/dealMemory/assetRights hold two each. ResponsibilityMatrix's type import left client.ts with them; it had no other reader. 109 above the banner now, still no map. # SCALE-SEAM (88): the OPERATE-PHASE cluster, and the FIRST slice from the 126 methods that were never in any map (1015 -> 953). Nine to a new operations.ts — cmms x2, energyActual, energyBenchmarkStatus, twinReadiness, fca x2, reserveStudy, esgSummary — answering "how is this asset performing in service, and what will it need?". Checked against the backend rather than assumed: all nine are served by aec_api/routers/operations.py, whose docstring names the same cluster. THREE DID NOT COME, and the words say otherwise on every one. lifecycle/lifecycleSeed are DESIGN lifecycle (RIBA/AIA stage gates, design_fee_pct, soft_costs) — the fourth shared-word trap after entitlements, view and carbon. projectCarbon is EMBODIED carbon, a design estimate, while esgSummary GHG comes from meters. camReconciliation shared reserveStudy's banner AND its backend router and still stayed: it allocates recoverable opex across TENANTS and returns balance_due per suite, a lease answer, so it waits for the rent-roll slice with rentRollScrub, netEffectiveRent and normalizeT12. Its banner is rewritten in client.ts rather than left naming a method that has gone. AND THE STAYING BANNER CITED esgSummary as an example of work still above the line — a banner offering, as evidence of what is unfinished, a method this slice moved. Corrected, and it now says to re-derive rather than read. # SCALE-SEAM (87): the CX-1 residue is FINISHED — 13 methods to elements/entitlements/proforma/estimate/modules/procurement/schedule/evm.ts (1131 -> 1015), and five more types out of client.ts into types.ts. TWO CORRECTIONS OF MY OWN EARLIER WORK. (i) ⓽ moved bidLevelingDetail to procurement.ts reasoning about procurementLevel and never noticed bidLeveling, the SUMMARY its detail belongs to, sitting in the same file — a rollup separated from its detail, the exact split (83) and (84) refused. Reunited. (ii) modules.ts carried a "compliance expiry" banner since SCALE-SEAM ④ (v0.3.803) whose method never came: complianceExpiring stayed in client.ts while its LABEL sat above addEnumOption. docComments.test.ts could not see it — its stranded check looks for /** */ above /** */, and this is a // banner above an undocumented method. AND THE BIG ONE: deriving the whole population showed client.ts has 130 methods, only 4 of them under the banner — 126 above it were never in any map. So (85)'s roadmap_status predicate ("--- UNFILED —" in client.ts) was ALSO a proxy: it would have declared SCALE-SEAM done with 126 methods outstanding. Replaced with a count of methods beyond the file's declared keep-list. # SCALE-SEAM (86): executivePortfolio + constructionPortfolio -> evm.ts, portfolioPrioritization -> proforma.ts, smart views -> elements.ts (1173 -> 1131). THE PORTFOLIO TRIO SPLIT 2/1: two REPORT status and are the cross-project form of evm.ts's projectHealth ("is the job on track across domains?"); the third RANKS deals and belongs with the pipeline in proforma.ts. And a shared WORD is not a shared domain for the third slice running: modules.ts already had a saved-views family (SavedViewDef = {q, state, sort}, a data-grid filter) and the name matched exactly, but a SmartView is {selector, mode: isolate|color|hide} that resolves to GUIDs — a saved SELECTION, so it went to elements.ts beside colorBy. # SCALE-SEAM (85): source-model ingest + the RVT bridge -> model.ts, raisePlan -> authoring.ts, takeoffDxf -> estimate.ts (1212 -> 1173). MECHANISM IS NOT A QUESTION: (84) had grouped these five as "how do I get a file into this project?", which is really "they are all multipart uploads" — a HOW. Read for what they answer and they split FOUR ways. rvtBridgeStatus did NOT go to entitlements.ts: that mixin is LAND-USE entitlements (planning approvals), a homonym. Also widened unfiledMap.test.ts, which matched only 2-space method indentation and so could not see authoring.ts (37 methods), assetRights, docqa or library — the async bug again, in the gate written to prevent it; it now asserts every mixin contributes at least one name. # SCALE-SEAM (84): dev budget + draws -> proforma.ts, pricing/traceability -> cost.ts, subcontractorBilling -> accounting.ts (1292 -> 1212), and the DevBudget* interfaces out of client.ts into types.ts, where a mixin can import them. THE TYPES DECIDED THE SPLIT: gmpReconciliation and syncGmpToHard look like cost.ts work (㉚ put the GMP stack there) but both return DevBudgetLine/DevBudgetSummary, and filing them there would have forced one type family into two mixins. cost.ts gmpBudget is the GC's own GMP; these two are the developer comparing against it. ALSO: (83) recorded the CX-1 banner as 44 methods using a regex that did not match `async` — it was 49. The right number was in the roadmap and (83) "corrected" it to a wrong one. Restored, and the UNFILED map is now derived by apps/web/src/api/unfiledMap.test.ts rather than proofread. # SCALE-SEAM (83): commissioning -> documents.ts, model checks + rebarCheckCage -> model.ts, qtoByFloor -> estimate.ts (1339 -> 1292). The "CX-1 commissioning loop" banner ran to the END of the file over 44 methods, three of them commissioning; with those three gone it named NOTHING, so it is replaced by an UNFILED map of the 35 that remain rather than narrowed. Two placements came from return shapes, not routes: qtoByFloor looks like a quantity and reads /qto/, but every line carries rate and amount and the payload has a grand_total, so it is priced takeoff; and rebarCheckCage came to model.ts while its two /rebar/ siblings did NOT, because a bar bending schedule is a quantity and an ACI cage check is the same question envelopeAudit asks. # SCALE-SEAM (82): model-quality audits -> model.ts, namingAudit -> documents.ts (1374 -> 1339). The RACI banner covered THIRTEEN methods and described four. namingAudit was on its way to model.ts until the return shapes were compared with documents.ts's namingConventions — same two subjects, containers and sheets, one stating the pattern and one reporting compliance. The banner is now split, and the three methods still under it that are not RACI are named as unfiled rather than left implicit. # SCALE-SEAM (81, unnumbered — the ⓵–⓾ glyph range is exhausted and the item carries no mark): turnover/G704 -> documents.ts, ifcClassify -> model.ts, market escalation -> cost.ts (1436 -> 1374). THIRD banner in three slices that over-claimed: ifcClassify sat under "turnover: substantial completion (G704)" separated by a blank line, a model question filed at whatever banner was nearest. # SCALE-SEAM ⓾: concept-render + aiReadiness -> ai.ts (1462 -> 1436). aiReadiness had been declined TWICE — by ai.ts at ㉑ on route grounds ("it is /ai-readiness"), and by documents.ts at ㉛ on semantic grounds ("it is an AI scorecard, not a CDE question"). The second characterisation is what moved it; the first is the superseded rule. MARKS widened to ⓾ (U+24FE), the last of the double-circled range. # SCALE-SEAM ⓽: drafting -> ai.ts, extractSheets -> drawingSheets.ts, bidLevelingDetail -> procurement.ts (1512 -> 1462). One banner, THREE questions: the "AI drafting" section labelled where the /draft/ run started and then carried on into sheet extraction and bid levelling — the exact failure procurement.ts's own header recorded at ⑥. No version bump (tag lag at bound). # v0.3.1143 follow-on SCALE-SEAM ⓺+⓻+⓼: preflight -> documents.ts, types+groups -> authoring.ts (1584 -> 1512). # v0.3.1143 follow-on SCALE-SEAM ⓷+⓸+⓹: license -> auth.ts, land -> entitlements.ts, pins -> topics.ts (1663 -> 1584). # v0.3.1143 follow-on SCALE-SEAM ⓴+⓵+⓶: clash import -> clash.ts, jobs -> routines.ts, projects -> auth.ts (1740 -> 1663). # v0.3.1143 follow-on SCALE-SEAM ⓱+⓲+⓳: inbox+escalations -> routines.ts, versions -> model.ts (1814 -> 1740). # v0.3.1143 follow-on SCALE-SEAM ⓮+⓯+⓰: roster+audit -> auth.ts, presence -> sync.ts (1867 -> 1814). # v0.3.1143 follow-on SCALE-SEAM ⓫+⓬+⓭: health -> evm.ts, safety+field-log -> schedule.ts, E57 -> model.ts (1916 -> 1867). # v0.3.1143 follow-on SCALE-SEAM ❽+❾+❿: bidding -> procurement.ts, quality -> topics.ts, closeout -> documents.ts (1966 -> 1916). # v0.3.1143 follow-on SCALE-SEAM ❺+❻+❼: actions -> routines.ts, RFI register -> topics.ts, feasibility -> entitlements.ts (2_000 -> 1966). # v0.3.1143 follow-on SCALE-SEAM ❷+❸+❹: ask -> ai.ts, submittals -> procurement.ts, CO log -> contracts.ts (2_035 -> 2_000). # v0.3.1143 follow-on SCALE-SEAM ㊾+㊿+❶: reports -> documents.ts, T&M + WH-347 -> cost.ts (2_065 -> 2_035). CJK enclosed numbers end at ㊿; ❶ is 51. # v0.3.1143 follow-on SCALE-SEAM ㊻+㊼+㊽: verification -> model.ts, rent-roll -> proforma.ts, opendata permits -> entitlements.ts (2_127 -> 2_065). # v0.3.1143 follow-on SCALE-SEAM ㊸+㊹+㊺: view templates -> model.ts, selections -> contracts.ts, progress -> schedule.ts (2_194 -> 2_127). # v0.3.1143 follow-on SCALE-SEAM ㊵+㊶+㊷: layout+loads -> model.ts, optioneer -> authoring.ts (2_258 -> 2_194). leftover // banners deleted. # v0.3.1143 follow-on SCALE-SEAM ㊲+㊳+㊴: graph+layers -> model.ts, macros -> authoring.ts (2_323 -> 2_258). # v0.3.1143 follow-on SCALE-SEAM ㉞+㉟+㊱: structure -> model.ts, RFI -> topics.ts, logistics -> schedule.ts (2_440 -> 2_323). No version bump (tag lag at bound). # v0.3.1143 SCALE-SEAM ㉝: Last-Planner pull board -> schedule.ts (2_486 -> 2_440). # v0.3.1142 SCALE-SEAM ㉜: appraisal/listing -> proforma.ts (2_531 -> 2_486). # v0.3.1141 SCALE-SEAM ㉛: ISO 19650 CDE/BEP/info-requirements -> documents.ts (2_580 -> 2_531). # v0.3.1140 SCALE-SEAM ㉚: GMP / pay-app stack -> cost.ts (2_641 -> 2_580). # v0.3.1139 SCALE-SEAM ㉙: investor capital stack -> finance.ts (2_696 -> 2_641), nine methods, existing withFinance wrapper. # v0.3.1134: clash group -> clash.ts (2_731 -> 2_696). SOFT-CLASH-RULES added clashClearanceRules + clashMatrix; the pin refused them in this file so the whole /clash cluster moved. # v0.3.1124: the four refusal-aware response shapes moved to types.ts as named interfaces (2_769 -> 2_731, under the 2_752 pin they had broken). THE RATCHET DID ITS JOB: 18 lines of new response fields went into this file and it went red, which is the whole point — types.ts exists precisely so the type surface lives apart from the client, and its header says so. The pin comes DOWN 21 rather than up, and the file is now 20 lines below where main had it. # ㉘ SCALE-SEAM ㉘ construction accounting -> accounting.ts (2_816 -> 2_752), ten methods in TWO non-contiguous clusters ~700 lines apart, which is the strongest case for grouping by what methods ANSWER: no prefix split would have found them together, and `journalBatchExportUrl` builds the URL for the batch `createJournalBatch` creates. The 2_837 this replaces was ㉗'s; v0.3.1119 had already taken it to 2_816 under duress from this very check, without lowering the pin — so the ratchet had slack it had not been told about. #: R39-DECOMP-VIEWER. Pinned at its CURRENT size before any extraction, deliberately. #: #: `app.ts` had no per-file entry, so it lived under the 5,200 global — which it also *set*, being