From 44a6ed4464b95861c3655af7d36202b4e8237c57 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 4 Sep 2026 04:06:12 +0000 Subject: [PATCH 01/12] =?UTF-8?q?SCALE-SEAM=20(95)=20=E2=80=94=20element?= =?UTF-8?q?=20state:=20two=20read/write=20pairs,=20and=20why=20the=20matri?= =?UTF-8?q?x=20loses?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Moves `lodSummary`/`setLod` and `phasing`/`setPhase` out of `client.ts` into `api/model.ts`. They answer one question — *what state are the model's elements in, and set it?* — and `client.ts` goes 727 -> 711, 76 methods above the STAYING banner. The grouping is derived, not asserted: - identical return shape `{ total, ed, prop, counts: Record<...> }`; - both writers are `(pid, guids, , publish) -> editIfc`; - both readers are consumed by `viewer/tools/modelStatePanels.ts` (251, 316); - both writers sit unwired and *adjacent* on `clientCallers.test.ts`'s UNCALLED allowlist; - `model.ts` already owned `/model/lod/census`, `/lod/handover-readiness` and `/lod/assessment`, while the base distribution `/projects/{pid}/lod` was left behind in `client.ts` — `lodSummary` was a sibling separated from its family. `authoring_matrix.py` DISAGREES and is recorded as the losing vote rather than elided. It 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 property sets, same question, which is (89)'s "storage is a HOW" trap. This is the first slice where the matrix has been wrong after being right three running. It also MEETS (94)'s objection rather than overriding it: that slice declined `setPhase` because taking the writer alone would have stranded `phasing()`, the reader/writer split (87) had to undo. Both halves move together here. The four names are added to `surface.test.ts` because its floor is a slack ratchet (788 actual vs 751 floor) — the count alone would not notice a loss — and because the UNCALLED allowlist is about call sites, not the surface. Verified: tsc 0, lint 0, `vitest run src/api` 27 files / 119 tests, build 0, `test_file_sizes.py` / `test_claude_md_gates.py` / `test_roadmap_status.py` / ruff all 0. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Tt2XKB83wwNt2nrMbK6eEA --- CHANGELOG.md | 41 ++++++++++++++++++++++++++++ apps/web/src/api/client.ts | 26 ++++-------------- apps/web/src/api/model.ts | 47 ++++++++++++++++++++++++++++++++ apps/web/src/api/surface.test.ts | 4 +++ docs/roadmap.md | 18 +++++++++++- services/api/test_file_sizes.py | 2 +- 6 files changed, 115 insertions(+), 23 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 6497e356..6f2b4bb9 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1185,6 +1185,47 @@ 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-fourth follow-on on the same version: **SCALE-SEAM (95)** — *element state, and a matrix +disagreement worth stating rather than eliding*. + +Four methods out of `client.ts` (`727 → 711`) into the existing `apps/web/src/api/model.ts`: the +`lodSummary`/`setLod` and `phasing`/`setPhase` pairs. No new mixin. **What they answer: what state +are the model's elements in, and set it.** + +### The shape is the argument + +Both readers return `{ total, ed, prop, counts: Record<…> }` — same three fields, differing only +in the second field's name and the key union. Both writers are `(pid, guids, , publish) → +editIfc`. Both readers are consumed by `apps/web/src/viewer/tools/modelStatePanels.ts`. Both writers +are unwired and sit **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 behind in `client.ts`. + +### `authoring_matrix.py` disagrees, and why it loses + +The matrix files `set_lod` under `data` and `set_phase` under `lifecycle`. That is a real +disagreement with this grouping and is recorded rather than elided. It loses because **the matrix +categorises by the IFC output each recipe writes** — an LOD stage tag against +`Massing_Phasing.Status`. Different property sets, same question. + +*That is (89)'s "storage is a HOW" trap: "they write different psets" has the same shape as "they are +all module records", and neither is a question.* The matrix has been a good witness three slices +running; this is the first time it has been the losing vote, which is the reason to say so plainly +rather than quietly not mentioning it. + +### It meets (94)'s objection rather than overriding it + +(94) 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 them. (88) recorded that as the strongest case for grouping by what methods answer, since no +prefix or positional split would ever find them together.* + +Pin 727 → 711. **76 above the banner, still no map.** + diff --git a/apps/web/src/api/client.ts b/apps/web/src/api/client.ts index 2e0c8b51..2ff7c7cc 100644 --- a/apps/web/src/api/client.ts +++ b/apps/web/src/api/client.ts @@ -267,16 +267,6 @@ export class ApiClient extends withAnnotate(withCreDeal(withClientPortal(withRes connections: { a: string; a_class: string; b: string; b_class: string; description: string | null }[] }>( `/projects/${pid}/element-connections`); } - /** W11 F0: element LOD-stage distribution (100/200/300/350/400/500/unset). */ - lodSummary(pid: string) { - return this.json<{ total: number; staged: number; prop: string; - counts: Record<"100" | "200" | "300" | "350" | "400" | "500" | "UNSET", number> }>( - `/projects/${pid}/lod`); - } - /** W11 F0: tag elements with a LOD stage (element maturity 100→500). */ - setLod(pid: string, guids: string[], stage: "100" | "200" | "300" | "350" | "400" | "500", publish = true) { - return this.editIfc(pid, "set_lod", { guids, stage }, publish); - } /** 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) { @@ -289,16 +279,6 @@ export class ApiClient extends withAnnotate(withCreDeal(withClientPortal(withRes elements: { guid: string; name: string; ifc_class: string; storey: string | null }[] }>( `/projects/${pid}/query?q=${encodeURIComponent(q)}&limit=${limit}`); } - /** W10-8: element phase/status distribution (new · existing · demolish · temporary · unset). */ - phasing(pid: string) { - return this.json<{ total: number; phased: number; prop: string; - counts: Record<"NEW" | "EXISTING" | "DEMOLISH" | "TEMPORARY" | "UNSET", number> }>( - `/projects/${pid}/phasing`); - } - /** W10-8: tag elements with a construction phase (new | existing | demolish | temporary). */ - setPhase(pid: string, guids: string[], phase: "new" | "existing" | "demolish" | "temporary", publish = true) { - return this.editIfc(pid, "set_phase", { guids, phase }, publish); - } /** Speckle interoperability bridge status (open-source, self-hostable; off unless configured). */ speckleStatus() { return this.json<{ enabled: boolean; connected: boolean; server: string | null; server_name?: string; @@ -644,7 +624,7 @@ export class ApiClient extends withAnnotate(withCreDeal(withClientPortal(withRes // 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.** - // 80 methods still sit ABOVE this line — `disciplineTree`, `classify`, `specManual`, `editUndo`, + // 76 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. @@ -699,6 +679,10 @@ export class ApiClient extends withAnnotate(withCreDeal(withClientPortal(withRes // route-prefix split could not see. `setPhase` did NOT come despite completing the matrix's // `lifecycle` category: its read half `phasing()` is still here. Reasoning in `model.ts`'s header. // + // (95) took element state — `lodSummary`/`setLod` and `phasing`/`setPhase` — to `model.ts`, + // leaving 76. Both pairs move together, which is what (94)'s objection to taking `setPhase` alone + // required. Reasoning in `model.ts`'s header. + // // 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 e3a45f4b..365bce0a 100644 --- a/apps/web/src/api/model.ts +++ b/apps/web/src/api/model.ts @@ -42,6 +42,33 @@ * field-verified dimension with its variance against design. Both are ㊻'s own question — *is this * element installed as designed?* — and neither was named in its header. * + * **SCALE-SEAM (95) adds element STATE — *what state are the model's elements in, and set it?*** + * Two read/write pairs: `lodSummary`/`setLod` (element maturity 100→500) and `phasing`/`setPhase` + * (new / existing / demolish / temporary). + * + * *`lodSummary` was a sibling separated from its own family:* this file already held + * `/model/lod/census`, `/lod/handover-readiness` and `/lod/assessment`, while the BASE distribution + * `/projects/{pid}/lod` stayed behind. The two pairs come together because they are the same + * question in the same shape — both return `{ total, ed, prop, counts }`, both writers are + * `(pid, guids, , publish) → editIfc`, both readers are consumed by + * `viewer/tools/modelStatePanels.ts`, and both writers sit unwired and adjacent on + * `api/clientCallers.test.ts`'s UNCALLED allowlist. + * + * **`authoring_matrix.py` disagrees, and it is worth saying why it loses.** It 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 property sets, same + * question. **That is (89)'s "storage is a HOW" trap**: "they write different psets" has the same + * shape as "they are all module records", and neither is a question. + * + * *This also resolves what (94) deliberately left open.* 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 and the objection is met + * rather than overridden. + * + * *Not contiguous — the pairs sat at 271–279 and 293–301 with `ensureContexts` and `queryElements` + * between them. (88) recorded that as the strongest case for grouping by what methods ANSWER, since + * no prefix or positional split would ever find them together.* + * * **Two known members, not necessarily all of them.** This slice does not claim the question is now * complete: it claims these two answer it and were missed. *The first draft said "finishes that * question", which asserts a completeness nothing here established — and the PR description @@ -771,5 +798,25 @@ export function withModel>(Base: TBase) { verifyAsbuilt(pid: string, guids: string[], opts: { verified_by?: string; method?: string; note?: string } = {}, publish = true) { return this.editIfc(pid, "verify_asbuilt", { guids, ...opts }, publish); } + /** W11 F0: element LOD-stage distribution (100/200/300/350/400/500/unset). */ + lodSummary(pid: string) { + return this.json<{ total: number; staged: number; prop: string; + counts: Record<"100" | "200" | "300" | "350" | "400" | "500" | "UNSET", number> }>( + `/projects/${pid}/lod`); + } + /** W11 F0: tag elements with a LOD stage (element maturity 100→500). */ + setLod(pid: string, guids: string[], stage: "100" | "200" | "300" | "350" | "400" | "500", publish = true) { + return this.editIfc(pid, "set_lod", { guids, stage }, publish); + } + /** W10-8: element phase/status distribution (new · existing · demolish · temporary · unset). */ + phasing(pid: string) { + return this.json<{ total: number; phased: number; prop: string; + counts: Record<"NEW" | "EXISTING" | "DEMOLISH" | "TEMPORARY" | "UNSET", number> }>( + `/projects/${pid}/phasing`); + } + /** W10-8: tag elements with a construction phase (new | existing | demolish | temporary). */ + setPhase(pid: string, guids: string[], phase: "new" | "existing" | "demolish" | "temporary", publish = true) { + return this.editIfc(pid, "set_phase", { guids, phase }, publish); + } }; } diff --git a/apps/web/src/api/surface.test.ts b/apps/web/src/api/surface.test.ts index 7ba8f4f5..3fb23cde 100644 --- a/apps/web/src/api/surface.test.ts +++ b/apps/web/src/api/surface.test.ts @@ -239,7 +239,11 @@ describe("the API client's public surface", () => { // and the count would not notice. "connectMep", "addMepFitting", // (94) two members of ㊻'s verification question that it did not name -> model.ts. + // (95) element state -> model.ts: two read/write pairs, both writers UNWIRED and on the + // UNCALLED allowlist. Named here because that allowlist is about CALL SITES and this list is + // about the SURFACE — an unwired writer can still vanish in an extraction unnoticed. "verifyAsbuilt", "recordAsbuiltDimension", + "lodSummary", "setLod", "phasing", "setPhase", ]) { 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 1899cd68..6a691c0e 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)–(94) took forty-six of those 126 — 80 remain, and there is STILL no map.** A new + **(88)–(95) took fifty of those 126 — 76 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`, @@ -3243,6 +3243,22 @@ verbs, with a command bar as the escape hatch to everything); and **role-shaped also unmovable then, for the `editIfc` typing reason (92) diagnosed — **three** slices now found to have left work behind for that single cause. + **(95) took element state to the same file** — `lodSummary`/`setLod` and `phasing`/`setPhase`, two + read/write pairs answering *what state are the model's elements in, and set it.* The shape is the + argument: both readers return `{ total, ed, prop, counts }`, both writers are + `(pid, guids, , publish) → editIfc`, both readers feed + `apps/web/src/viewer/tools/modelStatePanels.ts`, and both writers sit unwired and adjacent on the + UNCALLED allowlist. *`lodSummary` was a sibling separated from its own family:* `model.ts` already + held `/model/lod/census`, `/lod/handover-readiness` and `/lod/assessment`. + + **`authoring_matrix.py` argued against it, for the first time in four slices.** It files `set_lod` + under `data` and `set_phase` under `lifecycle` — because it categorises by the IFC OUTPUT a recipe + writes, an LOD stage tag against `Massing_Phasing.Status`. Different psets, same question, and + **that is (89)'s "storage is a HOW" trap** wearing new clothes. Recorded as a losing vote rather + than left unmentioned, because a source that has been right three times is exactly the one whose + disagreement is tempting to skip. *It also meets (94)'s objection instead of overriding it: both + halves of the phasing pair move together, so nothing is stranded.* + *This entry said "(94) finished SCALE-SEAM ㊻" until review, and the distinction against (93) is the point rather than a nicety. **⑲ NAMED the two it left** — `mep.ts`'s header says `connectMep` and `addMepFitting` by name — so taking both completes an explicit list, and "finished" is diff --git a/services/api/test_file_sizes.py b/services/api/test_file_sizes.py index 567232c5..fd3c0870 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": 727, # 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": 711, # 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 From 121c09560fd524b3f582c50a7ee367ebfa066e24 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 4 Sep 2026 04:35:20 +0000 Subject: [PATCH 02/12] =?UTF-8?q?SCALE-SEAM=20(96)=20=E2=80=94=20the=20as-?= =?UTF-8?q?built=20question's=20aggregate=20reader,=20and=20a=20witness=20?= =?UTF-8?q?that=20actually=20bounds?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Moves `lod500`, `setManufacturerInfo` and `attachOmDocument` out of `client.ts` into `api/model.ts`, rejoining `verifyAsbuilt` and `recordAsbuiltDimension` which (94) moved. `client.ts` goes 711 -> 698, 73 methods above the STAYING banner. TWO BOUNDING WITNESSES, derived independently, agreeing: - `openAsBuiltPanel` in `viewer/tools/modelStatePanels.ts` calls exactly five API methods — read off that function's brace closure rather than grepped for, so it is the closure of a scope and not a sample. Two of the five were already in `model.ts`. - The reader's own response type names its writer set field by field: `verified`/`by_method` from `verify_asbuilt`; `with_dimensions`/`dimensions_out_of_tolerance` from `record_asbuilt_dimension`; `with_manufacturer`/`with_serial` from `set_manufacturer_info`; `with_om_docs`/`om_documents` from `attach_om_document`. The backend route says it in prose: "Stamp elements with the `verify_asbuilt` recipe." A reader whose response type enumerates its writers is a DERIVED population. After eight slices of sampling, that is the first grouping witness here that bounds a set instead of illustrating one. WHAT CORROBORATES IS NOT WHAT BOUNDS. `test_lod500.py` reaches exactly three recipes — `attach_om_document`, `set_manufacturer_info`, `verify_asbuilt` — and OMITS `record_asbuilt_dimension`, which is unambiguously in this family. It agrees with the answer without being able to establish it. Three slices claimed "and no others" off a test file and were wrong all three times. NOT CLAIMED, and said in the header, the pin, the changelog and the roadmap rather than only in review: `attachDocument` stays in `client.ts`, takes a `purpose` parameter, and `asbuilt_summary` counts ANY purpose-tagged document reference — so "every writer of `with_om_docs` moves here" is false. The field map is of the recipes each field was designed around, not of everything that can set it. Two sources disagree and lose for the same reason: `attach_om_document` is a purpose-tagged wrapper of `detailing.attach_document`, and `authoring_matrix.py` files it and `set_manufacturer_info` under `data`. The first is a shared HELPER, the second a STORAGE bucket — the groupings (89) and (90) each had to reject. The matrix is the losing vote twice running after being right three times. Also fixes the extraction helper: it terminated its brace count on the method signature line, so a signature wrapping across two lines with no opening brace on the first read as a 3-line method. `attachOmDocument` is 6. Verified: tsc 0, lint 0, `vitest run src/api` 27 files / 119 tests, build 0, ruff (the CI command, from `services/api`) 0, and `test_file_sizes.py`, `test_claude_md_gates.py`, `test_roadmap_status.py`, `test_ruff_scope.py`, `test_reachable.py` all 0. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Tt2XKB83wwNt2nrMbK6eEA --- CHANGELOG.md | 52 +++++++++++++++++++++++++++++++ apps/web/src/api/client.ts | 23 +++----------- apps/web/src/api/model.ts | 53 ++++++++++++++++++++++++++++++++ apps/web/src/api/surface.test.ts | 3 ++ docs/roadmap.md | 41 +++++++++++++++++++++++- services/api/test_file_sizes.py | 2 +- 6 files changed, 154 insertions(+), 20 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 6f2b4bb9..8f04f623 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1185,6 +1185,58 @@ 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-fifth follow-on on the same version: **SCALE-SEAM (96)** — *the as-built question's +aggregate reader, and the first witness in this sequence that actually bounds a set*. + +Three methods out of `client.ts` (`711 → 698`) into the existing `apps/web/src/api/model.ts`: +`lod500`, `setManufacturerInfo` and `attachOmDocument`, rejoining `verifyAsbuilt` and +`recordAsbuiltDimension` which (94) moved. No new mixin. **What they answer: is this element +installed as designed, and is it documented for turnover.** + +### Two bounding witnesses, and they agree + +`openAsBuiltPanel` in `apps/web/src/viewer/tools/modelStatePanels.ts` calls exactly five API +methods — read off that function's brace closure rather than grepped for, so it is the closure of +a scope and not a sample. Two of the five were already in `model.ts`. + +Independently, the reader's own response type names its writer set field by field: +`verified`/`by_method` ← `verify_asbuilt`; `with_dimensions`/`dimensions_out_of_tolerance` ← +`record_asbuilt_dimension`; `with_manufacturer`/`with_serial` ← `set_manufacturer_info`; +`with_om_docs`/`om_documents` ← `attach_om_document`. The backend route says it in prose: +*"Stamp elements with the `verify_asbuilt` recipe."* + +**A reader whose response type enumerates its writers is a DERIVED population.** Eight slices in, +that is the first grouping witness here that bounds a set rather than sampling one. + +### What corroborates is not what bounds + +`services/api/test_lod500.py` reaches exactly three recipes — `attach_om_document`, +`set_manufacturer_info`, `verify_asbuilt` — and **omits `record_asbuilt_dimension`**, which is +unambiguously in this family. So it agrees with the answer without being able to establish it. A +witness that misses a known member cannot bound anything, however exactly its members match. +*Three slices claimed "and no others" off a test file and were wrong all three times; the fix is +not to read the test harder, it is to ask which question the test can answer.* + +### What is NOT claimed + +`attachDocument` stays in `client.ts`, takes a `purpose` parameter, and `asbuilt_summary` counts +**any** purpose-tagged document reference. So *"every writer of `with_om_docs` moves here"* is +**false**. The field map above is of the recipes each field was designed around, not of everything +that can set it. The claim that survives is the bounded one: the five methods `openAsBuiltPanel` +calls. + +### Two sources disagree, and lose for the same reason + +`attach_om_document` is implemented as a purpose-tagged wrapper of `detailing.attach_document`, and +`authoring_matrix.py` files it and `set_manufacturer_info` under `data`. The first is a shared +HELPER, the second a STORAGE bucket — the two groupings (89) and (90) each had to reject. The +matrix is now the losing vote twice running after being right three times; *a corroborating source +that keeps winning is the one that stops getting checked.* + +`client.ts` is 73 methods above the STAYING banner and 4 below. Pin lowered with the file; the +three names added to `surface.test.ts`, whose floor carries enough slack that the count alone would +not notice a loss. + Thirty-fourth follow-on on the same version: **SCALE-SEAM (95)** — *element state, and a matrix disagreement worth stating rather than eliding*. diff --git a/apps/web/src/api/client.ts b/apps/web/src/api/client.ts index 2ff7c7cc..af04a9a8 100644 --- a/apps/web/src/api/client.ts +++ b/apps/web/src/api/client.ts @@ -143,12 +143,6 @@ export class ApiClient extends withAnnotate(withCreDeal(withClientPortal(withRes opts: { location?: string; identification?: string; description?: string; purpose?: string } = {}, publish = true) { return this.editIfc(pid, "attach_document", { guids, name, ...opts }, publish); } - /** G3: attach an O&M / warranty document reference (purpose-tagged) to elements — turnover paperwork - * bound to the physical asset; surfaced in the as-built summary's `with_om_docs`. */ - attachOmDocument(pid: string, guids: string[], name: string, - opts: { location?: string; kind?: "om" | "warranty" } = {}, publish = true) { - return this.editIfc(pid, "attach_om_document", { guids, name, ...opts }, publish); - } /** W11 B6: author a base plate + anchor bolts under a steel column (fabrication assembly). */ addBasePlate(pid: string, columnGuid: string, opts: { bolts?: number; width?: number; depth?: number } = {}, publish = true) { return this.editIfc(pid, "add_base_plate", { column_guid: columnGuid, ...opts }, publish); @@ -225,17 +219,6 @@ export class ApiClient extends withAnnotate(withCreDeal(withClientPortal(withRes return this.json<{ ok: boolean; errors: string[]; warnings: string[] }>( `/projects/${pid}/edit/precheck`, { method: "POST", body: JSON.stringify({ recipe, params }) }); } - /** W11 G1: LOD-500 readiness — share of the model field-verified as-built, by method. */ - lod500(pid: string) { - return this.json<{ total: number; verified: number; unverified: number; readiness_pct: number; - by_method: Record; methods: string[]; prop: string; - with_manufacturer: number; with_serial: number; with_dimensions: number; dimensions_out_of_tolerance: number; - with_om_docs?: number; om_documents?: string[] }>(`/projects/${pid}/lod500`); - } - /** W11 G3: stamp manufacturer / serial info (Pset_Manufacturer*) — the LOD-500 / O&M / turnover layer. */ - 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); - } /** W11 B6: author an IfcCurtainWall (mullions + transoms + glazing panels) along a line. */ addCurtainWall(pid: string, start: [number, number], end: [number, number], opts: { height?: number; cols?: number; rows?: number } = {}, publish = true) { @@ -624,7 +607,7 @@ export class ApiClient extends withAnnotate(withCreDeal(withClientPortal(withRes // 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.** - // 76 methods still sit ABOVE this line — `disciplineTree`, `classify`, `specManual`, `editUndo`, + // 73 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. @@ -683,6 +666,10 @@ export class ApiClient extends withAnnotate(withCreDeal(withClientPortal(withRes // leaving 76. Both pairs move together, which is what (94)'s objection to taking `setPhase` alone // required. Reasoning in `model.ts`'s header. // + // (96) took as-built/turnover — `lod500`, `setManufacturerInfo`, `attachOmDocument` — to + // `model.ts`, leaving 73. `lod500` is the AGGREGATE READER of the question whose writers (94) + // already moved, and its response type names its own writer set field by field. + // // 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 365bce0a..5ded9222 100644 --- a/apps/web/src/api/model.ts +++ b/apps/web/src/api/model.ts @@ -100,6 +100,42 @@ * *A complete category is one vote, not a verdict — and "lifecycle" is a word (88) already caught * misleading once.* * + * **SCALE-SEAM (96) finishes the as-built/turnover question by bringing its AGGREGATE READER and + * the two writers that fed it:** `lod500` (LOD-500 readiness), `setManufacturerInfo` + * (`Pset_Manufacturer*`) and `attachOmDocument` (purpose-tagged turnover paperwork). + * + * *Two BOUNDING witnesses, derived rather than enumerated, and they agree.* First: + * `openAsBuiltPanel` in `viewer/tools/modelStatePanels.ts` calls exactly five API methods — read + * off that function's brace closure, not grepped for — and two of the five are `verifyAsbuilt` + * and `recordAsbuiltDimension`, which (94) already moved. Second: the reader's own response type + * names its writer set FIELD BY FIELD — `verified`/`by_method` from `verify_asbuilt`, + * `with_dimensions`/`dimensions_out_of_tolerance` from `record_asbuilt_dimension`, + * `with_manufacturer`/`with_serial` from `set_manufacturer_info`, `with_om_docs`/`om_documents` + * from `attach_om_document`. The backend route says so out loud: *"Stamp elements with the + * `verify_asbuilt` recipe."* **A reader whose response type enumerates its writers IS a derived + * population** — the first witness in this sequence that bounds a set instead of sampling it. + * + * *`test_lod500.py` CORROBORATES but does NOT bound, and the difference is the whole lesson of + * (91)–(93).* Derived: it reaches exactly three recipes — `attach_om_document`, + * `set_manufacturer_info`, `verify_asbuilt` — and OMITS `record_asbuilt_dimension`, which is + * unambiguously in this family. A witness that misses a known member cannot establish a boundary, + * however exactly its members match. **Three slices claimed "and no others" off a test file and + * were wrong all three times**; the fix is not to look harder at the test, it is to notice which + * question the test can answer. + * + * **What this slice does NOT claim.** `attachDocument` — still in `client.ts` — takes a `purpose` + * parameter, and `asbuilt_summary` counts ANY purpose-tagged document reference. So *"every writer + * of `with_om_docs` moves here"* is **false**, and the field-by-field map above is a map of the + * recipes each field was DESIGNED around, not of everything that can set it. The claim that + * survives is the bounded one: these are the five methods `openAsBuiltPanel` calls. + * + * **Two sources disagree, and both lose for the same reason.** `attach_om_document` is implemented + * as a purpose-tagged wrapper of `detailing.attach_document` (`edit.py`), and `authoring_matrix.py` + * files it and `set_manufacturer_info` under `data`. The first is a shared HELPER and the second a + * STORAGE bucket — the two groupings (89) and (90) each had to reject. *The matrix is now the + * losing vote twice running, after being right three times. A corroborating source that keeps + * winning is exactly the one that stops being checked.* + * * SCALE-SEAM ⓭ adds E57 scan ingest — *can we bring this scan in?* Status plus convert. * Admin audit/error stayed. * @@ -818,5 +854,22 @@ export function withModel>(Base: TBase) { setPhase(pid: string, guids: string[], phase: "new" | "existing" | "demolish" | "temporary", publish = true) { return this.editIfc(pid, "set_phase", { guids, phase }, publish); } + /** G3: attach an O&M / warranty document reference (purpose-tagged) to elements — turnover paperwork + * bound to the physical asset; surfaced in the as-built summary's `with_om_docs`. */ + attachOmDocument(pid: string, guids: string[], name: string, + opts: { location?: string; kind?: "om" | "warranty" } = {}, publish = true) { + return this.editIfc(pid, "attach_om_document", { guids, name, ...opts }, publish); + } + /** W11 G1: LOD-500 readiness — share of the model field-verified as-built, by method. */ + lod500(pid: string) { + return this.json<{ total: number; verified: number; unverified: number; readiness_pct: number; + by_method: Record; methods: string[]; prop: string; + with_manufacturer: number; with_serial: number; with_dimensions: number; dimensions_out_of_tolerance: number; + with_om_docs?: number; om_documents?: string[] }>(`/projects/${pid}/lod500`); + } + /** W11 G3: stamp manufacturer / serial info (Pset_Manufacturer*) — the LOD-500 / O&M / turnover layer. */ + 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); + } }; } diff --git a/apps/web/src/api/surface.test.ts b/apps/web/src/api/surface.test.ts index 3fb23cde..84300b38 100644 --- a/apps/web/src/api/surface.test.ts +++ b/apps/web/src/api/surface.test.ts @@ -244,6 +244,9 @@ describe("the API client's public surface", () => { // about the SURFACE — an unwired writer can still vanish in an extraction unnoticed. "verifyAsbuilt", "recordAsbuiltDimension", "lodSummary", "setLod", "phasing", "setPhase", + // (96) the as-built/turnover reader + its two remaining writers -> model.ts. `lod500` has a + // LIVE call site (openAsBuiltPanel), so losing it would break the panel, not just the surface. + "lod500", "setManufacturerInfo", "attachOmDocument", ]) { 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 6a691c0e..c345f348 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)–(95) took fifty of those 126 — 76 remain, and there is STILL no map.** A new + **(88)–(96) took fifty-three of those 126 — 73 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`, @@ -3277,6 +3277,45 @@ verbs, with a command bar as the escape hatch to everything); and **role-shaped alone would repeat the reader/rollup 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. + **(96) finished the as-built/turnover question by taking its AGGREGATE READER** — `lod500`, plus + the two writers still feeding it, `setManufacturerInfo` and `attachOmDocument`. They rejoin + `verifyAsbuilt` and `recordAsbuiltDimension`, which (94) moved and could only claim as "two known + members, not necessarily all". **This is the slice that can say more than that, and the reason is + worth more than the extraction.** + + *Two witnesses BOUND the set, and they were derived independently.* `openAsBuiltPanel` in + `apps/web/src/viewer/tools/modelStatePanels.ts` calls exactly five API methods — read off that + function's brace closure rather than grepped for, so it is the closure of a scope, not a sample. + Separately, the reader's own response type names its writer set field by field: + `verified`/`by_method` ← `verify_asbuilt`, `with_dimensions`/`dimensions_out_of_tolerance` ← + `record_asbuilt_dimension`, `with_manufacturer`/`with_serial` ← `set_manufacturer_info`, + `with_om_docs`/`om_documents` ← `attach_om_document`; and the backend route says it in prose — + *"Stamp elements with the `verify_asbuilt` recipe."* **A reader whose response type enumerates its + writers is a derived population**, and after eight slices of sampling, that is the first grouping + witness here that bounds a set instead of illustrating one. + + *What CORROBORATES is not what BOUNDS.* `services/api/test_lod500.py` reaches exactly three + recipes — `attach_om_document`, `set_manufacturer_info`, `verify_asbuilt` — and **omits + `record_asbuilt_dimension`**, which is unambiguously in this family. It agrees with the answer + without being able to establish it. **A witness that misses a known member cannot bound anything**, + however exactly its members match. Three slices claimed "and no others" off a test file and were + wrong all three times; the fix is not to read the test harder, it is to ask which question the + test is able to answer at all. + + **And what this slice does NOT claim, stated where a later reader will see it.** + `attachDocument` stays in `client.ts`, takes a `purpose` parameter, and `asbuilt_summary` counts + **any** purpose-tagged document reference — so *"every writer of `with_om_docs` moves here"* is + false. The field map is of the recipes each field was designed around, not of everything that can + set it. *(94) hedged in its PR while its artifact overstated; the caveat belongs in both, which is + why it is in the header, the pin, the changelog and here.* + + *Two sources disagree and lose for the same reason:* `attach_om_document` is implemented as a + purpose-tagged wrapper of `detailing.attach_document`, and `authoring_matrix.py` files it and + `set_manufacturer_info` under `data`. The first is a shared HELPER, the second a STORAGE bucket — + the groupings (89) and (90) each had to reject. **The matrix is now the losing vote twice running + after being right three times**, which is the interesting part: a corroborating source that keeps + winning is the one that quietly stops getting checked. + **(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 fd3c0870..de373239 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": 711, # 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": 698, # 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 From 0472f974d094ac66c1f985f9c9156d715312cab6 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 4 Sep 2026 05:08:56 +0000 Subject: [PATCH 03/12] =?UTF-8?q?SCALE-SEAM=20(97)=20=E2=80=94=20the=20und?= =?UTF-8?q?o=20stack,=20and=20a=20destination=20that=20looked=20right=20an?= =?UTF-8?q?d=20was=20not?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Moves `editHistory`, `editUndo` and `editRedo` out of `client.ts` into `api/authoring.ts`. `client.ts` goes 698 -> 687, 70 methods above the STAYING banner. WHY THAT MIXIN: `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 that stack, and `edit_history.state()` reads its depths. One stack, and the operation that fills it was already in this file. The types agree: both writers return `{restored, state: {can_undo, can_redo}}`, and `state` is `editHistory`'s own return type minus the depths — the writers hand back the reader's answer. That is a type-level relation, not the shared `/edit/` prefix. The prefix is real and is deliberately not the argument, since a route prefix is exactly what the verification slice was caught grouping on. A HYPOTHESIS TESTED AND WITHDRAWN, which is the part worth keeping. "Undo restores the prior model version" makes `model.ts` the obvious home — it owns `modelVersions`, `versionDiff`, `versionCostDelta`. It is the wrong home: those read `/projects/{pid}/versions` out of `bim.py`, while undo pops a DIFFERENT stack, the `edit_history` sidecar, which `recipe_log.py` describes as a list of file paths with "No recipe, no parameters, no actor". Two stacks, one word — and the word is what made the wrong answer look obvious. Second withdrawal of a plausible destination after checking it, after (93) withdrew (92)'s `HttpCore` forecast. THE BOUND IS WEAKER THAN (96)'s AND IS STATED THAT WAY. `app.ts`'s S4 block wires `refreshUndo` (calling only `editHistory`) and `doUndoRedo` (calling only `editUndo`/`editRedo`), so the union is exactly these three — but that unit is a block delimited by reading, not a closure the braces define. It corroborates; it does not bound. Not every set has a witness as strong as the last one's, and promoting a block to a closure would be this sequence's own recurring defect. Verified: tsc 0, lint 0, `vitest run src/api` 27 files / 119 tests, build 0, ruff (the CI command, from `services/api`) 0, and `test_file_sizes.py`, `test_claude_md_gates.py`, `test_roadmap_status.py` all 0. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Tt2XKB83wwNt2nrMbK6eEA --- CHANGELOG.md | 43 ++++++++++++++++++++++++++++++++ apps/web/src/api/authoring.ts | 41 ++++++++++++++++++++++++++++++ apps/web/src/api/client.ts | 21 ++++------------ apps/web/src/api/surface.test.ts | 3 +++ docs/roadmap.md | 26 ++++++++++++++++++- services/api/test_file_sizes.py | 2 +- 6 files changed, 118 insertions(+), 18 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 8f04f623..f083e940 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1185,6 +1185,49 @@ 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-sixth follow-on on the same version: **SCALE-SEAM (97)** — *the undo stack, and a +destination that looked right and was not*. + +Three methods out of `client.ts` (`698 → 687`) into the existing `apps/web/src/api/authoring.ts`: +`editHistory`, `editUndo`, `editRedo`. No new mixin. **What they answer: what has been done to this +model, and can I take it back.** + +### `editIfc` is the push they pop + +They belong with `editIfc` — already in that mixin — because `authoring.py` records the pre-edit +version on every `/edit` call *"so this edit can be undone"*, `_restore_version` pops that stack, +and `edit_history.state()` reads its depths. One stack; the operation that fills it was already +here. + +The types agree: both writers return `{ restored, state: { can_undo, can_redo } }`, and `state` is +`editHistory`'s own return type minus the depths — **the writers hand back the reader's answer.** +That is a type-level relation, not a shared `/edit/` prefix. The prefix is real, but a route prefix +is exactly what ㊻ was caught grouping on, so it corroborates and does not decide. + +### A hypothesis tested and withdrawn + +*"Undo restores the prior model version"* makes `model.ts` the obvious home — it owns +`modelVersions`, `versionDiff`, `versionCostDelta`. **It is the wrong home.** Those read +`/projects/{pid}/versions` out of `bim.py`; undo pops a *different* stack, the `edit_history` +sidecar, which `recipe_log.py` describes as a list of file paths with *"No recipe, no parameters, +no actor"*. Two stacks, one word. + +This is the second time a plausible destination has had to be withdrawn after checking it — (93) +withdrew (92)'s forecast about moving `editIfc` into `HttpCore`. **A likely-looking home is a +hypothesis to check against the backend, not an instruction to carry out.** + +### The bound is weaker than (96)'s, and is stated that way + +`app.ts`'s S4 block wires `refreshUndo` (calling only `editHistory`) and `doUndoRedo` (calling only +`editUndo`/`editRedo`), so the union is exactly these three. But unlike (96)'s `openAsBuiltPanel`, +that unit is a block delimited by reading rather than a closure the braces define — so it is +recorded as corroboration, not as a boundary. *Not every set has a witness as strong as the last +one's, and inflating a block into a closure would be the same defect this sequence keeps finding.* + +`client.ts` is 70 methods above the STAYING banner and 4 below. Pin lowered with the file; the three +names added to `surface.test.ts` — all three have live call sites, so a drop breaks the undo/redo +buttons rather than only the count. + Thirty-fifth follow-on on the same version: **SCALE-SEAM (96)** — *the as-built question's aggregate reader, and the first witness in this sequence that actually bounds a set*. diff --git a/apps/web/src/api/authoring.ts b/apps/web/src/api/authoring.ts index 2fdf25bb..07dba6a3 100644 --- a/apps/web/src/api/authoring.ts +++ b/apps/web/src/api/authoring.ts @@ -17,6 +17,32 @@ * SCALE-SEAM ⓼ adds groups and assemblies — *how are these elements grouped?* * List, inspector, create group/assembly, parametric array. Detailing stayed. * + * **SCALE-SEAM (97) adds the UNDO STACK — *what has been done to this model, and can I take it + * back?*** `editHistory` (can_undo/can_redo + depths), `editUndo` and `editRedo`. They belong in + * THIS file because `editIfc` — already here — 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 + * that stack, and `edit_history.state()` reads its depths. One stack, and the operation that fills + * it was already in this mixin. + * + * *The writers hand back the reader's answer:* both return `{ restored, state: { can_undo, + * can_redo } }`, and `state` is `editHistory`'s return type minus the depths. That is a type-level + * relation, not a shared `/edit/` prefix — the prefix is real here but is exactly the grouping ㊻ + * was caught using, so it corroborates and does not decide. + * + * **A hypothesis TESTED AND WITHDRAWN, because it looked right.** "Undo restores the prior model + * version" makes `model.ts` the obvious home — it owns `modelVersions`, `versionDiff` and + * `versionCostDelta`. It is the wrong home: those read `/projects/{pid}/versions` out of `bim.py`, + * while undo pops a **different stack** in the `edit_history` sidecar (a list of file paths, per + * `recipe_log.py`: *"No recipe, no parameters, no actor"*). Two stacks, one word. *(93) had to + * withdraw a forecast the same way; a plausible destination is a hypothesis to check against the + * backend, not an instruction to carry out.* + * + * *Bounded by a UI unit rather than a function, and that is weaker on purpose:* `app.ts`'s S4 + * undo/redo block wires `refreshUndo` (calling only `editHistory`) and `doUndoRedo` (calling only + * `editUndo`/`editRedo`), so the union is exactly these three. Unlike (96)'s `openAsBuiltPanel`, + * the unit is a block delimited by reading, not a closure the braces define — so it is stated as + * corroboration, not as a boundary. + * * First extraction of roadmap SCALE-SEAM. `client.ts` was measured at 4,956 lines with 152 commits * in a fortnight and 631 methods on one class: it had to be opened to add any endpoint, so every * change to it competed with every other change. The server solved this long ago by splitting into @@ -337,6 +363,21 @@ export function withAuthoring>(Base: TBase) { arrayElement(pid: string, guid: string, nx: number, ny: number, dx: number, dy: number, dz = 0, publish = true) { return this.editIfc(pid, "array_element", { guid, nx, ny, dx, dy, dz }, publish); } + /** S4: whether the model can be undone / redone + stack depths. */ + editHistory(pid: string) { + return this.json<{ can_undo: boolean; can_redo: boolean; undo_depth: number; redo_depth: number }>( + `/projects/${pid}/edit/history`); + } + /** S4: undo the last authoring edit (restore the prior model version + republish). */ + editUndo(pid: string, publish = true) { + return this.json<{ restored: string; state: { can_undo: boolean; can_redo: boolean } }>( + `/projects/${pid}/edit/undo`, { method: "POST", body: JSON.stringify({ publish }) }); + } + /** S4: redo an undone edit. */ + editRedo(pid: string, publish = true) { + return this.json<{ restored: string; state: { can_undo: boolean; can_redo: boolean } }>( + `/projects/${pid}/edit/redo`, { method: "POST", body: JSON.stringify({ publish }) }); + } }; } diff --git a/apps/web/src/api/client.ts b/apps/web/src/api/client.ts index af04a9a8..9b38ddaa 100644 --- a/apps/web/src/api/client.ts +++ b/apps/web/src/api/client.ts @@ -161,21 +161,6 @@ export class ApiClient extends withAnnotate(withCreDeal(withClientPortal(withRes specManual(pid: string) { return this.json(`/projects/${pid}/spec/manual`); } - /** S4: whether the model can be undone / redone + stack depths. */ - editHistory(pid: string) { - return this.json<{ can_undo: boolean; can_redo: boolean; undo_depth: number; redo_depth: number }>( - `/projects/${pid}/edit/history`); - } - /** S4: undo the last authoring edit (restore the prior model version + republish). */ - editUndo(pid: string, publish = true) { - return this.json<{ restored: string; state: { can_undo: boolean; can_redo: boolean } }>( - `/projects/${pid}/edit/undo`, { method: "POST", body: JSON.stringify({ publish }) }); - } - /** S4: redo an undone edit. */ - editRedo(pid: string, publish = true) { - return this.json<{ restored: string; state: { can_undo: boolean; can_redo: boolean } }>( - `/projects/${pid}/edit/redo`, { method: "POST", body: JSON.stringify({ publish }) }); - } /** B3: give a wall a sloped top (start_height → end_height) for parapet/shed/gable walls. */ setWallSlope(pid: string, guid: string, startHeight: number, endHeight: number, publish = true) { return this.editIfc(pid, "set_wall_slope", { guid, start_height: startHeight, end_height: endHeight }, publish); @@ -607,7 +592,7 @@ export class ApiClient extends withAnnotate(withCreDeal(withClientPortal(withRes // 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.** - // 73 methods still sit ABOVE this line — `disciplineTree`, `classify`, `specManual`, `editUndo`, + // 70 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. @@ -670,6 +655,10 @@ export class ApiClient extends withAnnotate(withCreDeal(withClientPortal(withRes // `model.ts`, leaving 73. `lod500` is the AGGREGATE READER of the question whose writers (94) // already moved, and its response type names its own writer set field by field. // + // (97) took the UNDO STACK — `editHistory`/`editUndo`/`editRedo` — to `authoring.ts`, leaving + // 70. `editIfc`, already there, is the PUSH they pop. `model.ts` looked right and is not: its + // `modelVersions` reads a DIFFERENT stack. Reasoning in `authoring.ts`'s header. + // // 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/surface.test.ts b/apps/web/src/api/surface.test.ts index 84300b38..a3ff85db 100644 --- a/apps/web/src/api/surface.test.ts +++ b/apps/web/src/api/surface.test.ts @@ -247,6 +247,9 @@ describe("the API client's public surface", () => { // (96) the as-built/turnover reader + its two remaining writers -> model.ts. `lod500` has a // LIVE call site (openAsBuiltPanel), so losing it would break the panel, not just the surface. "lod500", "setManufacturerInfo", "attachOmDocument", + // (97) the undo stack -> authoring.ts. All three have LIVE call sites in app.ts's S4 block, + // so a drop here breaks the undo/redo buttons, not just the surface count. + "editHistory", "editUndo", "editRedo", ]) { 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 c345f348..c2bca22a 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)–(96) took fifty-three of those 126 — 73 remain, and there is STILL no map.** A new + **(88)–(97) took fifty-six of those 126 — 70 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`, @@ -3316,6 +3316,30 @@ verbs, with a command bar as the escape hatch to everything); and **role-shaped after being right three times**, which is the interesting part: a corroborating source that keeps winning is the one that quietly stops getting checked. + **(97) took the UNDO STACK to `apps/web/src/api/authoring.ts`** — `editHistory`, `editUndo`, + `editRedo`, answering *what has been done to this model, and can I take it back?* They go to that + mixin because **`editIfc`, already in it, 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 + that stack, and `edit_history.state()` reads its depths. The types agree — both writers return + `{ restored, state: { can_undo, can_redo } }`, and `state` is the reader's own type minus the + depths, so **the writers hand back the reader's answer**. The shared `/edit/` prefix is real and + is deliberately NOT the argument; a route prefix is what ㊻ was caught grouping on. + + **A hypothesis tested and withdrawn, which is the part worth keeping.** *"Undo restores the prior + model version"* makes `model.ts` the obvious destination — it owns `modelVersions`, `versionDiff` + and `versionCostDelta`. It is wrong: those read `/projects/{pid}/versions` out of `bim.py`, while + undo pops a **different stack**, the `edit_history` sidecar, which `recipe_log.py` describes as a + list of file paths with *"No recipe, no parameters, no actor"*. Two stacks, one word — and the + word is what made the wrong answer look obvious. Second withdrawal of a plausible destination + after checking it, following (93)'s of (92)'s `HttpCore` forecast: **a likely home is a hypothesis + to check against the backend, not an instruction to execute.** + + *And the bound here is weaker than (96)'s, recorded as such.* `app.ts`'s S4 block wires + `refreshUndo` (only `editHistory`) and `doUndoRedo` (only `editUndo`/`editRedo`), so the union is + exactly these three — but that unit is a block delimited by reading, not a closure the braces + define. It corroborates; it does not bound. **Not every set has a witness as strong as the last + one's, and promoting a block to a closure would be this sequence's own recurring defect.** + **(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 de373239..a31e2419 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": 698, # 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": 687, # 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 From 58525e1ce363f472c5252a354cd41856ee87d690 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 4 Sep 2026 05:16:29 +0000 Subject: [PATCH 04/12] =?UTF-8?q?Correct=20the=20undo/redo=20republish=20d?= =?UTF-8?q?ocs=20=E2=80=94=20all=20three=20sites,=20not=20just=20the=20fla?= =?UTF-8?q?gged=20one?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit CodeRabbit flagged `editUndo`'s docstring on #414: it says "restore the prior model version + republish" unconditionally, but `publish` defaults to true and can be false. Verified against the backend — `_restore_version` guards the republish with `if publish:` — so the claim is wrong whenever a caller passes `publish: false`. Grepping every site of that wording found the same unconditional claim in THREE live places, not one: - `apps/web/src/api/authoring.ts` — `editUndo` (the flagged one) - `services/api/src/aec_api/routers/authoring.py` — the `/edit/undo` route - `services/api/src/aec_api/routers/authoring.py` — the `/edit/redo` route All three now say republishing happens only when `publish`. The remaining hits are UI button labels, where the call site never passes the flag so republish really is unconditional, and historical CHANGELOG entries; both are correct as written and are left alone. Also fixes the same defect's other half in the same five lines: the declared return type omitted `publish`, which the backend adds as `"running"` when it republishes. Correcting the prose while leaving the type silent about the same conditional would be the half-applied fix this sequence has twice been caught making. Verified: tsc 0, lint 0, `vitest run src/api` 27 files / 119 tests, build 0, ruff (the CI command, from `services/api`) 0, `test_file_sizes.py` 0. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Tt2XKB83wwNt2nrMbK6eEA --- apps/web/src/api/authoring.ts | 12 ++++++++---- services/api/src/aec_api/routers/authoring.py | 6 ++++-- 2 files changed, 12 insertions(+), 6 deletions(-) diff --git a/apps/web/src/api/authoring.ts b/apps/web/src/api/authoring.ts index 07dba6a3..d006e346 100644 --- a/apps/web/src/api/authoring.ts +++ b/apps/web/src/api/authoring.ts @@ -368,14 +368,18 @@ export function withAuthoring>(Base: TBase) { return this.json<{ can_undo: boolean; can_redo: boolean; undo_depth: number; redo_depth: number }>( `/projects/${pid}/edit/history`); } - /** S4: undo the last authoring edit (restore the prior model version + republish). */ + /** S4: undo the last authoring edit — restore the prior model version, and republish only when + * `publish` (the default). With `publish: false` the source IFC is swapped and no publish runs, + * so `publish` is absent from the response. */ editUndo(pid: string, publish = true) { - return this.json<{ restored: string; state: { can_undo: boolean; can_redo: boolean } }>( + return this.json<{ restored: string; state: { can_undo: boolean; can_redo: boolean }; + publish?: string }>( `/projects/${pid}/edit/undo`, { method: "POST", body: JSON.stringify({ publish }) }); } - /** S4: redo an undone edit. */ + /** S4: redo an undone edit — same `publish` semantics as `editUndo`. */ editRedo(pid: string, publish = true) { - return this.json<{ restored: string; state: { can_undo: boolean; can_redo: boolean } }>( + return this.json<{ restored: string; state: { can_undo: boolean; can_redo: boolean }; + publish?: string }>( `/projects/${pid}/edit/redo`, { method: "POST", body: JSON.stringify({ publish }) }); } }; diff --git a/services/api/src/aec_api/routers/authoring.py b/services/api/src/aec_api/routers/authoring.py index 2f220d0a..9f196f6e 100644 --- a/services/api/src/aec_api/routers/authoring.py +++ b/services/api/src/aec_api/routers/authoring.py @@ -1059,7 +1059,8 @@ def _restore_version(pid: str, db: Session, actor: str, publish: bool, redo: boo @router.post("/projects/{pid}/edit/undo") def edit_undo(pid: str, publish: bool = Body(default=True, embed=True), db: Session = Depends(get_db), actor: str = Depends(require_role("editor"))): - """S4: **undo** the last authoring edit — restore the prior model version + republish. GUID-stable + """S4: **undo** the last authoring edit — restore the prior model version, republishing only when + `publish` (the default). GUID-stable (pins/RFIs/clashes keyed by GlobalId survive).""" return _restore_version(pid, db, actor, publish, redo=False) @@ -1067,7 +1068,8 @@ def edit_undo(pid: str, publish: bool = Body(default=True, embed=True), db: Sess @router.post("/projects/{pid}/edit/redo") def edit_redo(pid: str, publish: bool = Body(default=True, embed=True), db: Session = Depends(get_db), actor: str = Depends(require_role("editor"))): - """S4: **redo** an undone edit — restore the next model version + republish.""" + """S4: **redo** an undone edit — restore the next model version, republishing only when `publish` + (the default).""" return _restore_version(pid, db, actor, publish, redo=True) From 75f859796f4caec15fdb4aca76202e0ab92ab60f Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 4 Sep 2026 05:49:34 +0000 Subject: [PATCH 05/12] =?UTF-8?q?SCALE-SEAM=20(98)=20=E2=80=94=20detailing?= =?UTF-8?q?=20carriers,=20and=20a=20field=20map=20total=20over=20one=20mod?= =?UTF-8?q?ule=20but=20not=20the=20codebase?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Moves `elementDetailing`, `classify`, `applyDetailingRules`, `validateDetailing` and `attachDocument` out of `client.ts` into a new `api/detailing.ts`. `client.ts` goes 687 -> 665, 65 methods above the STAYING banner. WHAT THEY ANSWER: what informational carriers are attached to this element, write them, and which are missing? THE WITNESS IS A 1:1 AND TOTAL FIELD-TO-WRITER MAP, the shape (96) established. `element_detailing` walks `HasAssociations` and branches on exactly two relationship types, and `detailing.py` holds exactly two writers, one per response array: classifications[] <- classify (IfcRelAssociatesClassification) documents[] <- attachDocument (IfcRelAssociatesDocument) The map is read out of the reader's own body, not matched on names. The other two methods are those same writes automated and audited: `applyDetailingRules` runs the condition-to-content rule set and writes both carrier kinds, `validateDetailing` reports elements a rule applies to that lack the code. TOTAL OVER THE MODULE, NOT THE CODEBASE, and the difference is the claim. `attachOmDocument` — moved to `model.ts` in (96) — wraps the SAME `detailing.attach_document` and also lands in `documents[]`, so "these are all the writers of this reader's fields" is false. That overlap was recorded when it moved, which is why it was on hand to qualify this slice rather than being found in review. ADJACENCY AGREED WITH THE ANSWER AND IS NOT EVIDENCE FOR IT. These five were contiguous in `client.ts`; unlike (95), where non-contiguity was the whole argument, a positional split would have found this set too. Stated precisely because it looks like support. ALSO RECORDED: `api.classify()` has no call site — `detailingSection.ts` drives the recipe through the generic `authorAndReload` path, bypassing the typed method, and `clientCallers.test.ts` counts it reached because it matches bare string literals as well as calls. That looseness is deliberate per that file's own docstring, so it is a limit of the gate rather than a defect in it. The new mixin needs `editIfc`, so it declares `NeedsEditIfc` and composes outside `withAuthoring`; `compositionOrder.test.ts` gains a fourth assertion. MUTATION-CHECKED: relaxing the constraint to `Ctor` produces "TS2578: Unused '@ts-expect-error' directive" on exactly the new line, so it fails for the reason claimed rather than merely passing. The extraction removed 27 lines and the banner plus import added 5 back — caught by the ratchet, not by me, the same way (94) found its own banner growth. Verified: tsc 0, lint 0, `vitest run src/api` 27 files / 119 tests, build 0, ruff (the CI command, from `services/api`) 0, and `test_file_sizes.py`, `test_claude_md_gates.py`, `test_roadmap_status.py` all 0. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Tt2XKB83wwNt2nrMbK6eEA --- CHANGELOG.md | 56 ++++++++++++++++ apps/web/src/api/client.ts | 36 ++--------- apps/web/src/api/compositionOrder.test.ts | 3 + apps/web/src/api/detailing.ts | 78 +++++++++++++++++++++++ apps/web/src/api/surface.test.ts | 4 ++ docs/roadmap.md | 35 +++++++++- services/api/test_file_sizes.py | 2 +- 7 files changed, 183 insertions(+), 31 deletions(-) create mode 100644 apps/web/src/api/detailing.ts diff --git a/CHANGELOG.md b/CHANGELOG.md index f083e940..6170a310 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1185,6 +1185,62 @@ 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-seventh follow-on on the same version: **SCALE-SEAM (98)** — *detailing carriers, and a +field map that is total over one module but not over the codebase*. + +Five methods out of `client.ts` (`687 → 665`) into a new `apps/web/src/api/detailing.ts`: +`elementDetailing`, `classify`, `applyDetailingRules`, `validateDetailing`, `attachDocument`. +**What they answer: what informational carriers are attached to this element, write them, and which +are missing.** + +### A 1:1 and total field-to-writer map + +The reader's response has exactly two carrier arrays, and `services/data/src/aec_data/detailing.py` +holds exactly two writers, one per array: + +| response field | writer | IFC relationship | +|---|---|---| +| `classifications[]` | `classify` | `IfcRelAssociatesClassification` | +| `documents[]` | `attachDocument` | `IfcRelAssociatesDocument` | + +`element_detailing` walks `HasAssociations` and branches on precisely those two relationship types — +nothing else contributes a field — so the map comes from the reader's own body rather than from +matching names. The other two methods are those same two writes under automation: +`applyDetailingRules` runs the condition-to-content rule set and writes both carrier kinds, and +`validateDetailing` reports elements a rule applies to that lack the required code. + +### Total over the module, not over the codebase + +`attachOmDocument` — moved to `model.ts` in (96) — is a purpose-tagged wrapper of the **same** +`detailing.attach_document`, so it also writes `IfcRelAssociatesDocument` and its output lands in +`documents[]`. So *"these are all the writers of this reader's fields"* is **false**. The claim the +evidence supports is narrower and is the one made: the map is 1:1 and total **over `detailing.py`**. +*That overlap was named when `attachOmDocument` moved, which is why it was available to qualify this +slice instead of being discovered by a reviewer.* + +### Adjacency agreed with the answer, and is not evidence for it + +These five were **contiguous** in `client.ts` (119–145). Unlike (95), where non-contiguity was the +whole argument for grouping by what methods answer, a positional split would have found this set +too. That is worth stating precisely *because* it looks like support: a grouping that happens to +coincide with adjacency is not thereby better evidenced. + +Also recorded: **`api.classify()` has no call site.** `viewer/tools/detailingSection.ts` drives the +recipe through the generic `authorAndReload("classify", …)` path, bypassing the typed method. +`api/clientCallers.test.ts` counts it as reached because it matches bare string literals as well as +calls — a looseness that file's own docstring declares deliberate, preferring a higher ceiling to a +false unreachability report. Noted so the next reader of `detailing.ts` does not assume the method +is live. + +The new mixin needs `editIfc`, so it declares `NeedsEditIfc` and composes outside `withAuthoring`; +`api/compositionOrder.test.ts` gains a fourth line asserting that. **That assertion was +mutation-checked**: relaxing the constraint to `Ctor` produces `TS2578: Unused '@ts-expect-error' +directive` on exactly the new line, so it fails for the reason claimed rather than merely passing. + +`client.ts` is 65 methods above the STAYING banner and 4 below. *The extraction removed 27 lines and +the banner plus import added 5 back — caught by the ratchet, not by me, which is the same way (94) +found its own banner growth.* + Thirty-sixth follow-on on the same version: **SCALE-SEAM (97)** — *the undo stack, and a destination that looked right and was not*. diff --git a/apps/web/src/api/client.ts b/apps/web/src/api/client.ts index 9b38ddaa..f1432507 100644 --- a/apps/web/src/api/client.ts +++ b/apps/web/src/api/client.ts @@ -17,6 +17,7 @@ import { withOperations } from "./operations"; import { withClientPortal } from "./clientPortal"; import { withCreDeal } from "./creDeal"; import { withAnnotate } from "./annotate"; +import { withDetailing } from "./detailing"; import { withResilience } from "./resilience"; import { withResponsibility } from "./responsibility"; import { withCodeCheck } from "./codecheck"; import { withDealMemory } from "./dealMemory"; @@ -69,7 +70,7 @@ import type { // Transport (baseUrl, token, json/_pdfPost/url/health) lives in HttpCore; ApiClient adds the typed // domain methods below. Every `api.method()` call site is unchanged by the split. -export class ApiClient extends withAnnotate(withCreDeal(withClientPortal(withResilience(withResponsibility(withOperations(withAccounting(withDealMemory(withPdfTools(withCodeCheck(withSpecialty(withIds(withEvm(withRisk(withEntitlements(withPrecon(withAi(withTopics(withMep(withDocuments(withModels(withElements(withDrawingSheets(withDrawingSet(withMarkup(withSync(withConnections(withDocQa(withFinance(withContracts(withAuth(withProforma(withDesignOptions(withRoutines(withCost(withProcurement(withEstimate(withModules(withModel(withSchedule(withLibrary(withAssetRights(withAuthoring(HttpCore))))))))))))))))))))))))))))))))))))))))))) { +export class ApiClient extends withDetailing(withAnnotate(withCreDeal(withClientPortal(withResilience(withResponsibility(withOperations(withAccounting(withDealMemory(withPdfTools(withCodeCheck(withSpecialty(withIds(withEvm(withRisk(withEntitlements(withPrecon(withAi(withTopics(withMep(withDocuments(withModels(withElements(withDrawingSheets(withDrawingSet(withMarkup(withSync(withConnections(withDocQa(withFinance(withContracts(withAuth(withProforma(withDesignOptions(withRoutines(withCost(withProcurement(withEstimate(withModules(withModel(withSchedule(withLibrary(withAssetRights(withAuthoring(HttpCore)))))))))))))))))))))))))))))))))))))))))))) { /** * R22-PHOTO-CV — attach a field photo to an element and get the server's read on it back. * @@ -116,33 +117,6 @@ export class ApiClient extends withAnnotate(withCreDeal(withClientPortal(withRes return this.json<{ by: string; buckets: Record; counts: Record; element_count: number }>( `/projects/${pid}/5d/heatmap?by=${by}`); } - /** W11 Track D: one element's attached carriers — classification codes + documents (details/instructions). */ - elementDetailing(pid: string, guid: string) { - return this.json<{ guid: string; name: string; ifc_class: string; - classifications: { system: string | null; code: string | null; title: string | null }[]; - documents: { identification: string | null; name: string | null; location: string | null; description: string | null }[] }>( - `/projects/${pid}/detailing/${encodeURIComponent(guid)}`); - } - /** W11 Track D: classify elements with a keynote/spec/element code (UniFormat/MasterFormat/OmniClass). */ - classify(pid: string, guids: string[], system: string, code: string, name?: string, edition?: string, publish = true) { - return this.editIfc(pid, "classify", { guids, system, code, name, edition }, publish); - } - /** W11 D3: auto-detail — run the condition→content rule set (e.g. exterior window → IBC flashing - * detail + 08 51 00), writing code/detail bundles to every matching element. */ - applyDetailingRules(pid: string, publish = true) { - return this.editIfc(pid, "apply_detailing_rules", {}, publish); - } - /** W11 D3: IDS-style QA — elements that a rule applies to but are missing their required keynote/spec code. */ - validateDetailing(pid: string) { - return this.json<{ rules_evaluated: number; gaps: number; - elements: { rule: string; guid: string; name: string; missing: string }[] }>( - `/projects/${pid}/detailing/rules/validate`); - } - /** W11 Track D: attach a document (detail drawing / installation instruction) to elements. */ - attachDocument(pid: string, guids: string[], name: string, - opts: { location?: string; identification?: string; description?: string; purpose?: string } = {}, publish = true) { - return this.editIfc(pid, "attach_document", { guids, name, ...opts }, publish); - } /** W11 B6: author a base plate + anchor bolts under a steel column (fabrication assembly). */ addBasePlate(pid: string, columnGuid: string, opts: { bolts?: number; width?: number; depth?: number } = {}, publish = true) { return this.editIfc(pid, "add_base_plate", { column_guid: columnGuid, ...opts }, publish); @@ -592,7 +566,7 @@ export class ApiClient extends withAnnotate(withCreDeal(withClientPortal(withRes // 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.** - // 70 methods still sit ABOVE this line — `disciplineTree`, `classify`, `specManual`, `editUndo`, + // 65 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. @@ -659,6 +633,10 @@ export class ApiClient extends withAnnotate(withCreDeal(withClientPortal(withRes // 70. `editIfc`, already there, is the PUSH they pop. `model.ts` looked right and is not: its // `modelVersions` reads a DIFFERENT stack. Reasoning in `authoring.ts`'s header. // + // (98) took DETAILING CARRIERS to a new `detailing.ts`, leaving 65. The reader's two carrier + // arrays map 1:1 onto `detailing.py`'s two writers, plus the rule engine that writes both and + // the audit that reports gaps. Reasoning in `detailing.ts`'s header. + // // 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/compositionOrder.test.ts b/apps/web/src/api/compositionOrder.test.ts index dec0776e..b7e2f290 100644 --- a/apps/web/src/api/compositionOrder.test.ts +++ b/apps/web/src/api/compositionOrder.test.ts @@ -32,6 +32,7 @@ import { HttpCore } from "./httpCore"; import { withAnnotate } from "./annotate"; import { withMep } from "./mep"; import { withModel } from "./model"; +import { withDetailing } from "./detailing"; describe("mixins requiring editIfc", () => { it("reject a base that lacks it, so a bad chain order fails at compile time", () => { @@ -41,6 +42,8 @@ describe("mixins requiring editIfc", () => { void (() => withMep(HttpCore)); // @ts-expect-error withModel needs NeedsEditIfc; bare HttpCore has no editIfc. void (() => withModel(HttpCore)); + // @ts-expect-error withDetailing needs NeedsEditIfc; bare HttpCore has no editIfc. + void (() => withDetailing(HttpCore)); expect(true).toBe(true); }); }); diff --git a/apps/web/src/api/detailing.ts b/apps/web/src/api/detailing.ts new file mode 100644 index 00000000..413db0aa --- /dev/null +++ b/apps/web/src/api/detailing.ts @@ -0,0 +1,78 @@ +/** Detailing carriers: the informational attachments an element carries — classification codes + * (keynote / spec / element) and associated documents (details, installation instructions) — the + * rule engine that writes them in bulk, and the QA that audits what is missing. + * + * **SCALE-SEAM (98).** *What informational carriers are attached to this element, write them, and + * which are missing?* Five methods: `elementDetailing` (the inspector), `classify` and + * `attachDocument` (the two writers), `applyDetailingRules` (the rule engine that writes both in + * bulk) and `validateDetailing` (the gap audit). + * + * **The witness is a 1:1 AND TOTAL field-to-writer map**, the shape (96) established. The reader's + * response has exactly two carrier arrays, and `services/data/src/aec_data/detailing.py` holds + * exactly two writers, one per array: + * + * `classifications[]` <- `classify` (writes `IfcRelAssociatesClassification`) + * `documents[]` <- `attachDocument` (writes `IfcRelAssociatesDocument`) + * + * `element_detailing` walks `HasAssociations` and branches on precisely those two relationship + * types — nothing else contributes a field — so the map is derived from the reader's own body, not + * inferred from names. The other two methods are the same two writes under automation: + * `applyDetailingRules` runs the condition-to-content rule set and writes BOTH carrier kinds, and + * `validateDetailing` reports elements a rule applies to that lack the required code. + * + * **What this does NOT claim, and it is the same limit (96) recorded.** `attachOmDocument` — + * moved to `model.ts` in (96) — is a purpose-tagged wrapper of the SAME + * `detailing.attach_document`, so it also writes `IfcRelAssociatesDocument` and its output appears + * in `documents[]`. *"These are all the writers of this reader's fields"* is therefore **false**. + * The map is 1:1 and total over `detailing.py`, which is the claim the evidence supports; one + * method answering the turnover question reaches the same carrier from another file, and that + * overlap was named when it moved rather than discovered here. + * + * *Two weaker witnesses, labelled as such rather than promoted.* `viewer/tools/detailingSection.ts` + * calls only the two READERS, so it corroborates them and bounds nothing; and these five were + * CONTIGUOUS in `client.ts` (119-145), which means — unlike (95), where non-contiguity was the + * whole argument — a positional split would have found this set too. **Adjacency agreeing with the + * answer is not evidence for it**; it is worth stating precisely because it looks like support. + * + * *`api.classify()` has no call site.* `viewer/tools/detailingSection.ts` drives the recipe through + * the generic `authorAndReload("classify", ...)` path, so the typed method is bypassed. + * `api/clientCallers.test.ts` counts it as reached because it matches bare string literals too — a + * looseness that file's own docstring declares deliberate, preferring a higher ceiling to a false + * unreachability report. Recorded here because the next reader of this file will otherwise assume + * the method is live. + */ +import type { NeedsEditIfc } from "./types"; + +type Ctor = new (...args: any[]) => T; + +export function withDetailing>(Base: TBase) { + return class Detailing extends Base { + /** W11 Track D: one element's attached carriers — classification codes + documents (details/instructions). */ + elementDetailing(pid: string, guid: string) { + return this.json<{ guid: string; name: string; ifc_class: string; + classifications: { system: string | null; code: string | null; title: string | null }[]; + documents: { identification: string | null; name: string | null; location: string | null; description: string | null }[] }>( + `/projects/${pid}/detailing/${encodeURIComponent(guid)}`); + } + /** W11 Track D: classify elements with a keynote/spec/element code (UniFormat/MasterFormat/OmniClass). */ + classify(pid: string, guids: string[], system: string, code: string, name?: string, edition?: string, publish = true) { + return this.editIfc(pid, "classify", { guids, system, code, name, edition }, publish); + } + /** W11 D3: auto-detail — run the condition→content rule set (e.g. exterior window → IBC flashing + * detail + 08 51 00), writing code/detail bundles to every matching element. */ + applyDetailingRules(pid: string, publish = true) { + return this.editIfc(pid, "apply_detailing_rules", {}, publish); + } + /** W11 D3: IDS-style QA — elements that a rule applies to but are missing their required keynote/spec code. */ + validateDetailing(pid: string) { + return this.json<{ rules_evaluated: number; gaps: number; + elements: { rule: string; guid: string; name: string; missing: string }[] }>( + `/projects/${pid}/detailing/rules/validate`); + } + /** W11 Track D: attach a document (detail drawing / installation instruction) to elements. */ + attachDocument(pid: string, guids: string[], name: string, + opts: { location?: string; identification?: string; description?: string; purpose?: string } = {}, publish = true) { + return this.editIfc(pid, "attach_document", { guids, name, ...opts }, publish); + } + }; +} diff --git a/apps/web/src/api/surface.test.ts b/apps/web/src/api/surface.test.ts index a3ff85db..b704f58b 100644 --- a/apps/web/src/api/surface.test.ts +++ b/apps/web/src/api/surface.test.ts @@ -250,6 +250,10 @@ describe("the API client's public surface", () => { // (97) the undo stack -> authoring.ts. All three have LIVE call sites in app.ts's S4 block, // so a drop here breaks the undo/redo buttons, not just the surface count. "editHistory", "editUndo", "editRedo", + // (98) detailing carriers -> detailing.ts. `elementDetailing` and `validateDetailing` have + // live call sites; `classify` is driven through the generic recipe path, so the SURFACE check + // is the only thing that would notice it vanishing. + "elementDetailing", "classify", "applyDetailingRules", "validateDetailing", "attachDocument", ]) { 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 c2bca22a..43c6e9dd 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)–(97) took fifty-six of those 126 — 70 remain, and there is STILL no map.** A new + **(88)–(98) took sixty-one of those 126 — 65 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`, @@ -3340,6 +3340,39 @@ verbs, with a command bar as the escape hatch to everything); and **role-shaped define. It corroborates; it does not bound. **Not every set has a witness as strong as the last one's, and promoting a block to a closure would be this sequence's own recurring defect.** + **(98) added `apps/web/src/api/detailing.ts`** — `elementDetailing`, `classify`, + `applyDetailingRules`, `validateDetailing`, `attachDocument`, answering *what informational + carriers are attached to this element, write them, and which are missing?* The witness is the + (96) shape at its strongest yet: **a 1:1 AND TOTAL field-to-writer map**. `element_detailing` + walks `HasAssociations` and branches on exactly two relationship types, and + `services/data/src/aec_data/detailing.py` holds exactly two writers — `classifications[]` from + `classify` (`IfcRelAssociatesClassification`), `documents[]` from `attachDocument` + (`IfcRelAssociatesDocument`). The map is read out of the reader's own body, not matched on names. + The remaining two methods are those same writes automated and audited. + + **Total over the MODULE, not over the codebase — and the difference is the claim.** + `attachOmDocument`, moved to `model.ts` in (96), wraps the *same* `detailing.attach_document` and + also lands in `documents[]`, so *"these are all the writers of this reader's fields"* is false. + *That overlap was named when it moved, which is why it was on hand to qualify this slice rather + than being found by a reviewer — the value of recording a limit is that the next slice inherits + it.* + + **Adjacency agreed with the answer and is not evidence for it.** These five were contiguous in + `client.ts`; unlike (95), where non-contiguity was the whole argument, a positional split would + have found this set too. Stated precisely *because* it looks like support. + + *Also recorded, since it will otherwise mislead the next reader:* **`api.classify()` has no call + site** — `apps/web/src/viewer/tools/detailingSection.ts` drives the recipe through the generic + `authorAndReload` path, bypassing the typed method, and `apps/web/src/api/clientCallers.test.ts` + counts it reached because it matches bare string literals as well as calls. That looseness is + deliberate per that file's own docstring (a higher ceiling beats a false unreachability report), + so it is a limit of the gate, not a defect in it. + + The new mixin needs `editIfc`, so it declares `NeedsEditIfc` and composes outside `withAuthoring`; + `apps/web/src/api/compositionOrder.test.ts` gains a fourth assertion, **mutation-checked** — + relaxing the constraint to `Ctor` produces `TS2578` on exactly the new line, so it fails for + the reason claimed. + **(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 a31e2419..f469c7b8 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": 687, # 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": 665, # 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 From 83e149e02da3ec4f4350b9ac3a4f294d9a7fc4dd Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 4 Sep 2026 06:19:17 +0000 Subject: [PATCH 06/12] =?UTF-8?q?SCALE-SEAM=20(99)=20=E2=80=94=20the=20con?= =?UTF-8?q?tent=20shelf,=20and=20a=20destination=20header=20that=20was=20w?= =?UTF-8?q?rong=20until=20now?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Moves `contentCatalog`, `placeContent` and `importContent` out of `client.ts` into `api/authoring.ts`. `client.ts` goes 665 -> 648, 62 methods above the STAYING banner. WHAT THEY ANSWER: what pre-made content can I place, and place it? THE WITNESS IS A ROLE-FOR-ROLE PARALLEL with the family shelf already in that file, read off the signatures rather than the shared noun: catalog reader familyCatalog() {count, categories: Record<..>} contentCatalog() {count, note, groups: Record<..>} placer placeFamily(pid, family, position) placeContent(pid, category, point, name) multipart import async importFamilies(pid, file, ..) async importContent(pid, file, opts) Three roles, three methods each, matching shapes and arities. A parallel between two method TRIPLES is structural; "both are shelves" would have been a shared word, which is the grouping (88) and (89) each had to reject. THE DESTINATION'S OWN FIRST LINE WAS WRONG UNTIL THIS COMMIT. `authoring.ts` has described itself as holding "the family/content shelf" while containing ZERO content methods — the word's only other appearances there are an HTTP header and a sentence about IFC *type* content. The docstring stated an intended scope as fact. That is recorded as corroboration that was FALSE, not as evidence. A header agreeing with the answer is worth nothing until someone checks whether it is true, and this one had been wrong for as long as it had existed. It is the smallest possible instance of the drift the project instructions keep warning about. Verified: tsc 0, lint 0, `vitest run src/api` 27 files / 119 tests, build 0, ruff (the CI command, from `services/api`) 0, and `test_file_sizes.py`, `test_claude_md_gates.py`, `test_roadmap_status.py` all 0. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Tt2XKB83wwNt2nrMbK6eEA --- CHANGELOG.md | 35 ++++++++++++++++++++++++++ apps/web/src/api/authoring.ts | 42 ++++++++++++++++++++++++++++++++ apps/web/src/api/client.ts | 27 ++++---------------- apps/web/src/api/surface.test.ts | 2 ++ docs/roadmap.md | 19 ++++++++++++++- services/api/test_file_sizes.py | 2 +- 6 files changed, 103 insertions(+), 24 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 6170a310..fa51af4b 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1185,6 +1185,41 @@ 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-eighth follow-on on the same version: **SCALE-SEAM (99)** — *the content half of a shelf the +destination's own first line already claimed*. + +Three methods out of `client.ts` (`665 → 648`) into the existing `apps/web/src/api/authoring.ts`: +`contentCatalog`, `placeContent`, `importContent`. No new mixin. **What they answer: what pre-made +content can I place, and place it.** + +### A role-for-role parallel, read off the signatures + +The family shelf was already in `authoring.ts`. The content shelf is the same three roles, with +matching shapes and arities: + +| role | family | content | +|---|---|---| +| catalog reader | `familyCatalog()` → `{count, categories: Record<…>}` | `contentCatalog()` → `{count, note, groups: Record<…>}` | +| placer | `placeFamily(pid, family, position)` | `placeContent(pid, category, point, name)` | +| multipart importer | `async importFamilies(pid, file, …)` | `async importContent(pid, file, opts)` | + +**A parallel between two method *triples* is structural.** "Both are shelves" would have been a +shared word — the grouping (88) and (89) each had to reject — so the argument is deliberately the +signatures, not the noun. + +### The destination's header was wrong until this commit + +`authoring.ts` line 1 has read *"the family/content shelf"* while the file held **zero** content +methods; the only other occurrences of the word were an HTTP header and a sentence about IFC *type* +content. The docstring described an intended scope as though it were a fact. + +That is the same class as every drift the project instructions warn about, at the smallest possible +scale: **prose asserting an arrangement that nothing checked.** It is recorded as corroboration that +was *false* rather than as evidence — the parallel above is what carries the slice, and a header +that agreed with me would have been worth nothing if I had not checked whether it was true. + +`client.ts` is 62 methods above the STAYING banner and 4 below. + Thirty-seventh follow-on on the same version: **SCALE-SEAM (98)** — *detailing carriers, and a field map that is total over one module but not over the codebase*. diff --git a/apps/web/src/api/authoring.ts b/apps/web/src/api/authoring.ts index d006e346..1c213588 100644 --- a/apps/web/src/api/authoring.ts +++ b/apps/web/src/api/authoring.ts @@ -17,6 +17,27 @@ * SCALE-SEAM ⓼ adds groups and assemblies — *how are these elements grouped?* * List, inspector, create group/assembly, parametric array. Detailing stayed. * + * **SCALE-SEAM (99) adds the CONTENT half of the shelf this file's own first line already claimed.** + * `contentCatalog`, `placeContent`, `importContent` — *what pre-made content can I place, and place + * it.* The witness is a ROLE-FOR-ROLE PARALLEL with the family shelf already here, derived from the + * signatures rather than from the shared word "shelf": + * + * catalog reader `familyCatalog()` {count, categories: Record<..>} | `contentCatalog()` {count, note, groups: Record<..>} + * placer `placeFamily(pid, family, position)` | `placeContent(pid, category, point, name)` + * multipart import `async importFamilies(pid, file, ..)` | `async importContent(pid, file, opts)` + * + * Three roles, three methods each, matching shapes and matching arities. *A parallel between two + * method TRIPLES is structural; "both are shelves" would have been a word, which is the grouping + * (88) and (89) each had to reject.* + * + * **The header above was wrong until this commit, and that is the small finding.** Line 1 has said + * "the family/content shelf" while this file held **zero** content methods — the only other + * occurrences of the word were an HTTP header and a sentence about IFC *type* content. So the + * docstring described an intended scope as though it were a fact. *That is the same class as every + * drift the project instructions warn about, at the smallest possible scale: prose asserting an + * arrangement nothing checked.* It is corroboration that was FALSE, not evidence — the parallel + * above is what carries the slice. + * * **SCALE-SEAM (97) adds the UNDO STACK — *what has been done to this model, and can I take it * back?*** `editHistory` (can_undo/can_redo + depths), `editUndo` and `editRedo`. They belong in * THIS file because `editIfc` — already here — is the PUSH they pop: `authoring.py` records the @@ -382,6 +403,27 @@ export function withAuthoring>(Base: TBase) { publish?: string }>( `/projects/${pid}/edit/redo`, { method: "POST", body: JSON.stringify({ publish }) }); } + /** CONTENT-1: the curated content catalog (logistics / furniture / landscaping → IFC class + phase). */ + contentCatalog() { + return this.json<{ count: number; note: string; groups: Record }>(`/content/catalog`); + } + /** CONTENT-1: place a catalogued content item at an [E,N] point (optionally with a supplied mesh). */ + placeContent(pid: string, category: string, point: [number, number], name?: string, publish = true) { + return this.editIfc(pid, "place_content", { category, point, ...(name ? { name } : {}) }, publish); + } + /** CONTENT-1 (import): upload a detailed mesh (glTF/GLB/OBJ/STL/PLY) → auto-classified + placed as the + * right IFC via place_content. Category auto-detected from the filename unless given. */ + async importContent(pid: string, file: File, opts: { category?: string; e?: number; n?: number; + scale?: number; name?: string; storey?: string } = {}) { + const q = new URLSearchParams(); + for (const [k, v] of Object.entries(opts)) if (v !== undefined && v !== "") q.set(k, String(v)); + const fd = new FormData(); fd.append("file", file); + const r = await fetch(this.url(`/projects/${pid}/content/import?${q.toString()}`), + { method: "POST", body: fd, headers: this.authHeaders() }); + if (!r.ok) throw new Error((await r.text()) || `HTTP ${r.status}`); + return r.json() as Promise<{ guid: string; ifc_class: string; category: string; faces: number; publish?: string }>; + } }; } diff --git a/apps/web/src/api/client.ts b/apps/web/src/api/client.ts index f1432507..c8533528 100644 --- a/apps/web/src/api/client.ts +++ b/apps/web/src/api/client.ts @@ -152,27 +152,6 @@ export class ApiClient extends withDetailing(withAnnotate(withCreDeal(withClient phasing: Record; lod: Record; hygiene: { issues: number | null; clean: boolean | null } }>(`/projects/${pid}/scene-digest`); } - /** CONTENT-1: the curated content catalog (logistics / furniture / landscaping → IFC class + phase). */ - contentCatalog() { - return this.json<{ count: number; note: string; groups: Record }>(`/content/catalog`); - } - /** CONTENT-1: place a catalogued content item at an [E,N] point (optionally with a supplied mesh). */ - placeContent(pid: string, category: string, point: [number, number], name?: string, publish = true) { - return this.editIfc(pid, "place_content", { category, point, ...(name ? { name } : {}) }, publish); - } - /** CONTENT-1 (import): upload a detailed mesh (glTF/GLB/OBJ/STL/PLY) → auto-classified + placed as the - * right IFC via place_content. Category auto-detected from the filename unless given. */ - async importContent(pid: string, file: File, opts: { category?: string; e?: number; n?: number; - scale?: number; name?: string; storey?: string } = {}) { - const q = new URLSearchParams(); - for (const [k, v] of Object.entries(opts)) if (v !== undefined && v !== "") q.set(k, String(v)); - const fd = new FormData(); fd.append("file", file); - const r = await fetch(this.url(`/projects/${pid}/content/import?${q.toString()}`), - { method: "POST", body: fd, headers: this.authHeaders() }); - if (!r.ok) throw new Error((await r.text()) || `HTTP ${r.status}`); - return r.json() as Promise<{ guid: string; ifc_class: string; category: string; faces: number; publish?: string }>; - } /** W11 E8: validate an edit's params against the authoring guardrails without applying it. */ editPrecheck(pid: string, recipe: string, params: Record) { return this.json<{ ok: boolean; errors: string[]; warnings: string[] }>( @@ -566,7 +545,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.** - // 65 methods still sit ABOVE this line — `disciplineTree`, `classify`, `specManual`, `editUndo`, + // 62 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. @@ -637,6 +616,10 @@ export class ApiClient extends withDetailing(withAnnotate(withCreDeal(withClient // arrays map 1:1 onto `detailing.py`'s two writers, plus the rule engine that writes both and // the audit that reports gaps. Reasoning in `detailing.ts`'s header. // + // (99) took the CONTENT SHELF — `contentCatalog`/`placeContent`/`importContent` — to + // `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. + // // 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/surface.test.ts b/apps/web/src/api/surface.test.ts index b704f58b..e1584a59 100644 --- a/apps/web/src/api/surface.test.ts +++ b/apps/web/src/api/surface.test.ts @@ -254,6 +254,8 @@ describe("the API client's public surface", () => { // live call sites; `classify` is driven through the generic recipe path, so the SURFACE check // is the only thing that would notice it vanishing. "elementDetailing", "classify", "applyDetailingRules", "validateDetailing", "attachDocument", + // (99) the content shelf -> authoring.ts, joining the family triple it parallels. + "contentCatalog", "placeContent", "importContent", ]) { 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 43c6e9dd..61972eb3 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)–(98) took sixty-one of those 126 — 65 remain, and there is STILL no map.** A new + **(88)–(99) took sixty-four of those 126 — 62 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`, @@ -3373,6 +3373,23 @@ verbs, with a command bar as the escape hatch to everything); and **role-shaped relaxing the constraint to `Ctor` produces `TS2578` on exactly the new line, so it fails for the reason claimed. + **(99) took the CONTENT SHELF to `apps/web/src/api/authoring.ts`** — `contentCatalog`, + `placeContent`, `importContent`, answering *what pre-made content can I place, and place it?* The + witness is a **role-for-role parallel** with the family shelf already in that file, read off the + signatures rather than the shared noun: `familyCatalog`/`contentCatalog` are both catalog readers + returning `{count, …Record<…>}`, `placeFamily`/`placeContent` are both placers, and + `importFamilies`/`importContent` are both async multipart importers. Three roles, three methods + each. **A parallel between two method TRIPLES is structural**; *"both are shelves"* would have been + a word, which is the grouping (88) and (89) each had to reject. + + **And the destination's own first line was wrong until this commit.** `authoring.ts` has described + itself as holding *"the family/content shelf"* while containing **zero** content methods — the + word's only other appearances there are an HTTP header and a sentence about IFC *type* content. The + docstring stated an intended scope as fact. *Recorded as corroboration that was FALSE rather than + as evidence: a header agreeing with the answer is worth nothing until someone checks whether it is + 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. + **(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 f469c7b8..ff9ecb9b 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": 665, # 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": 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. #: 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 From 2a8f46ff2ccf68b56f9bbfb4564a06343a9fa6eb Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 4 Sep 2026 07:24:58 +0000 Subject: [PATCH 07/12] =?UTF-8?q?SCALE-SEAM=20(100)=20=E2=80=94=20the=20el?= =?UTF-8?q?ement-connection=20pair,=20and=20a=20destination=20named=20at?= =?UTF-8?q?=20its=20real=20strength?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Moves `elementConnections` and `connectElements` out of `client.ts` into `api/model.ts`. `client.ts` goes 648 -> 642, 60 methods above the STAYING banner. WHAT THEY ANSWER: 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 (IfcRelConnectsElements), both marked B5. THE DESTINATION ARGUMENT IS WEAKER THAN THE PAIRING ARGUMENT AND IS LABELLED SO. `model.ts` owns `modelGraphStats`, whose `by_rel` counts the IFC relationship graph BY RELATION — IfcRelConnectsElements being one — and `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: the graph methods are generic traversal over every IfcRel*, these two are one relation with a verb attached. The pairing is evidenced; the placement is a judgement, and collapsing the two into one confident sentence is 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 — sharing nothing with this but the English word, and it is the file a name-based search lands on first. (97) found two version stacks behind one word; this is the same collision in a destination rather than a source. `elements.ts` holds element ATTRIBUTES and views, and a relationship between two elements is not an attribute of either. `addBasePlate`/`addShearTab` did not come despite sharing `connections.py` with these: a backend module is a HOW, the grouping (89) had to reject, and those two 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. Verified: tsc 0, lint 0, `vitest run src/api` 27 files / 119 tests, build 0, ruff (the CI command, from `services/api`) 0, and `test_file_sizes.py`, `test_claude_md_gates.py`, `test_roadmap_status.py` all 0. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Tt2XKB83wwNt2nrMbK6eEA --- CHANGELOG.md | 46 ++++++++++++++++++++++++++++++++ apps/web/src/api/client.ts | 16 ++++------- apps/web/src/api/model.ts | 42 +++++++++++++++++++++++++++++ apps/web/src/api/surface.test.ts | 2 ++ docs/roadmap.md | 26 +++++++++++++++++- services/api/test_file_sizes.py | 2 +- 6 files changed, 121 insertions(+), 13 deletions(-) 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 From f5d675148291191e1494d7d79e88bf1ad0b2eefe Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 4 Sep 2026 12:49:48 +0000 Subject: [PATCH 08/12] =?UTF-8?q?R22-ENTITLEMENT=20=E2=91=A4=20=E2=80=94?= =?UTF-8?q?=20an=20agency=20review=20comment=20becomes=20an=20RFI=20somebo?= =?UTF-8?q?dy=20owns?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `RecordComment` had NO outward link of any kind. An agency's comment on an `entitlement` or `permit` was a text blob at the end of a thread: readable, and impossible to assign, track or close. ④ made comments survive a revision — the INBOUND half of "round-tripping"; this is the outbound half the ring entry still listed as remaining. `POST /projects/{pid}/modules/{key}/{rid}/comments/{cid}/promote` mints a Topic carrying the comment text, the source record's ref and its `element_guids`, and writes a back-link on the comment. THE BACK-LINK IS THE IDEMPOTENCY. A second promote 409s instead of minting a duplicate RFI — the failure mode a promote button produces on every double-click. Both load-bearing assertions in `test_comment_promote.py` were MUTATION-CHECKED: removing the 409 guard makes one comment mint two RFIs (the failure output shows both `comment.promote` activity entries), and removing the back-link write drops `topic_id` from the comment. Follows `promote_markup` rather than inventing a second idiom — mint, carry provenance, link back, 409, audit. REACHABLE, NOT MERELY BUILT: the control renders beside the comment and is replaced by "→ RFI raised" once promoted, because a button whose only remaining outcome is a 409 is worse than no button. Adding it turned `register.ts`'s extraction ratchet red, and the remedy is the one that file states — extraction, never headroom. The comment thread, composer and new control came out to `portal/register/recordComments.ts` (2,516 -> 2,505, pin lowered with it). A genuine leaf: it touches the record's comments, the API and a reload callback and nothing else on the class, and the directory already holds three leaves extracted the same way. WHAT THE PREMISE-CHECK FOUND, and it is why this slice exists. The entry's "Remaining:" line named two things and contradicted itself on one — it listed submittal packages flatly while the note above it said the inbound half had shipped. Measured: the inbound view is real, but assembling a package to send is not, because `modules/transmittal/module.json` types `items` as a textarea and `to_company` as plain text. Package contents are prose no machine can resolve back to the records named, and the recipient cannot be the agency an `entitlement` names, since that is free text too. That is a SCHEMA question, not a workflow one — which is why reading the workflow surface kept reporting it done. The roadmap now says that instead of the flat line. Also corrected: the roadmap's argument against picking SCALE-SEAM quoted `client.ts` at 2,837 lines. It is 642 — copied forward through every slice since, the exact drift the rows beside it document twice. Verified: tsc 0, lint 0, build 0, `vitest run src/portal src/api` 50 files / 275 tests, ruff (the CI command, from `services/api`) 0, and `test_comment_promote`, `test_modules`, `test_topic_lifecycle`, `test_reachable`, `test_declared_imports`, `test_ruff_scope`, `test_file_sizes`, `test_claude_md_gates`, `test_roadmap_status`, `test_doc_substance`, `test_alembic_single_head` all 0. Full 660-suite running as a cross-check. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Tt2XKB83wwNt2nrMbK6eEA --- CHANGELOG.md | 49 ++++++++ apps/web/src/api/modules.ts | 9 ++ apps/web/src/api/surface.test.ts | 3 + apps/web/src/api/types.ts | 6 +- .../web/src/portal/register/recordComments.ts | 66 +++++++++++ apps/web/src/portal/register/register.ts | 25 ++-- docs/roadmap.md | 34 +++++- ...record_comment_topic_id_r22_entitlement.py | 30 +++++ services/api/run_tests.py | 2 +- services/api/src/aec_api/models.py | 5 + services/api/src/aec_api/modules.py | 57 +++++++++- services/api/src/aec_api/routers/modules.py | 13 +++ services/api/test_comment_promote.py | 107 ++++++++++++++++++ services/api/test_file_sizes.py | 2 +- 14 files changed, 379 insertions(+), 29 deletions(-) create mode 100644 apps/web/src/portal/register/recordComments.ts create mode 100644 services/api/migrations/versions/2026_09_04_1200-c8a4e2f71b39_record_comment_topic_id_r22_entitlement.py create mode 100644 services/api/test_comment_promote.py diff --git a/CHANGELOG.md b/CHANGELOG.md index 4a3c40a3..c7e50d2b 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1185,6 +1185,55 @@ Reader and unwired writer on one panel — still the reason not to separate them Pin 731 → 727. **80 above the banner, still no map.** +Fortieth follow-on on the same version: **R22-ENTITLEMENT ⑤** — *an agency review comment becomes an +RFI somebody owns*. + +**The gap.** `RecordComment` had **no outward link of any kind**. An agency's comment on an +`entitlement` or `permit` was a text blob at the end of a thread: readable, and impossible to assign, +track or close. ④ had already made comments survive a revision — that is the *inbound* half of +"round-tripping"; this is the outbound half the ring entry still listed as remaining. + +`POST /projects/{pid}/modules/{key}/{rid}/comments/{cid}/promote` mints a Topic carrying the comment +text, the source record's ref and its `element_guids`, and writes a back-link on the comment. + +### The back-link is the idempotency + +A second promote **409s** instead of minting a duplicate RFI — the failure mode a promote button +produces on every double-click. `services/api/test_comment_promote.py` holds it, and both +load-bearing assertions were **mutation-checked**: removing the 409 guard makes one comment mint two +RFIs, and the failure output shows both `comment.promote` activity entries side by side; removing the +back-link write drops `topic_id` from the comment. + +Follows `promote_markup` (`POST …/drawings/markup/{mid}/promote`) rather than inventing a second +idiom — same shape: mint, carry provenance, link back, 409, audit. + +### Reachable, not merely built + +The control renders beside the comment in `apps/web/src/portal/register/recordComments.ts` and is +replaced by "→ RFI raised" once promoted, because a button whose only remaining outcome is a 409 is +worse than no button. + +Adding it turned `register.ts`'s extraction ratchet red, and **the remedy is the one that file +states: extraction, never headroom.** The comment thread + composer + the new control came out to +`portal/register/recordComments.ts` (`2,516 → 2,505`, pin lowered with it). The block is a genuine +leaf — it touches the record's comments, the API and a reload callback and nothing else on the class +— and the directory already holds three leaves extracted the same way. + +### What the premise-check found, and it is why this slice exists + +The entry's "Remaining:" line named **two** things and **contradicted itself on one**: it listed +submittal packages flatly while the ④ note above it said the inbound half had already shipped. +Measured 2026-09-04 — the inbound *view* is real (`…/related` returns `incoming`), but assembling a +package to send is not, because `modules/transmittal/module.json` types **`items` as a textarea and +`to_company` as plain text**. A package's contents are prose no machine can resolve back to the +records it names, and its recipient cannot be the agency an `entitlement` names, since that is free +text too. *That is a schema question — reference fields — not a workflow one, which is why reading +the workflow surface kept reporting it done.* The roadmap now says that instead of the flat line. + +Also corrected: the roadmap's argument against picking SCALE-SEAM quoted `client.ts` at **2,837 +lines**. It is **642** — the number was copied forward through every slice since, which is the exact +drift the rows beside it document twice. + 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*. diff --git a/apps/web/src/api/modules.ts b/apps/web/src/api/modules.ts index 50039493..21becd75 100644 --- a/apps/web/src/api/modules.ts +++ b/apps/web/src/api/modules.ts @@ -130,6 +130,15 @@ export function withModules>(Base: TBase) { return this.json(`/projects/${pid}/modules/${key}/${rid}/comments`, { method: "POST", body: JSON.stringify({ text }) }); } + /** R22-ENTITLEMENT ⑤: promote a review comment into an RFI (or punch item) somebody owns. An + * agency comment has to leave the thread — be assigned, tracked, closed. 409 if already promoted, + * which is what stops a double-click minting two RFIs for one comment. */ + promoteComment(pid: string, key: string, rid: string, cid: string, kind: "rfi" | "issue" = "rfi") { + return this.json<{ comment_id: string; record: ModuleRecord; + topic: { id: string; type: string; title: string; status: string; element_guids: string[] | null } }>( + `/projects/${pid}/modules/${key}/${rid}/comments/${cid}/promote`, + { method: "POST", body: JSON.stringify({ kind }) }); + } updateModuleRecord(pid: string, key: string, rid: string, data: Record, expectedModifiedAt?: string | null) { // pass the modified_at the editor loaded to opt into the optimistic lock — a concurrent edit diff --git a/apps/web/src/api/surface.test.ts b/apps/web/src/api/surface.test.ts index b206257d..058563ae 100644 --- a/apps/web/src/api/surface.test.ts +++ b/apps/web/src/api/surface.test.ts @@ -258,6 +258,9 @@ describe("the API client's public surface", () => { "contentCatalog", "placeContent", "importContent", // (100) the IfcRelConnectsElements reader + its writer -> model.ts. "elementConnections", "connectElements", + // R22-ENTITLEMENT ⑤ — the promote control in register.ts is the only call site, so losing + // this method silently un-reaches the capability rather than breaking a typecheck. + "promoteComment", ]) { expect(surface.has(k), `${k}() vanished — a call site is now broken`).toBe(true); } diff --git a/apps/web/src/api/types.ts b/apps/web/src/api/types.ts index b1899958..257a4330 100644 --- a/apps/web/src/api/types.ts +++ b/apps/web/src/api/types.ts @@ -384,7 +384,11 @@ export interface ModuleRecord { }; attachments?: RecordAttachmentMeta[]; activity?: { ts: string; actor: string; party: string; action: string; detail: unknown }[]; - comments?: { author: string | null; text: string; created_at: string }[]; + // `id` and `topic_id` are R22-ENTITLEMENT ⑤: a comment must be addressable to be promoted into + // an RFI, and `topic_id` is present ONLY once it has been — absent means not promoted, which + // a build predating the column reports identically rather than claiming a false `null`. + comments?: { id?: string; author: string | null; text: string; created_at: string; + topic_id?: string }[]; available_actions?: { action: string; to: string; party: string[]; requires?: string[] }[]; } export interface RecordAttachmentMeta { diff --git a/apps/web/src/portal/register/recordComments.ts b/apps/web/src/portal/register/recordComments.ts new file mode 100644 index 00000000..f655bc8b --- /dev/null +++ b/apps/web/src/portal/register/recordComments.ts @@ -0,0 +1,66 @@ +/** + * The comment thread on a register record — render it, add to it, and promote an entry out of it. + * + * Lived inline in `register.ts` until R22-ENTITLEMENT ⑤ added the promote control and the file's + * extraction ratchet went red. The pin's question is whether the block is a leaf, and this one is: + * it touches the record's `comments`, the API, and a reload callback, and nothing else on the class. + * + * **R22-ENTITLEMENT ⑤ — why a comment needs a way out.** An agency's review comment is the one input + * that must LEAVE the thread: somebody has to be assigned it and it has to close. Promoting mints an + * RFI carrying the comment text, the source record's ref and its element ties. Once promoted the + * control is replaced by its outcome, because the second press would 409 and a button whose only + * remaining result is an error is worse than no button at all. + */ +import type { ModuleDef, ModuleRecord } from "../../api/client"; + +export interface RecordCommentsDeps { + root: HTMLElement; + api: { + addComment(pid: string, key: string, rid: string, text: string): Promise; + promoteComment(pid: string, key: string, rid: string, cid: string, + kind?: "rfi" | "issue"): Promise; + }; + setStatus(msg: string): void; + reload(): void; +} + +/** Render the thread + composer for one record. */ +export function mountRecordComments(d: RecordCommentsDeps, pid: string, m: ModuleDef, + rid: string, r: ModuleRecord): void { + const cd = document.createElement("div"); + cd.className = "section-title"; cd.textContent = "Comments"; + d.root.appendChild(cd); + + for (const cm of r.comments ?? []) { + const e = document.createElement("div"); e.className = "portal-act"; + e.textContent = `${cm.author ?? ""}: ${cm.text}`; + if (cm.topic_id) { + const done = document.createElement("span"); + done.className = "meta"; done.textContent = " → RFI raised"; + e.appendChild(done); + } else if (cm.id) { + const cid = cm.id; + const pb = document.createElement("button"); + pb.className = "mini-btn"; pb.textContent = "→ RFI"; pb.style.marginLeft = "6px"; + pb.title = "Raise an RFI from this comment"; + pb.onclick = async () => { + pb.disabled = true; + try { await d.api.promoteComment(pid, m.key, rid, cid); d.reload(); } + catch (err) { pb.disabled = false; d.setStatus(`promote failed: ${(err as Error).message}`); } + }; + e.appendChild(pb); + } + d.root.appendChild(e); + } + + const ta = document.createElement("textarea"); + ta.className = "portal-field"; ta.placeholder = "Add a comment…"; ta.style.width = "100%"; + const addBtn = document.createElement("button"); + addBtn.className = "tool-btn"; addBtn.textContent = "Comment"; addBtn.style.margin = "4px 0"; + addBtn.onclick = async () => { + if (!ta.value.trim()) return; + await d.api.addComment(pid, m.key, rid, ta.value.trim()); + d.reload(); + }; + d.root.append(ta, addBtn); +} diff --git a/apps/web/src/portal/register/register.ts b/apps/web/src/portal/register/register.ts index a31fcf20..a373a864 100644 --- a/apps/web/src/portal/register/register.ts +++ b/apps/web/src/portal/register/register.ts @@ -5,6 +5,7 @@ import { statusChip } from "../../ui/chips"; import { type RegisterEmptyKind, registerEmptyEl } from "../../ui/empty"; import { emptyHint } from "../../ui/emptyGuide"; import { escapeHtml as esc, toast } from "../../ui/feedback"; +import { mountRecordComments } from "./recordComments"; import { confidenceReading } from "../../ui/confidenceReading"; import { confirmModal, modalShell, promptModal } from "../../ui/modal"; import { allQueued, dequeue, enqueueUpload, queuedCountForRecord } from "../offlineQueue"; @@ -2289,24 +2290,12 @@ export class RegisterUI { } } - // comments - const cd = document.createElement("div"); cd.className = "section-title"; cd.textContent = "Comments"; - this.ctx.root.appendChild(cd); - for (const cm of r.comments ?? []) { - const e = document.createElement("div"); e.className = "portal-act"; - e.textContent = `${cm.author ?? ""}: ${cm.text}`; - this.ctx.root.appendChild(e); - } - const ta = document.createElement("textarea"); - ta.className = "portal-field"; ta.placeholder = "Add a comment…"; ta.style.width = "100%"; - const addBtn = document.createElement("button"); - addBtn.className = "tool-btn"; addBtn.textContent = "Comment"; addBtn.style.margin = "4px 0"; - addBtn.onclick = async () => { - if (!ta.value.trim()) return; - await this.ctx.host.api.addComment(pid, m.key, rid, ta.value.trim()); - void this.openRecord(m, rid); - }; - this.ctx.root.append(ta, addBtn); + // comments — thread, composer, and the R22-ENTITLEMENT ⑤ promote control. + mountRecordComments({ + root: this.ctx.root, api: this.ctx.host.api, + setStatus: (s) => this.ctx.host.setStatus(s), + reload: () => { void this.openRecord(m, rid); }, + }, pid, m, rid, r); // activity timeline const td = document.createElement("div"); td.className = "section-title"; td.textContent = "Activity"; diff --git a/docs/roadmap.md b/docs/roadmap.md index 7a601efe..70424536 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -1134,7 +1134,9 @@ exact failure `roadmapLanes.test.ts` documents in its `MARKS` note. The gates ca needs to keep being interleaved. **Re-measure the ceiling before ever promoting it again** — that is the specific error row 2 made. * **Not the next SCALE-SEAM slice.** ㉘ is genuinely next in a series that has shipped twenty-six - increments, but the series is now cutting into `client.ts` at 2,837 lines from a 3,600-odd start. The marginal slice + increments, but the series is now cutting into `client.ts` at **642** lines from a 3,600-odd start + *(re-derived 2026-09-04; this read "2,837" — 4.4x the real figure — because the number was copied + forward through every slice since, which is the exact drift the rows above document twice)*. The marginal slice is worth less than it was. *(㉘ also needed `MARKS` widened; that shipped in v0.3.1112.)* The vocabulary lives in `apps/web/src/shell/roadmapLanes.test.ts` — a vocabulary change to a population check, which that file's own docstring calls a real change and not housekeeping. @@ -1719,8 +1721,9 @@ stakes we are missing. **Tier 1 — closes the mission's own gaps** -- ◧ **R22-ENTITLEMENT** *(M/L — ①②③ shipped: `approval_conditions.py`, `condition_checks.py`, - `approval_cycles.py` + the `review_cycle` register)* — **permit & entitlement workflow**: jurisdiction +- ◧ **R22-ENTITLEMENT** *(M/L — ①②③④⑤ shipped: `approval_conditions.py`, `condition_checks.py`, + `approval_cycles.py` + the `review_cycle` register, comment inheritance across revisions, and the + comment→RFI promote)* — **permit & entitlement workflow**: jurisdiction submittal packages, review cycles, comment responses, and **conditions of approval carried into the model as constraints**. Today there is a hole between "acquisition" and "construction" in our own mission statement — we underwrite the deal and we build it, and nothing spans approval. @@ -1761,8 +1764,29 @@ stakes we are missing. about the party you are about to argue with. Days are **calendar**, stated on the response, because a statutory review clock does not pause for a weekend and construction durations elsewhere here are working days. - **Remaining:** submittal *packages* (the documents that go to the authority) and comment-response - round-tripping into RFI/issue records. + ⑤ **comment-response round-tripping into RFI/issue records, shipped 2026-09-04.** `RecordComment` + had **no outward link of any kind** — an agency's comment on an `entitlement` or `permit` was a + text blob at the end of a thread: readable, and impossible to assign, track or close. ④ made + comments survive a revision, which is the INBOUND half; this is the outbound half. + `POST …/modules/{key}/{rid}/comments/{cid}/promote` mints a Topic carrying the comment, the source + record's ref and its `element_guids`, and writes a back-link. **The back-link is the idempotency**: + a second promote 409s rather than minting a duplicate RFI, which is what a promote button does on + every double-click. Follows `promote_markup` rather than inventing a second idiom. Held by + `services/api/test_comment_promote.py`, whose two load-bearing assertions were mutation-checked — + removing the 409 guard makes one comment mint two RFIs, and the failure output shows both. + *Reachable, not merely built:* the control renders beside the comment in + `apps/web/src/portal/register/register.ts` and is replaced by "→ RFI raised" once promoted, because + a button whose only remaining outcome is a 409 is worse than no button. + + **Remaining: the OUTBOUND submittal package, and the reason is now specific rather than vague.** + This line used to name "submittal packages" flatly while the ④ note above said the inbound half had + already shipped — the entry contradicted itself. Measured 2026-09-04: the inbound *view* is real + (`…/related` returns `incoming`), but assembling a package to send is not, because + `modules/transmittal/module.json` types **`items` as a textarea and `to_company` as plain text**. + A package's contents are therefore prose no machine can resolve back to the records it names, and + its recipient cannot be the agency an `entitlement` names, since that field is free text too. + *That is a schema question — reference fields — not a workflow one, which is why reading the + workflow surface kept reporting this as done.* ⚠️ **Two name collisions sit on this item; gap-check on SEMANTICS before touching it.** `tiers.py` is **subscription tiers** (free/pro/enterprise), nothing to do with land use — it was diff --git a/services/api/migrations/versions/2026_09_04_1200-c8a4e2f71b39_record_comment_topic_id_r22_entitlement.py b/services/api/migrations/versions/2026_09_04_1200-c8a4e2f71b39_record_comment_topic_id_r22_entitlement.py new file mode 100644 index 00000000..83ebd11d --- /dev/null +++ b/services/api/migrations/versions/2026_09_04_1200-c8a4e2f71b39_record_comment_topic_id_r22_entitlement.py @@ -0,0 +1,30 @@ +"""record_comments.topic_id — promote an agency review comment into an RFI (R22-ENTITLEMENT ⑤) + +Revision ID: c8a4e2f71b39 +Revises: f4b8c2d51e93 +Create Date: 2026-09-04 12:00:00.000000 +""" +from __future__ import annotations + +from collections.abc import Sequence + +import sqlalchemy as sa +from alembic import op + +# revision identifiers, used by Alembic. +revision: str = 'c8a4e2f71b39' +down_revision: str | None = 'f4b8c2d51e93' +branch_labels: str | Sequence[str] | None = None +depends_on: str | Sequence[str] | None = None + + +def upgrade() -> None: + # Nullable and no server default: an existing comment has not been promoted, and NULL says that + # without inventing a state for it. The back-link is what makes promotion idempotent. + with op.batch_alter_table('record_comments', schema=None) as batch_op: + batch_op.add_column(sa.Column('topic_id', sa.String(), nullable=True)) + + +def downgrade() -> None: + with op.batch_alter_table('record_comments', schema=None) as batch_op: + batch_op.drop_column('topic_id') diff --git a/services/api/run_tests.py b/services/api/run_tests.py index 81739301..d3db2341 100644 --- a/services/api/run_tests.py +++ b/services/api/run_tests.py @@ -86,7 +86,7 @@ "test_markup", "test_route_authz", "test_resource_id_authz", "test_route_reachability", "test_resumable_upload", "test_model_align", "test_ifc_parse_gate", "test_plugin_isolation", "test_body_pid_authz", "test_global_authz", "test_protected_prefix_coverage", "test_baseline", "test_global_mutating_authz", "test_ref_counter", "test_audit_coverage", "test_bsdd", "test_openbim_registry", "test_waterfall", "test_waterfall_cents", "test_sessions", "test_mfa", "test_stored_ids", "test_cobie", "test_fts_index", "test_scim", "test_scim_provision_race", "test_saml", "test_responsibility", "test_array_live", "test_assemblies", "test_dxf_takeoff", "test_qto_class_match", "test_georef", "test_scene_package", "test_clash_bvh", "test_model_qa", "test_model_health", "test_roundtrip_qa", "test_stakeholder", "test_prioritization", "test_ai_readiness", - "test_scan_deviation", "test_plan_to_bim", "test_errorlog", "test_import_cycles", "test_tenant_scoping", "test_schedule_risk_single", "test_carbon_compliance", "test_permit_check", "test_drawing_qa", "test_element_5d", "test_authoring_matrix", "test_option_missing", "test_option_score", "test_plugin_registry", "test_jobs", "test_clash_federated_job", "test_inbox_jobs", "test_job_kind_labels", "test_worker_split", "test_job_orphan_scope", "test_job_stall", "test_pid_lock_xproc", "test_pid_lock_surface", "test_sheet_layout", "test_dim_component", "test_sheet_recover", "test_firm_standards", "test_site_context", "test_risk_board", "test_env_wind", "test_model_options", "test_doc_text", "test_escalation", "test_query_dsl", "test_rule_library", "test_schedule_baselines", "test_model_ci", "test_xlsx_roundtrip", "test_geometric_rules", "test_rebar_rules", "test_cx", "test_distwaterfall", "test_license_cloud", "test_smart_views", "test_view_delete", "test_version_approve_identity", "test_upload_streaming", "test_lod_aspects", "test_lod_element_table", "test_publish_reconvert", "test_model_cache_seed", "test_model_cache_mutation", "test_mutating_readers", "test_adopt_guid", "test_ifcpatch", "test_bcf_api", "test_coordination_fresh", "test_assemblies_cost", "test_fem_export", "test_subset_export", "test_norm_valid", "test_schema_diag", "test_revision_delta", "test_bep", "test_pm_close", "test_itp", "test_quality_chain", "test_quality_chain_route", "test_meeting_links", "test_est_bands", "test_scope_gap", "test_golden_thread", "test_clash_xml_import", "test_gis_out", "test_cbs", "test_mep_graph", "test_model_warnings", "test_schedule_options", "test_master_builder", "test_master_builder_scope", "test_get_commits", "test_project_pulse", "test_client_portal", "test_selections", "test_margin", "test_model_assets", "test_macros", "test_layout_options", "test_equipment", "test_space_util", "test_design_metrics", "test_mep_fittings", "test_prod_actuals", "test_pipeline_allocate", "test_production", "test_procure_level", "test_adjacency", "test_supply_chain", "test_invisible_unicode", "test_cited_answer", "test_est_confidence", "test_buyout_schedule", "test_scope_register", "test_permit_timeline", "test_absorption", "test_progress_rollup", "test_fill_matrix", "test_parcel_geometry", "test_assembly_thermal", "test_portal_txn", "test_persona_answer", "test_boe_ledger", "test_assumption_provenance", "test_assumption_provenance_route", "test_concept_budget", "test_topic_board", "test_roof_window", "test_topic_lifecycle", "test_calc_fields", "test_constraints", "test_element_lookup", "test_cli", "test_view_templates", "test_type_catalogs", "test_password_policy", "test_stepup_single_verifier", "test_fin_gov", "test_fin_calc", "test_fin_ingest", "test_fin_portfolio", "test_level_move", "test_instance_props", "test_roundtrip", "test_wall_joins", "test_composite_family", "test_shared_params", "test_version_values", "test_ifcpatch_transforms", "test_bcf3", "test_energy_export", "test_net_effective", "test_cre_deal_desk", "test_cre_governance", "test_cre_tier3", "test_family_geometry", "test_demo_seed", "test_cost_spine", "test_commercial_drift", "test_family_shapes", "test_workflow_config", "test_option_takeoff", "test_option_carbon", "test_option_carbon_route", "test_option_economics", "test_option_economics_route", "test_option_object", "test_option_object_route", "test_family_coverage", "test_section_annotation", "test_lod500_readiness", "test_scan_to_lod500", "test_egress_routes", "test_status_workflow_parity", "test_section_hatch", "test_section_keynotes", "test_detail_refs", "test_vg_overrides", "test_revit_export_cfg", "test_soft_clash", "test_sequence_clash", "test_element_tags", "test_cost_ifc", "test_fived", "test_health_consistency", "test_module_rooms", "test_modules_response_complete", "test_lifecycle_strip", "test_family_merge", "test_element_facts", "test_consistency", "test_work_queue", "test_task_bind", "test_qto_wire", "test_estimate_diff", "test_dim_constraints", "test_sov_build", "test_takeoff_scope", "test_r37_wire_routes", "test_r37_consolidate", "test_r37_contract", "test_export_promises", "test_pdf_ingest_gate", "test_roadmap_status", "test_claim_type", "test_risk_calibrate", "test_schedule_status", "test_engine_routes", "test_reachable", "test_money_wire", "test_license_gate", "test_license_lock_gate", "test_lock_advisories", "test_npm_advisories", "test_perf_budget", "test_perf_rate", "test_cache_key", "test_oauth_providers", "test_qto_measured_area", "test_lod_census", "test_lod_proxy", "test_model_ensure", "test_support_graph", "test_export_colour_stable", "test_stair_ramp", "test_profile_dims", "test_eot", "test_eot_methods", "test_eot_sourced", "test_shared_model", "test_plan_identity", "test_axon_view", "test_view_kind_dispatch", "test_photo_cv", "test_photo_detect", "test_photo_duplicate", "test_pipeline_scales", "test_plan_pins", "test_plan_cut_quality", "test_pins_unified", "test_index_freshness", "test_bake_budget", "test_geom_slots", "test_bake_shared", "test_geo_ref", "test_asset_verify", "test_folder_owner", "test_file_sizes", "test_declared_imports", "test_ruff_scope", "test_delete_ratchet", "test_doc_substance", "test_claude_md_gates", "test_cors_expose_headers", "test_open_redirect", "test_mp_engine", "test_upload_cap", "test_vitals", "test_samples", "test_bundle_index", + "test_scan_deviation", "test_plan_to_bim", "test_errorlog", "test_import_cycles", "test_tenant_scoping", "test_schedule_risk_single", "test_carbon_compliance", "test_permit_check", "test_drawing_qa", "test_element_5d", "test_authoring_matrix", "test_option_missing", "test_option_score", "test_plugin_registry", "test_jobs", "test_clash_federated_job", "test_inbox_jobs", "test_job_kind_labels", "test_worker_split", "test_job_orphan_scope", "test_job_stall", "test_pid_lock_xproc", "test_pid_lock_surface", "test_sheet_layout", "test_dim_component", "test_sheet_recover", "test_firm_standards", "test_site_context", "test_risk_board", "test_env_wind", "test_model_options", "test_doc_text", "test_escalation", "test_query_dsl", "test_rule_library", "test_schedule_baselines", "test_model_ci", "test_xlsx_roundtrip", "test_geometric_rules", "test_rebar_rules", "test_cx", "test_distwaterfall", "test_license_cloud", "test_smart_views", "test_view_delete", "test_version_approve_identity", "test_upload_streaming", "test_lod_aspects", "test_lod_element_table", "test_publish_reconvert", "test_model_cache_seed", "test_model_cache_mutation", "test_mutating_readers", "test_adopt_guid", "test_ifcpatch", "test_bcf_api", "test_coordination_fresh", "test_assemblies_cost", "test_fem_export", "test_subset_export", "test_norm_valid", "test_schema_diag", "test_revision_delta", "test_bep", "test_pm_close", "test_itp", "test_quality_chain", "test_quality_chain_route", "test_meeting_links", "test_est_bands", "test_scope_gap", "test_golden_thread", "test_clash_xml_import", "test_gis_out", "test_cbs", "test_mep_graph", "test_model_warnings", "test_schedule_options", "test_master_builder", "test_master_builder_scope", "test_get_commits", "test_project_pulse", "test_client_portal", "test_selections", "test_margin", "test_model_assets", "test_macros", "test_layout_options", "test_equipment", "test_space_util", "test_design_metrics", "test_mep_fittings", "test_prod_actuals", "test_pipeline_allocate", "test_production", "test_procure_level", "test_adjacency", "test_supply_chain", "test_invisible_unicode", "test_cited_answer", "test_est_confidence", "test_buyout_schedule", "test_scope_register", "test_permit_timeline", "test_absorption", "test_progress_rollup", "test_fill_matrix", "test_parcel_geometry", "test_assembly_thermal", "test_portal_txn", "test_persona_answer", "test_boe_ledger", "test_assumption_provenance", "test_assumption_provenance_route", "test_concept_budget", "test_topic_board", "test_roof_window", "test_topic_lifecycle", "test_comment_promote", "test_calc_fields", "test_constraints", "test_element_lookup", "test_cli", "test_view_templates", "test_type_catalogs", "test_password_policy", "test_stepup_single_verifier", "test_fin_gov", "test_fin_calc", "test_fin_ingest", "test_fin_portfolio", "test_level_move", "test_instance_props", "test_roundtrip", "test_wall_joins", "test_composite_family", "test_shared_params", "test_version_values", "test_ifcpatch_transforms", "test_bcf3", "test_energy_export", "test_net_effective", "test_cre_deal_desk", "test_cre_governance", "test_cre_tier3", "test_family_geometry", "test_demo_seed", "test_cost_spine", "test_commercial_drift", "test_family_shapes", "test_workflow_config", "test_option_takeoff", "test_option_carbon", "test_option_carbon_route", "test_option_economics", "test_option_economics_route", "test_option_object", "test_option_object_route", "test_family_coverage", "test_section_annotation", "test_lod500_readiness", "test_scan_to_lod500", "test_egress_routes", "test_status_workflow_parity", "test_section_hatch", "test_section_keynotes", "test_detail_refs", "test_vg_overrides", "test_revit_export_cfg", "test_soft_clash", "test_sequence_clash", "test_element_tags", "test_cost_ifc", "test_fived", "test_health_consistency", "test_module_rooms", "test_modules_response_complete", "test_lifecycle_strip", "test_family_merge", "test_element_facts", "test_consistency", "test_work_queue", "test_task_bind", "test_qto_wire", "test_estimate_diff", "test_dim_constraints", "test_sov_build", "test_takeoff_scope", "test_r37_wire_routes", "test_r37_consolidate", "test_r37_contract", "test_export_promises", "test_pdf_ingest_gate", "test_roadmap_status", "test_claim_type", "test_risk_calibrate", "test_schedule_status", "test_engine_routes", "test_reachable", "test_money_wire", "test_license_gate", "test_license_lock_gate", "test_lock_advisories", "test_npm_advisories", "test_perf_budget", "test_perf_rate", "test_cache_key", "test_oauth_providers", "test_qto_measured_area", "test_lod_census", "test_lod_proxy", "test_model_ensure", "test_support_graph", "test_export_colour_stable", "test_stair_ramp", "test_profile_dims", "test_eot", "test_eot_methods", "test_eot_sourced", "test_shared_model", "test_plan_identity", "test_axon_view", "test_view_kind_dispatch", "test_photo_cv", "test_photo_detect", "test_photo_duplicate", "test_pipeline_scales", "test_plan_pins", "test_plan_cut_quality", "test_pins_unified", "test_index_freshness", "test_bake_budget", "test_geom_slots", "test_bake_shared", "test_geo_ref", "test_asset_verify", "test_folder_owner", "test_file_sizes", "test_declared_imports", "test_ruff_scope", "test_delete_ratchet", "test_doc_substance", "test_claude_md_gates", "test_cors_expose_headers", "test_open_redirect", "test_mp_engine", "test_upload_cap", "test_vitals", "test_samples", "test_bundle_index", # R41-TEST-RESIDUE — the residue sweep must never propose a database it does not own: "test_sweep_guard", # R23-DIGEST — the deterministic model digest and its two routes: diff --git a/services/api/src/aec_api/models.py b/services/api/src/aec_api/models.py index 424ae1b5..978e6c61 100644 --- a/services/api/src/aec_api/models.py +++ b/services/api/src/aec_api/models.py @@ -155,6 +155,11 @@ class RecordComment(Base): record_id: Mapped[str] = mapped_column(String, index=True) author: Mapped[str | None] = mapped_column(String, nullable=True) text: Mapped[str] = mapped_column(Text, nullable=False) + # R22-ENTITLEMENT ⑤ — the RFI/issue this comment was promoted into, if any. An agency review + # comment is the one input that has to LEAVE the thread: somebody must be assigned it and it must + # close. Nullable because promotion is a deliberate act, and the back-link is what makes it + # idempotent — a second promote 409s instead of minting a duplicate RFI for the same comment. + topic_id: Mapped[str | None] = mapped_column(String, nullable=True) created_at: Mapped[datetime] = mapped_column(DateTime(timezone=True), default=_now) diff --git a/services/api/src/aec_api/modules.py b/services/api/src/aec_api/modules.py index e9873dc7..1587c9b6 100644 --- a/services/api/src/aec_api/modules.py +++ b/services/api/src/aec_api/modules.py @@ -25,8 +25,8 @@ ) from sqlalchemy.orm import Session -from . import fin_gov, module_schema, rbac -from .models import EnumOption, RecordActivity, RecordComment +from . import audit, fin_gov, module_schema, rbac +from .models import EnumOption, RecordActivity, RecordComment, Topic # the read + workflow-evaluation base is a leaf over the registry (no writes, no cycles); re-exported # so every existing `modules.list_records` / `.available_actions` / … caller keeps working. @@ -462,8 +462,12 @@ def get_record(db: Session, key: str, project_id: str, rid: str) -> dict: ref_by_id = dict(ancestry) ids = [aid for aid, _ in ancestry] + [rid] rec["comments"] = sorted( - ({"author": cm.author, "text": cm.text, + ({"id": cm.id, "author": cm.author, "text": cm.text, "created_at": cm.created_at.isoformat() if cm.created_at else None, + # R22-ENTITLEMENT ⑤: present ONLY when promoted, so a caller cannot read `None` as "not + # yet" on a build that predates the column. `id` is exposed for the same reason promotion + # needs it — a comment nobody can address is a comment nobody can act on. + **({"topic_id": cm.topic_id} if cm.topic_id else {}), **({"inherited": True, "on_ref": ref_by_id[cm.record_id]} if cm.record_id != rid else {})} for cm in db.query(RecordComment).filter( @@ -933,6 +937,53 @@ def add_comment(db: Session, key: str, project_id: str, rid: str, text: str, return get_record(db, key, project_id, rid) +def promote_comment(db: Session, key: str, project_id: str, rid: str, cid: str, + author: str, kind: str = "rfi") -> dict: + """R22-ENTITLEMENT ⑤ — turn a review comment into an RFI/issue Topic somebody owns. + + **The gap this closes.** `RecordComment` had no outward link of any kind, so an agency's review + comment on an `entitlement` or `permit` was a text blob at the end of a thread: readable, and + impossible to assign, track or close. The ring's own remainder called this "comment-response + round-tripping into RFI/issue records", and the round trip was missing in the *outbound* + direction — ④ had already made comments survive a revision, which is the inbound half. + + Follows `promote_markup` exactly rather than inventing a second idiom: mint a `Topic`, carry the + source's identity into the description, copy the record's `element_guids` so the RFI lands on the + model, write the back-link, and audit. **The back-link is the idempotency**: a second promote of + the same comment 409s instead of minting a duplicate RFI, which is the failure mode a + "promote" button produces on every double-click. + """ + rec = get_record(db, key, project_id, rid) # 404 if the record is missing + cm = db.get(RecordComment, cid) + if not cm or cm.project_id != project_id or cm.module != key or cm.record_id != rid: + raise HTTPException(404, "no such comment on this record") + if cm.topic_id: + raise HTTPException(409, "comment already promoted") + if kind not in ("rfi", "issue"): + raise HTTPException(422, "kind must be rfi or issue") + + ref = rec.get("ref") or rid + title = (cm.text or "").strip().splitlines()[0][:80] or f"{key} {ref} review comment" + guids = rec.get("element_guids") or None + t = Topic(project_id=project_id, type=("rfi" if kind == "rfi" else "punch"), status="open", + author=author, title=title, + description=(f"Raised from a review comment on {key} {ref}" + + (f" by {cm.author}" if cm.author else "") + ".\n\n" + (cm.text or "")), + element_guids=guids) + db.add(t) + db.flush() + cm.topic_id = t.id + _log(db, project_id, key, rid, author, None, "comment.promote", + {"comment": cid, "topic": t.id, "kind": kind}) + audit.record(db, action="record.comment.promote", actor=author, method="POST", topic_id=t.id, + path=f"/projects/{project_id}/modules/{key}/{rid}/comments/{cid}/promote", + detail={"module": key, "record": rid, "comment": cid}) + db.commit() + return {"comment_id": cid, "topic": {"id": t.id, "type": t.type, "title": t.title, + "status": t.status, "element_guids": t.element_guids}, + "record": get_record(db, key, project_id, rid)} + + def iter_csv(db: Session, key: str, project_id: str, page: int = 1000): """Module record list → CSV, streamed in pages so a 200k-record module never materializes in one request (the previous single limit=100000 load was a memory/DoS vector). Yields CSV chunks.""" diff --git a/services/api/src/aec_api/routers/modules.py b/services/api/src/aec_api/routers/modules.py index ca0294d5..e59406b9 100644 --- a/services/api/src/aec_api/routers/modules.py +++ b/services/api/src/aec_api/routers/modules.py @@ -887,6 +887,19 @@ def add_comment(pid: str, key: str, rid: str, text: str = Body(..., embed=True), return mod_engine.add_comment(db, key, pid, rid, text, user) +@router.post("/projects/{pid}/modules/{key}/{rid}/comments/{cid}/promote", status_code=201) +def promote_comment(pid: str, key: str, rid: str, cid: str, kind: str = Body("rfi", embed=True), + db: Session = Depends(get_db), user: str = Depends(require_role("reviewer"))): + """R22-ENTITLEMENT ⑤ — promote a review comment into an RFI (or punch item) somebody owns. + + An agency's review comment is the one input that must leave the thread: it has to be assigned, + tracked and closed. Mints a Topic carrying the comment text, the source record's ref and its + `element_guids`, and writes a back-link so a second promote 409s rather than minting a duplicate. + Mirrors `POST /projects/{pid}/drawings/markup/{mid}/promote` rather than inventing a second idiom. + """ + return mod_engine.promote_comment(db, key, pid, rid, cid, user, kind) + + @router.post("/projects/{pid}/modules/{key}/{rid}/assign") def assign_record(pid: str, key: str, rid: str, assignee: str | None = Body(None, embed=True), db: Session = Depends(get_db), user: str = Depends(require_role("reviewer"))): diff --git a/services/api/test_comment_promote.py b/services/api/test_comment_promote.py new file mode 100644 index 00000000..4791d4a6 --- /dev/null +++ b/services/api/test_comment_promote.py @@ -0,0 +1,107 @@ +"""R22-ENTITLEMENT ⑤ — an agency review comment becomes an RFI somebody owns. + +`RecordComment` had no outward link of any kind: an agency's comment on an `entitlement` or `permit` +was a text blob at the end of a thread — readable, and impossible to assign, track or close. ④ had +already made comments survive a revision, which is the INBOUND half of "round-tripping"; this is the +outbound half the ring entry still listed as remaining. + +Follows `promote_markup` rather than inventing a second idiom, and the back-link is the idempotency: +a second promote 409s instead of minting a duplicate RFI for the same comment — the failure mode a +"promote" button produces on every double-click. + +Run: PYTHONPATH=src ./.venv/bin/python test_comment_promote.py""" +import os + +os.environ["DATABASE_URL"] = "sqlite:///./test_comment_promote.db" +os.environ["STORAGE_DIR"] = "./test_storage_comment_promote" +os.environ.pop("AEC_RBAC", None) +for _f in ("./test_comment_promote.db",): + if os.path.exists(_f): + os.remove(_f) + +from fastapi.testclient import TestClient # noqa: E402 + +from aec_api.main import app # noqa: E402 + +with TestClient(app) as c: + pid = c.post("/projects", json={"name": "Entitlement P"}).json()["id"] + rec = c.post(f"/projects/{pid}/modules/entitlement", + json={"data": {"subject": "Site plan review", "agency": "City Planning", + "application_type": "Site Plan"}}).json() + rid = rec["id"] + + # --- the comment exists and is addressable ------------------------------------------------- + # It was not, before this slice: the serialised comment carried author/text/created_at and no + # id, so nothing could name one comment out of a thread in order to act on it. + body = ("Provide a shade study for the north plaza before the hearing.\n" + "Ref: condition 14.") + c.post(f"/projects/{pid}/modules/entitlement/{rid}/comments", json={"text": body}) + got = c.get(f"/projects/{pid}/modules/entitlement/{rid}").json() + assert len(got["comments"]) == 1, got["comments"] + cid = got["comments"][0]["id"] + assert cid, "the comment must be addressable or it cannot be promoted" + assert "topic_id" not in got["comments"][0], "an unpromoted comment must not claim a topic" + + # --- promote → a real RFI carrying the comment and its source ------------------------------ + r = c.post(f"/projects/{pid}/modules/entitlement/{rid}/comments/{cid}/promote", + json={"kind": "rfi"}) + assert r.status_code == 201, (r.status_code, r.text) + out = r.json() + tid = out["topic"]["id"] + assert out["topic"]["type"] == "rfi", out["topic"] + assert out["topic"]["status"] == "open", out["topic"] + # The title is the comment's FIRST LINE, not the whole body: an RFI list is scanned, and a + # two-paragraph title is unreadable in it. + assert out["topic"]["title"] == "Provide a shade study for the north plaza before the hearing.", \ + out["topic"]["title"] + + # The description must carry the provenance — which record, and who said it. An RFI that does + # not name where it came from sends someone back to find the thread by hand. + topic = c.get(f"/projects/{pid}/topics/{tid}").json() + assert "entitlement" in topic["description"], topic["description"] + assert rec["ref"] in topic["description"], (rec["ref"], topic["description"]) + assert "shade study" in topic["description"], topic["description"] + + # --- the back-link is written, and it is what the UI reads --------------------------------- + got2 = c.get(f"/projects/{pid}/modules/entitlement/{rid}").json() + assert got2["comments"][0].get("topic_id") == tid, got2["comments"][0] + + # --- promoting the same comment twice is refused, not duplicated --------------------------- + # Without the back-link this mints a second RFI for one comment every time the button is + # pressed, and nothing downstream can tell the copies apart. + again = c.post(f"/projects/{pid}/modules/entitlement/{rid}/comments/{cid}/promote", json={}) + assert again.status_code == 409, (again.status_code, again.text) + assert len(c.get(f"/projects/{pid}/topics").json()) == 1, "a refused promote must mint nothing" + + # --- the element tie is carried, because an RFI belongs on the model ----------------------- + # GlobalId is the only identity that survives a reload, so the RFI has to reference the element + # rather than a viewer id; the record's own tie is the honest source for it. + rec2 = c.post(f"/projects/{pid}/modules/entitlement", + json={"data": {"subject": "Height variance", "agency": "City Planning", + "application_type": "Variance"}}).json() + rid2 = rec2["id"] + c.post(f"/projects/{pid}/modules/entitlement/{rid2}/elements", + json={"guids": ["1a2b3c4d5e6f7g8h9i0j1k"]}) + c.post(f"/projects/{pid}/modules/entitlement/{rid2}/comments", + json={"text": "Parapet exceeds the district limit."}) + cid2 = c.get(f"/projects/{pid}/modules/entitlement/{rid2}").json()["comments"][0]["id"] + r2 = c.post(f"/projects/{pid}/modules/entitlement/{rid2}/comments/{cid2}/promote", json={}) + assert r2.status_code == 201, (r2.status_code, r2.text) + assert r2.json()["topic"]["element_guids"] == ["1a2b3c4d5e6f7g8h9i0j1k"], r2.json()["topic"] + + # --- refusals: an unknown comment, and a kind nobody defined ------------------------------- + assert c.post(f"/projects/{pid}/modules/entitlement/{rid}/comments/nope/promote", + json={}).status_code == 404 + c.post(f"/projects/{pid}/modules/entitlement/{rid}/comments", json={"text": "Third round."}) + cid3 = [x for x in c.get(f"/projects/{pid}/modules/entitlement/{rid}").json()["comments"] + if not x.get("topic_id")][0]["id"] + bad = c.post(f"/projects/{pid}/modules/entitlement/{rid}/comments/{cid3}/promote", + json={"kind": "wishlist"}) + assert bad.status_code == 422, (bad.status_code, bad.text) + + # a comment on a DIFFERENT record must not be promotable through this record's path — the + # engine matches project+module+record, not the comment id alone. + cross = c.post(f"/projects/{pid}/modules/entitlement/{rid2}/comments/{cid3}/promote", json={}) + assert cross.status_code == 404, (cross.status_code, cross.text) + +print("test_comment_promote OK") diff --git a/services/api/test_file_sizes.py b/services/api/test_file_sizes.py index fa956542..1cfe755a 100644 --- a/services/api/test_file_sizes.py +++ b/services/api/test_file_sizes.py @@ -140,7 +140,7 @@ def check(label, ok, detail=""): # above records why the timing matters: "a ratchet added at the point of pain only ratifies the # 2_546 → 2_516 (v0.3.1000): the model-elements block moved to tiedElements.ts so the # lifecycle card could mount on every tied GUID without growing this file. - "apps/web/src/portal/register/register.ts": 2_516, + "apps/web/src/portal/register/register.ts": 2_505, # R22-ENTITLEMENT (5): the comment thread + composer + the new promote control -> portal/register/recordComments.ts (2_516 -> 2_505). The ratchet went red on the promote control and the remedy is the one this file states: extraction, never headroom. The block is a genuine leaf — it touches the record's comments, the API and a reload callback, and nothing else on the class — and it follows the directory's own convention (elementTies.ts, schemaStale.ts, tiedElements.ts are already extracted the same way). } #: Exempt because a human never reads them top-to-bottom. Name them, never infer them. From d826115838d89f2e7d94b0c6cc89c164a0aa3c59 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 4 Sep 2026 13:05:41 +0000 Subject: [PATCH 09/12] =?UTF-8?q?R22-ENTITLEMENT=20=E2=91=A4=20review:=20p?= =?UTF-8?q?romotion=20claims=20the=20comment=20atomically,=20and=20a=20bla?= =?UTF-8?q?nk=20one=20no=20longer=20500s?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Two findings on #434, both reproduced before fixing and both mutation-checked after. **A whitespace-only comment 500s on promote.** The comment route takes `text: str = Body(...)` with no min-length, so `{"text": " \n "}` is a 201. Promoting it ran `.strip().splitlines()[0]` over an empty list — IndexError. The `or f"{key} {ref} review comment"` fallback written for exactly this case had never been reachable at all: when the list is non-empty its first element is never blank, so the `or` arm could not fire. The guard makes it live. **Promotion idempotency was not atomic — and the damage is worse than a duplicate.** `SessionLocal` is `expire_on_commit=False`, so a request that read the comment before a concurrent promote committed keeps seeing a null back-link for as long as it holds the session; the `if cm.topic_id` guard reads that stale copy. A plain assignment then let the later writer overwrite the back-link, minting a second RFI AND orphaning the first, whose Topic no comment pointed at any more. The claim is now a conditional `UPDATE ... WHERE topic_id IS NULL`: under Postgres read-committed the loser blocks on the winner's row lock and re-evaluates the predicate against the committed row; under SQLite the writes serialize to the same effect. Rolling back discards the Topic flushed a moment earlier, so a losing promote leaves nothing behind. The race test is deterministic rather than timing-dependent — the loser reads, the winner commits, the loser proceeds from its stale identity map, which is the production sequence. Mutation-checked both ways: restoring the unguarded index raises IndexError, restoring the plain assignment fails "a stale-read promote must be refused, not duplicated". Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Tt2XKB83wwNt2nrMbK6eEA --- services/api/src/aec_api/modules.py | 20 +++++++++-- services/api/test_comment_promote.py | 54 ++++++++++++++++++++++++++++ 2 files changed, 72 insertions(+), 2 deletions(-) diff --git a/services/api/src/aec_api/modules.py b/services/api/src/aec_api/modules.py index 1587c9b6..e95dadf0 100644 --- a/services/api/src/aec_api/modules.py +++ b/services/api/src/aec_api/modules.py @@ -963,7 +963,12 @@ def promote_comment(db: Session, key: str, project_id: str, rid: str, cid: str, raise HTTPException(422, "kind must be rfi or issue") ref = rec.get("ref") or rid - title = (cm.text or "").strip().splitlines()[0][:80] or f"{key} {ref} review comment" + # `splitlines()` on stripped whitespace-only text yields [], so `[0]` raised IndexError — a 500 + # on a comment the comment route itself accepts (`text: str = Body(...)` has no min-length). The + # fallback title below was written for exactly this case and was unreachable until now: when the + # list is non-empty its first element is never blank, so the `or` arm could never fire. + lines = (cm.text or "").strip().splitlines() + title = lines[0][:80] if lines else f"{key} {ref} review comment" guids = rec.get("element_guids") or None t = Topic(project_id=project_id, type=("rfi" if kind == "rfi" else "punch"), status="open", author=author, title=title, @@ -972,7 +977,18 @@ def promote_comment(db: Session, key: str, project_id: str, rid: str, cid: str, element_guids=guids) db.add(t) db.flush() - cm.topic_id = t.id + # The `cm.topic_id` check above cannot be the last word: two requests each hold their own session, + # each read a null back-link, and a plain assignment lets the later commit overwrite the earlier + # one — minting a duplicate RFI *and* orphaning the first, whose Topic no comment then points at. + # The claim is therefore a conditional UPDATE. Under Postgres read-committed the loser blocks on + # the winner's row lock, then re-evaluates `topic_id IS NULL` against the committed row and + # matches nothing; under SQLite the writes serialize to the same effect. Rolling back discards + # the Topic flushed a moment ago, so a losing promote leaves nothing behind. + if not db.execute(update(RecordComment) + .where(RecordComment.id == cid, RecordComment.topic_id.is_(None)) + .values(topic_id=t.id)).rowcount: + db.rollback() + raise HTTPException(409, "comment already promoted") _log(db, project_id, key, rid, author, None, "comment.promote", {"comment": cid, "topic": t.id, "kind": kind}) audit.record(db, action="record.comment.promote", actor=author, method="POST", topic_id=t.id, diff --git a/services/api/test_comment_promote.py b/services/api/test_comment_promote.py index 4791d4a6..99cd66f4 100644 --- a/services/api/test_comment_promote.py +++ b/services/api/test_comment_promote.py @@ -19,9 +19,13 @@ if os.path.exists(_f): os.remove(_f) +from fastapi import HTTPException # noqa: E402 from fastapi.testclient import TestClient # noqa: E402 +from aec_api import modules as mod_engine # noqa: E402 +from aec_api.db import SessionLocal # noqa: E402 from aec_api.main import app # noqa: E402 +from aec_api.models import RecordComment # noqa: E402 with TestClient(app) as c: pid = c.post("/projects", json={"name": "Entitlement P"}).json()["id"] @@ -104,4 +108,54 @@ cross = c.post(f"/projects/{pid}/modules/entitlement/{rid2}/comments/{cid3}/promote", json={}) assert cross.status_code == 404, (cross.status_code, cross.text) + # --- a whitespace-only comment promotes to the fallback title, it does not 500 --------------- + # The comment route takes `text: str = Body(...)` with no min-length, so " \n " is a 201. + # Promoting it ran `.strip().splitlines()[0]` over an empty list — IndexError, 500, and the + # fallback title written for exactly this case never fired. + rec3 = c.post(f"/projects/{pid}/modules/entitlement", + json={"data": {"subject": "Blank", "agency": "City Planning", + "application_type": "Site Plan"}}).json() + rid3 = rec3["id"] + assert c.post(f"/projects/{pid}/modules/entitlement/{rid3}/comments", + json={"text": " \n "}).status_code == 201 + cid4 = c.get(f"/projects/{pid}/modules/entitlement/{rid3}").json()["comments"][0]["id"] + blank = c.post(f"/projects/{pid}/modules/entitlement/{rid3}/comments/{cid4}/promote", json={}) + assert blank.status_code == 201, (blank.status_code, blank.text) + assert blank.json()["topic"]["title"] == f"entitlement {rec3['ref']} review comment", \ + blank.json()["topic"]["title"] + + # --- two sessions that both read a null back-link: exactly one promote survives ------------- + # The `if cm.topic_id` guard reads the SESSION's copy, and `SessionLocal` is + # `expire_on_commit=False`, so a request that loaded the comment before a concurrent promote + # committed still sees None however long it holds it. A plain assignment therefore let the later + # writer overwrite the back-link — minting a duplicate RFI AND orphaning the first, whose Topic + # no comment pointed at any more. The claim is a conditional UPDATE; this is the loser's path. + rec4 = c.post(f"/projects/{pid}/modules/entitlement", + json={"data": {"subject": "Race", "agency": "City Planning", + "application_type": "Site Plan"}}).json() + rid4 = rec4["id"] + c.post(f"/projects/{pid}/modules/entitlement/{rid4}/comments", + json={"text": "Two reviewers pressed promote at once."}) + cid5 = c.get(f"/projects/{pid}/modules/entitlement/{rid4}").json()["comments"][0]["id"] + + before = len(c.get(f"/projects/{pid}/topics").json()) + loser, winner = SessionLocal(), SessionLocal() + stale = loser.get(RecordComment, cid5) # the loser reads first: topic_id is None + assert stale.topic_id is None + won = mod_engine.promote_comment(winner, "entitlement", pid, rid4, cid5, "winner", "rfi") + assert stale.topic_id is None, "the loser's session still holds the pre-promote read" + try: + mod_engine.promote_comment(loser, "entitlement", pid, rid4, cid5, "loser", "rfi") + raise AssertionError("a stale-read promote must be refused, not duplicated") + except HTTPException as e: + assert e.status_code == 409, e.status_code + loser.close() + winner.close() + + # and the loser left nothing behind: one new Topic, still pointed at by the comment. + assert len(c.get(f"/projects/{pid}/topics").json()) == before + 1, "the loser minted an orphan" + linked = [x for x in c.get(f"/projects/{pid}/modules/entitlement/{rid4}").json()["comments"] + if x["id"] == cid5][0] + assert linked["topic_id"] == won["topic"]["id"], (linked, won["topic"]["id"]) + print("test_comment_promote OK") From c437a7f8ab11cb75fce9ad408f6b7ad688855763 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 4 Sep 2026 13:41:21 +0000 Subject: [PATCH 10/12] =?UTF-8?q?R24-REPORTS-BY-MOMENT=20=E2=80=94=20a=20f?= =?UTF-8?q?inished=20pack=20can=20be=20sent,=20not=20only=20downloaded?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `POST /projects/{pid}/jobs/{job_id}/deliver` emails any finished job's artifact to named recipients, surfaced as **Send** beside **Download** in the job tray. **The roadmap named the wrong blocker, one layer too high.** The entry said making a pack a scheduled deliverable "still wants a delivery surface and SMTP". Both already existed when that was written: `mailer.py` sends real mail (stdlib smtplib, a Settings "Test connection" button), and `POST …/notifications/digest` is a working assemble-then-send surface returning a per-recipient status map. What was actually missing was one size smaller — **the mailer could not carry a file**. That is why the entry sat: the two things it named were present, so every look confirmed it and nobody checked the layer below. `build_message` gained attachments. The ORDER is load-bearing: `add_alternative` must run before `add_attachment`, or the html body lands inside the mixed part — Python's EmailMessage refuses outright ("Cannot convert mixed to alternative"), which the test asserts rather than assumes. Refusals mirror the download route exactly (404 wrong project, 409 while queued/running, 404 with no artifact) so a caller does not learn two answers to "is this artifact ready", plus two of delivery's own: an empty recipient list is 422 rather than a silent success, and over 15 MB is 413 rather than a per-recipient error from a server that would have bounced it anyway. An unconfigured deployment returns 200 with every recipient `disabled`, so the UI reads `smtp_configured` before claiming a send. The delivery is audited — a file leaving the system is what an audit log is for. **Not shipped, deliberately: the SCHEDULED half.** There is no scheduler of any kind in this tree — no APScheduler, no croniter, no cron — so the existing digest is admin-triggered and nothing runs on a date. Choosing in-process versus external cron hitting an endpoint is a deployment decision with different operational consequences, not a wiring task. The roadmap now says that instead of naming two things that already ship. Mutation-checked, four ways on the route and one on the tray: dropping the empty-recipient refusal reproduces the silent success it exists to prevent (200 with `"results":{}`); dropping the size cap admits 15 MB + 1; ignoring attachments loses the file; attaching before the alternative raises; and ungating Send from `hasArtifact` offers it on a job with nothing to send. The client-caller gate did its job here — it failed the build because `deliverJobArtifact` had no screen, which is what drove the job-tray wiring rather than shipping another endpoint nobody can reach. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Tt2XKB83wwNt2nrMbK6eEA --- CHANGELOG.md | 22 +++++ apps/web/public/wasm/web-ifc-mt.wasm | Bin apps/web/public/wasm/web-ifc.wasm | Bin apps/web/src/api/routines.ts | 10 ++ apps/web/src/api/surface.test.ts | 2 +- apps/web/src/main.ts | 17 ++++ apps/web/src/ui/jobTray.test.ts | 28 ++++++ apps/web/src/ui/jobTray.ts | 20 ++++ docs/roadmap.md | 18 +++- services/api/run_tests.py | 2 +- services/api/src/aec_api/mailer.py | 19 +++- services/api/src/aec_api/routers/jobs.py | 61 +++++++++++- services/api/test_artifact_deliver.py | 121 +++++++++++++++++++++++ 13 files changed, 309 insertions(+), 11 deletions(-) mode change 100644 => 100755 apps/web/public/wasm/web-ifc-mt.wasm mode change 100644 => 100755 apps/web/public/wasm/web-ifc.wasm create mode 100644 services/api/test_artifact_deliver.py diff --git a/CHANGELOG.md b/CHANGELOG.md index c7e50d2b..279a1e66 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,6 +4,28 @@ All notable changes to Massing. Releases are signed, auto-updating desktop build (Windows / macOS / Linux); the updater always serves the latest. Format loosely follows [Keep a Changelog](https://keepachangelog.com/). +## Unreleased — R24-REPORTS-BY-MOMENT: a finished pack can be sent, not only downloaded + +`POST /projects/{pid}/jobs/{job_id}/deliver` emails any finished job's artifact to named +recipients, surfaced as **Send** beside **Download** in the job tray. + +**The roadmap named the wrong blocker, one layer too high.** It said this "still wants a delivery +surface and SMTP" — both of which already shipped: `mailer.py` sends real mail, and the notification +digest is a working assemble-then-send surface. What was actually missing was smaller and more +specific: **the mailer could not carry a file**. `build_message` gained attachments, and the order +matters — `add_alternative` must run before `add_attachment` or Python refuses outright, which the +test asserts rather than assumes. + +Refusals mirror the download route exactly (404 wrong project, 409 while queued/running, 404 with no +artifact), so a caller does not learn two answers to "is this artifact ready", plus two of its own: +an empty recipient list is 422 rather than a silent success, and over 15 MB is 413 rather than a +per-recipient error from a server that would have bounced it. A deployment with no SMTP configured +returns 200 with every recipient `disabled`, so the UI reads `smtp_configured` before claiming a +send. The delivery is audited — a file leaving the system is what an audit log is for. + +**Not shipped, deliberately: the SCHEDULED half.** There is no scheduler of any kind in this tree, +so choosing in-process versus external cron is a deployment decision, not a wiring task. + ## v0.3.1143 (2026-09-01) — SCALE-SEAM ㉝, Last-Planner onto schedule.ts Six methods out of `client.ts` into the existing `apps/web/src/api/schedule.ts` mixin diff --git a/apps/web/public/wasm/web-ifc-mt.wasm b/apps/web/public/wasm/web-ifc-mt.wasm old mode 100644 new mode 100755 diff --git a/apps/web/public/wasm/web-ifc.wasm b/apps/web/public/wasm/web-ifc.wasm old mode 100644 new mode 100755 diff --git a/apps/web/src/api/routines.ts b/apps/web/src/api/routines.ts index 8bdda385..1aab3382 100644 --- a/apps/web/src/api/routines.ts +++ b/apps/web/src/api/routines.ts @@ -115,5 +115,15 @@ export function withRoutines>(Base: TBase) { jobArtifactUrl(pid: string, jobId: string): string { return this.url(`/projects/${pid}/jobs/${jobId}/artifact`); } + /** R24-REPORTS-BY-MOMENT — mail a finished job's artifact to recipients: the "shared, not just + * downloaded" half. Same refusals as the artifact URL above (404 / 409 while running / 404 with + * no artifact), plus 422 on no recipients and 413 over the 15 MB cap. On a deployment with no + * SMTP configured this SUCCEEDS with every recipient reported `disabled` — check + * `smtp_configured` before telling the user it was sent. */ + deliverJobArtifact(pid: string, jobId: string, to: string[], note = "") { + return this.json<{ smtp_configured: boolean; filename: string; bytes: number; + results: Record }>( + `/projects/${pid}/jobs/${jobId}/deliver`, { method: "POST", body: JSON.stringify({ to, note }) }); + } }; } diff --git a/apps/web/src/api/surface.test.ts b/apps/web/src/api/surface.test.ts index 058563ae..59282383 100644 --- a/apps/web/src/api/surface.test.ts +++ b/apps/web/src/api/surface.test.ts @@ -205,7 +205,7 @@ describe("the API client's public surface", () => { "escalationsScan", "sendDigest", "notificationStream", // 18 overdue / digest "reviewModelVersion", "modelVersions", "versionDiff", // 19 publish history "importClashXlsx", "importClashXml", // 20 clash import - "enqueueJob", "jobs", "jobArtifactUrl", // 21 job tray + "enqueueJob", "jobs", "jobArtifactUrl", "deliverJobArtifact", // 21 job tray "projects", "createProject", "importBundle", // 22 project catalog "integrations", "license", "capabilities", // 23 deploy entitle "siteContext", "parcelAnalyze", "parcelsScreen", // 24 land around site diff --git a/apps/web/src/main.ts b/apps/web/src/main.ts index 0fe22741..7db55cc4 100644 --- a/apps/web/src/main.ts +++ b/apps/web/src/main.ts @@ -2171,6 +2171,23 @@ const _jobs = _embed ? null : mountJobTray({ host: toolbar, fetch: () => (projectId ? api.jobs(projectId, 25) : Promise.resolve([])), artifactUrl: (j) => api.jobArtifactUrl(projectId!, j.id), + // R24-REPORTS-BY-MOMENT — "shared, not just downloaded". `prompt` rather than a modal on purpose: + // the recipient list is the whole input, and a dialog for one text field is chrome. An + // unconfigured deployment answers 200 with every recipient `disabled`, which is why the notice + // below reads `smtp_configured` instead of assuming a 200 means the mail went. + onSend: (j) => { + const to = window.prompt("Email this artifact to (comma-separated addresses):", ""); + if (to === null) return; + const addrs = to.split(",").map((a) => a.trim()).filter(Boolean); + if (!addrs.length) { notify("No recipients — nothing sent.", "error"); return; } + void api.deliverJobArtifact(projectId!, j.id, addrs) + .then((r) => notify( + r.smtp_configured + ? `${r.filename} sent to ${(r.results.sent ?? []).length} of ${addrs.length}` + : "Email is not configured on this server — nothing was sent.", + r.smtp_configured && (r.results.sent ?? []).length ? "success" : "error")) + .catch((e: Error) => notify(`Send failed — ${e.message}`, "error")); + }, // The completion notice is the point of the tray: it is what makes leaving safe. onSettled: (j) => notify( j.state === "error" ? `${jobLabel(j.kind)} failed — ${j.error ?? "no detail"}` : `${jobLabel(j.kind)} finished`, diff --git a/apps/web/src/ui/jobTray.test.ts b/apps/web/src/ui/jobTray.test.ts index 574181fc..c7d05263 100644 --- a/apps/web/src/ui/jobTray.test.ts +++ b/apps/web/src/ui/jobTray.test.ts @@ -305,4 +305,32 @@ describe("the tray is actually reachable", () => { document.dispatchEvent(new KeyboardEvent("keydown", { key: "Escape" })); expect(btn().getAttribute("aria-expanded")).toBe("false"); }); + + /** + * R24-REPORTS-BY-MOMENT — the send affordance is gated on there being a file, exactly like the + * download link beside it. Asserted rather than assumed because the two gates are written + * separately, and a "Send" on a running job offers to mail something that does not exist yet. + */ + it("offers Send only on rows that actually have an artifact", () => { + const host = document.createElement("div"); + const sent: string[] = []; + renderJobTray(host, [ + J({ id: "running", state: "running" }), + J({ id: "noart", state: "done", result: {} }), + J({ id: "ready", state: "done", result: { artifact_key: "k" } }), + ], { onSend: (j) => sent.push(j.id) }); + + const buttons = [...host.querySelectorAll("button")].filter((b) => b.textContent === "Send"); + expect(buttons.length).toBe(1); + buttons[0]!.click(); + expect(sent).toEqual(["ready"]); + }); + + /** Omitting `onSend` must offer no button at all — the same contract `artifactUrl` already has, + * so a host that cannot deliver does not show a control that would throw. */ + it("offers no Send affordance when onSend is omitted", () => { + const host = document.createElement("div"); + renderJobTray(host, [J({ state: "done", result: { artifact_key: "k" } })], {}); + expect([...host.querySelectorAll("button")].some((b) => b.textContent === "Send")).toBe(false); + }); }); diff --git a/apps/web/src/ui/jobTray.ts b/apps/web/src/ui/jobTray.ts index 0c3c92e9..d46b15ef 100644 --- a/apps/web/src/ui/jobTray.ts +++ b/apps/web/src/ui/jobTray.ts @@ -137,6 +137,9 @@ const STATE_COLOR: Record = { export interface JobTrayOpts { /** Absolute href for a finished job's artifact. Omitted → no download affordance is offered. */ artifactUrl?: (j: Job) => string; + /** R24-REPORTS-BY-MOMENT — mail a finished artifact to recipients ("shared, not just + * downloaded"). Omitted → no send affordance, exactly like `artifactUrl`. */ + onSend?: (j: Job) => void; /** Remove a finished/failed row from view. Client-side only — the server keeps its history. */ onDismiss?: (j: Job) => void; } @@ -206,6 +209,20 @@ export function renderJobTray(host: HTMLElement, jobs: readonly Job[], opts: Job row.appendChild(a); } + // Sending sits beside downloading because they answer the same question — "the pack is ready, + // now what" — and a report pack that can only be downloaded still has to be forwarded by hand. + // Gated on `hasArtifact` for the same reason the link is: there is nothing to send until there + // is a file. + if (opts.onSend && hasArtifact(j)) { + const b = document.createElement("button"); + b.type = "button"; + b.textContent = "Send"; + b.title = "Email this artifact to recipients"; + b.style.cssText = "font-size:11px;flex:0 0 auto"; + b.onclick = () => opts.onSend!(j); + row.appendChild(b); + } + // Only finished rows can be dismissed. Hiding a running job would leave work in flight with no // way back to it, which is the exact failure the tray exists to fix. if (opts.onDismiss && !isActive(j)) { @@ -312,6 +329,8 @@ export function mountJobTray(opts: { host: HTMLElement; fetch: () => Promise; artifactUrl?: (j: Job) => string; + /** R24-REPORTS-BY-MOMENT — see JobTrayOpts.onSend. Passed straight through to each row. */ + onSend?: (j: Job) => void; onSettled?: (j: Job) => void; /** * R24-RUNS-INBOX — open the run history. A footer row rather than a header button, because the @@ -359,6 +378,7 @@ export function mountJobTray(opts: { if (!panel.hidden) { renderJobTray(panel, shown, { artifactUrl: opts.artifactUrl, + onSend: opts.onSend, onDismiss: (j) => { dismissed.add(j.id); draw(); }, }); if (opts.onHistory) { diff --git a/docs/roadmap.md b/docs/roadmap.md index 70424536..c9d4b679 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -2062,10 +2062,20 @@ refute one, so this goes first even though it is the least visible. heading below. `reportMoments.test.ts` reads `reports.py` and fails the build if a package names an id the server no longer defines; without that, a renamed report shortens a package silently on the Friday it is due. - **Still open: "scheduled and shared, not just downloaded."** Assemble is a job - (`report_package` in `services/api/src/aec_api/jobs.py`, **Assemble** in `apps/web/src/reportCenter.ts`). - Making it a *scheduled deliverable* — sent to a recipient on a date — still wants a delivery surface - and SMTP. The Job row is already the record that a pack ran. + **SHARED shipped; SCHEDULED still open — and the blocker was never the one written here.** This + entry said making a pack a scheduled deliverable "still wants a delivery surface and SMTP". + **Both already existed** when that was written: `services/api/src/aec_api/mailer.py` sends real mail + (stdlib `smtplib`, a Settings "Test connection" button), and `POST …/notifications/digest` is a + working assemble-then-send surface returning a per-recipient status map. What was actually missing + was one size smaller — **the mailer could not carry a file**. `POST …/jobs/{job_id}/deliver` now + mails any finished job's artifact (`services/api/test_artifact_deliver.py`), surfaced as **Send** + beside **Download** in the job tray. *Naming the blocker one layer too high is what let it sit: the + two named things were present, so every look confirmed the entry and nobody checked the layer below.* + **What genuinely remains is SCHEDULED, and it needs a runner.** There is no scheduler of any kind in + this tree — no APScheduler, no croniter, no cron — so the existing digest is admin-triggered and + nothing runs on a date. Choosing in-process versus external cron hitting an endpoint is a + **deployment decision with different operational consequences, not a wiring task**, which is why it + is not taken here. The Job row is already the record that a pack ran. - **R24-TERMS** *(S)* — the remaining long tail (element/component and estimate/budget/cost pairs are a user decision; storey/floor settled v0.3.945). diff --git a/services/api/run_tests.py b/services/api/run_tests.py index d3db2341..5db23956 100644 --- a/services/api/run_tests.py +++ b/services/api/run_tests.py @@ -86,7 +86,7 @@ "test_markup", "test_route_authz", "test_resource_id_authz", "test_route_reachability", "test_resumable_upload", "test_model_align", "test_ifc_parse_gate", "test_plugin_isolation", "test_body_pid_authz", "test_global_authz", "test_protected_prefix_coverage", "test_baseline", "test_global_mutating_authz", "test_ref_counter", "test_audit_coverage", "test_bsdd", "test_openbim_registry", "test_waterfall", "test_waterfall_cents", "test_sessions", "test_mfa", "test_stored_ids", "test_cobie", "test_fts_index", "test_scim", "test_scim_provision_race", "test_saml", "test_responsibility", "test_array_live", "test_assemblies", "test_dxf_takeoff", "test_qto_class_match", "test_georef", "test_scene_package", "test_clash_bvh", "test_model_qa", "test_model_health", "test_roundtrip_qa", "test_stakeholder", "test_prioritization", "test_ai_readiness", - "test_scan_deviation", "test_plan_to_bim", "test_errorlog", "test_import_cycles", "test_tenant_scoping", "test_schedule_risk_single", "test_carbon_compliance", "test_permit_check", "test_drawing_qa", "test_element_5d", "test_authoring_matrix", "test_option_missing", "test_option_score", "test_plugin_registry", "test_jobs", "test_clash_federated_job", "test_inbox_jobs", "test_job_kind_labels", "test_worker_split", "test_job_orphan_scope", "test_job_stall", "test_pid_lock_xproc", "test_pid_lock_surface", "test_sheet_layout", "test_dim_component", "test_sheet_recover", "test_firm_standards", "test_site_context", "test_risk_board", "test_env_wind", "test_model_options", "test_doc_text", "test_escalation", "test_query_dsl", "test_rule_library", "test_schedule_baselines", "test_model_ci", "test_xlsx_roundtrip", "test_geometric_rules", "test_rebar_rules", "test_cx", "test_distwaterfall", "test_license_cloud", "test_smart_views", "test_view_delete", "test_version_approve_identity", "test_upload_streaming", "test_lod_aspects", "test_lod_element_table", "test_publish_reconvert", "test_model_cache_seed", "test_model_cache_mutation", "test_mutating_readers", "test_adopt_guid", "test_ifcpatch", "test_bcf_api", "test_coordination_fresh", "test_assemblies_cost", "test_fem_export", "test_subset_export", "test_norm_valid", "test_schema_diag", "test_revision_delta", "test_bep", "test_pm_close", "test_itp", "test_quality_chain", "test_quality_chain_route", "test_meeting_links", "test_est_bands", "test_scope_gap", "test_golden_thread", "test_clash_xml_import", "test_gis_out", "test_cbs", "test_mep_graph", "test_model_warnings", "test_schedule_options", "test_master_builder", "test_master_builder_scope", "test_get_commits", "test_project_pulse", "test_client_portal", "test_selections", "test_margin", "test_model_assets", "test_macros", "test_layout_options", "test_equipment", "test_space_util", "test_design_metrics", "test_mep_fittings", "test_prod_actuals", "test_pipeline_allocate", "test_production", "test_procure_level", "test_adjacency", "test_supply_chain", "test_invisible_unicode", "test_cited_answer", "test_est_confidence", "test_buyout_schedule", "test_scope_register", "test_permit_timeline", "test_absorption", "test_progress_rollup", "test_fill_matrix", "test_parcel_geometry", "test_assembly_thermal", "test_portal_txn", "test_persona_answer", "test_boe_ledger", "test_assumption_provenance", "test_assumption_provenance_route", "test_concept_budget", "test_topic_board", "test_roof_window", "test_topic_lifecycle", "test_comment_promote", "test_calc_fields", "test_constraints", "test_element_lookup", "test_cli", "test_view_templates", "test_type_catalogs", "test_password_policy", "test_stepup_single_verifier", "test_fin_gov", "test_fin_calc", "test_fin_ingest", "test_fin_portfolio", "test_level_move", "test_instance_props", "test_roundtrip", "test_wall_joins", "test_composite_family", "test_shared_params", "test_version_values", "test_ifcpatch_transforms", "test_bcf3", "test_energy_export", "test_net_effective", "test_cre_deal_desk", "test_cre_governance", "test_cre_tier3", "test_family_geometry", "test_demo_seed", "test_cost_spine", "test_commercial_drift", "test_family_shapes", "test_workflow_config", "test_option_takeoff", "test_option_carbon", "test_option_carbon_route", "test_option_economics", "test_option_economics_route", "test_option_object", "test_option_object_route", "test_family_coverage", "test_section_annotation", "test_lod500_readiness", "test_scan_to_lod500", "test_egress_routes", "test_status_workflow_parity", "test_section_hatch", "test_section_keynotes", "test_detail_refs", "test_vg_overrides", "test_revit_export_cfg", "test_soft_clash", "test_sequence_clash", "test_element_tags", "test_cost_ifc", "test_fived", "test_health_consistency", "test_module_rooms", "test_modules_response_complete", "test_lifecycle_strip", "test_family_merge", "test_element_facts", "test_consistency", "test_work_queue", "test_task_bind", "test_qto_wire", "test_estimate_diff", "test_dim_constraints", "test_sov_build", "test_takeoff_scope", "test_r37_wire_routes", "test_r37_consolidate", "test_r37_contract", "test_export_promises", "test_pdf_ingest_gate", "test_roadmap_status", "test_claim_type", "test_risk_calibrate", "test_schedule_status", "test_engine_routes", "test_reachable", "test_money_wire", "test_license_gate", "test_license_lock_gate", "test_lock_advisories", "test_npm_advisories", "test_perf_budget", "test_perf_rate", "test_cache_key", "test_oauth_providers", "test_qto_measured_area", "test_lod_census", "test_lod_proxy", "test_model_ensure", "test_support_graph", "test_export_colour_stable", "test_stair_ramp", "test_profile_dims", "test_eot", "test_eot_methods", "test_eot_sourced", "test_shared_model", "test_plan_identity", "test_axon_view", "test_view_kind_dispatch", "test_photo_cv", "test_photo_detect", "test_photo_duplicate", "test_pipeline_scales", "test_plan_pins", "test_plan_cut_quality", "test_pins_unified", "test_index_freshness", "test_bake_budget", "test_geom_slots", "test_bake_shared", "test_geo_ref", "test_asset_verify", "test_folder_owner", "test_file_sizes", "test_declared_imports", "test_ruff_scope", "test_delete_ratchet", "test_doc_substance", "test_claude_md_gates", "test_cors_expose_headers", "test_open_redirect", "test_mp_engine", "test_upload_cap", "test_vitals", "test_samples", "test_bundle_index", + "test_scan_deviation", "test_plan_to_bim", "test_errorlog", "test_import_cycles", "test_tenant_scoping", "test_schedule_risk_single", "test_carbon_compliance", "test_permit_check", "test_drawing_qa", "test_element_5d", "test_authoring_matrix", "test_option_missing", "test_option_score", "test_plugin_registry", "test_jobs", "test_clash_federated_job", "test_inbox_jobs", "test_job_kind_labels", "test_worker_split", "test_job_orphan_scope", "test_job_stall", "test_pid_lock_xproc", "test_pid_lock_surface", "test_sheet_layout", "test_dim_component", "test_sheet_recover", "test_firm_standards", "test_site_context", "test_risk_board", "test_env_wind", "test_model_options", "test_doc_text", "test_escalation", "test_query_dsl", "test_rule_library", "test_schedule_baselines", "test_model_ci", "test_xlsx_roundtrip", "test_geometric_rules", "test_rebar_rules", "test_cx", "test_distwaterfall", "test_license_cloud", "test_smart_views", "test_view_delete", "test_version_approve_identity", "test_upload_streaming", "test_lod_aspects", "test_lod_element_table", "test_publish_reconvert", "test_model_cache_seed", "test_model_cache_mutation", "test_mutating_readers", "test_adopt_guid", "test_ifcpatch", "test_bcf_api", "test_coordination_fresh", "test_assemblies_cost", "test_fem_export", "test_subset_export", "test_norm_valid", "test_schema_diag", "test_revision_delta", "test_bep", "test_pm_close", "test_itp", "test_quality_chain", "test_quality_chain_route", "test_meeting_links", "test_est_bands", "test_scope_gap", "test_golden_thread", "test_clash_xml_import", "test_gis_out", "test_cbs", "test_mep_graph", "test_model_warnings", "test_schedule_options", "test_master_builder", "test_master_builder_scope", "test_get_commits", "test_project_pulse", "test_client_portal", "test_selections", "test_margin", "test_model_assets", "test_macros", "test_layout_options", "test_equipment", "test_space_util", "test_design_metrics", "test_mep_fittings", "test_prod_actuals", "test_pipeline_allocate", "test_production", "test_procure_level", "test_adjacency", "test_supply_chain", "test_invisible_unicode", "test_cited_answer", "test_est_confidence", "test_buyout_schedule", "test_scope_register", "test_permit_timeline", "test_absorption", "test_progress_rollup", "test_fill_matrix", "test_parcel_geometry", "test_assembly_thermal", "test_portal_txn", "test_persona_answer", "test_boe_ledger", "test_assumption_provenance", "test_assumption_provenance_route", "test_concept_budget", "test_topic_board", "test_roof_window", "test_topic_lifecycle", "test_comment_promote", "test_artifact_deliver", "test_calc_fields", "test_constraints", "test_element_lookup", "test_cli", "test_view_templates", "test_type_catalogs", "test_password_policy", "test_stepup_single_verifier", "test_fin_gov", "test_fin_calc", "test_fin_ingest", "test_fin_portfolio", "test_level_move", "test_instance_props", "test_roundtrip", "test_wall_joins", "test_composite_family", "test_shared_params", "test_version_values", "test_ifcpatch_transforms", "test_bcf3", "test_energy_export", "test_net_effective", "test_cre_deal_desk", "test_cre_governance", "test_cre_tier3", "test_family_geometry", "test_demo_seed", "test_cost_spine", "test_commercial_drift", "test_family_shapes", "test_workflow_config", "test_option_takeoff", "test_option_carbon", "test_option_carbon_route", "test_option_economics", "test_option_economics_route", "test_option_object", "test_option_object_route", "test_family_coverage", "test_section_annotation", "test_lod500_readiness", "test_scan_to_lod500", "test_egress_routes", "test_status_workflow_parity", "test_section_hatch", "test_section_keynotes", "test_detail_refs", "test_vg_overrides", "test_revit_export_cfg", "test_soft_clash", "test_sequence_clash", "test_element_tags", "test_cost_ifc", "test_fived", "test_health_consistency", "test_module_rooms", "test_modules_response_complete", "test_lifecycle_strip", "test_family_merge", "test_element_facts", "test_consistency", "test_work_queue", "test_task_bind", "test_qto_wire", "test_estimate_diff", "test_dim_constraints", "test_sov_build", "test_takeoff_scope", "test_r37_wire_routes", "test_r37_consolidate", "test_r37_contract", "test_export_promises", "test_pdf_ingest_gate", "test_roadmap_status", "test_claim_type", "test_risk_calibrate", "test_schedule_status", "test_engine_routes", "test_reachable", "test_money_wire", "test_license_gate", "test_license_lock_gate", "test_lock_advisories", "test_npm_advisories", "test_perf_budget", "test_perf_rate", "test_cache_key", "test_oauth_providers", "test_qto_measured_area", "test_lod_census", "test_lod_proxy", "test_model_ensure", "test_support_graph", "test_export_colour_stable", "test_stair_ramp", "test_profile_dims", "test_eot", "test_eot_methods", "test_eot_sourced", "test_shared_model", "test_plan_identity", "test_axon_view", "test_view_kind_dispatch", "test_photo_cv", "test_photo_detect", "test_photo_duplicate", "test_pipeline_scales", "test_plan_pins", "test_plan_cut_quality", "test_pins_unified", "test_index_freshness", "test_bake_budget", "test_geom_slots", "test_bake_shared", "test_geo_ref", "test_asset_verify", "test_folder_owner", "test_file_sizes", "test_declared_imports", "test_ruff_scope", "test_delete_ratchet", "test_doc_substance", "test_claude_md_gates", "test_cors_expose_headers", "test_open_redirect", "test_mp_engine", "test_upload_cap", "test_vitals", "test_samples", "test_bundle_index", # R41-TEST-RESIDUE — the residue sweep must never propose a database it does not own: "test_sweep_guard", # R23-DIGEST — the deterministic model digest and its two routes: diff --git a/services/api/src/aec_api/mailer.py b/services/api/src/aec_api/mailer.py index 80276265..d04a78a3 100644 --- a/services/api/src/aec_api/mailer.py +++ b/services/api/src/aec_api/mailer.py @@ -45,8 +45,14 @@ def smtp_test() -> dict: return {"ok": False, "message": f"SMTP failed: {str(e)[:140]}"} -def build_message(to: str, subject: str, body_text: str, body_html: str | None = None) -> EmailMessage: - """Construct a well-formed (optionally multipart) message — pure, no I/O (testable).""" +def build_message(to: str, subject: str, body_text: str, body_html: str | None = None, + attachments: list[tuple[str, bytes, str]] | None = None) -> EmailMessage: + """Construct a well-formed (optionally multipart) message — pure, no I/O (testable). + + `attachments` are `(filename, data, mime)` triples. Order matters: `add_alternative` must run + BEFORE `add_attachment`, or the html alternative lands inside the mixed part and clients show + the attachment where the body should be. + """ msg = EmailMessage() msg["From"] = _from_addr() msg["To"] = to @@ -54,13 +60,18 @@ def build_message(to: str, subject: str, body_text: str, body_html: str | None = msg.set_content(body_text) if body_html: msg.add_alternative(body_html, subtype="html") + for filename, data, mime in attachments or []: + maintype, _, subtype = mime.partition("/") + msg.add_attachment(data, maintype=maintype or "application", + subtype=subtype or "octet-stream", filename=filename) return msg -def send_email(to: str, subject: str, body_text: str, body_html: str | None = None) -> str: +def send_email(to: str, subject: str, body_text: str, body_html: str | None = None, + attachments: list[tuple[str, bytes, str]] | None = None) -> str: """Send one message. Returns "sent" | "disabled" | "error". Never raises (so a digest run can't be broken by one bad address / transient SMTP failure).""" - msg = build_message(to, subject, body_text, body_html) + msg = build_message(to, subject, body_text, body_html, attachments) if not smtp_configured(): _log.info("email disabled (no AEC_SMTP_HOST) — would send %r to %s", subject, to) return "disabled" diff --git a/services/api/src/aec_api/routers/jobs.py b/services/api/src/aec_api/routers/jobs.py index e7e46cac..2e8f3701 100644 --- a/services/api/src/aec_api/routers/jobs.py +++ b/services/api/src/aec_api/routers/jobs.py @@ -5,7 +5,7 @@ from sqlalchemy import select from sqlalchemy.orm import Session -from .. import rbac +from .. import audit, rbac from ..db import get_db from ..models import Job from ..rbac import require_role @@ -92,6 +92,65 @@ def job_artifact(pid: str, job_id: str, db: Session = Depends(get_db), headers={"Content-Disposition": f'inline; filename="{fname}"'}) +# R24-REPORTS-BY-MOMENT — "scheduled AND SHARED, not just downloaded" is the entry's own remainder, +# and the two halves have different blockers. SHARED is unblocked and lands here: the mailer already +# ships (stdlib smtplib, a Settings "Test connection" button, a digest route that sends real mail), +# it just had no way to carry a file. SCHEDULED is not here on purpose — it needs a recurring-trigger +# record AND a runner, and there is no scheduler of any kind in this tree (no APScheduler, croniter +# or cron), so choosing one is a deployment decision rather than a wiring task. +_DELIVER_MAX_BYTES = 15 * 1024 * 1024 + + +@router.post("/projects/{pid}/jobs/{job_id}/deliver") +def deliver_artifact(pid: str, job_id: str, to: list[str] = Body(..., embed=True), + note: str = Body("", embed=True), db: Session = Depends(get_db), + user: str = Depends(require_role("editor"))): + """Email a finished job's artifact to named recipients — the "shared, not just downloaded" half. + + Mirrors `job_artifact` exactly on lookup and refusal (404 wrong project, 409 while queued/running, + 404 when the job produced no artifact), because a caller should not have to learn two different + answers to "is this artifact ready". Delivery then adds two refusals of its own: an empty + recipient list is 422 rather than a silent no-op, and an artifact over 15 MB is 413 rather than a + per-recipient "error" from a server that would have rejected it anyway. + + Returns a per-recipient status map (`sent` / `disabled` / `error`) in the same shape as the + notification digest, so an unconfigured deployment reports `disabled` instead of failing. + """ + from .. import mailer, storage + j = db.get(Job, job_id) + if j is None or j.project_id != pid: + raise HTTPException(404, "job not found") + if j.state in ("queued", "running"): + raise HTTPException(409, f"job is {j.state} — poll until done") + res = j.result or {} + key = res.get("artifact_key") if isinstance(res, dict) else None + if j.state != "done" or not key or not storage.exists(key): + raise HTTPException(404, "job has no artifact" + (f" (state {j.state}: {j.error})" if j.error else "")) + addrs = [a.strip() for a in to if isinstance(a, str) and a.strip()] + if not addrs: + raise HTTPException(422, "at least one recipient is required") + + data = storage.get(key) + if len(data) > _DELIVER_MAX_BYTES: + raise HTTPException(413, f"artifact is {len(data)} bytes; the delivery cap is {_DELIVER_MAX_BYTES}") + fname = res.get("filename") or "artifact.bin" + subject = f"{j.kind.replace('_', ' ')}: {fname}" + body = (f"{user} sent you {fname} from project {pid}.\n\n" + + (note.strip() + "\n\n" if note.strip() else "") + + f"Generated by job {job_id} ({j.kind}).\n") + att = [(fname, data, res.get("media_type") or "application/octet-stream")] + results: dict[str, list[str]] = {} + for addr in addrs: + results.setdefault(mailer.send_email(addr, subject, body, None, att), []).append(addr) + audit.record(db, action="job.artifact.deliver", actor=user, method="POST", + path=f"/projects/{pid}/jobs/{job_id}/deliver", + detail={"kind": j.kind, "filename": fname, "bytes": len(data), + "recipients": len(addrs)}) + db.commit() + return {"smtp_configured": mailer.smtp_configured(), "filename": fname, + "bytes": len(data), "results": results} + + @router.get("/projects/{pid}/jobs") def list_jobs(pid: str, limit: int = 50, db: Session = Depends(get_db), _: str = Depends(require_role("viewer"))): diff --git a/services/api/test_artifact_deliver.py b/services/api/test_artifact_deliver.py new file mode 100644 index 00000000..b9021794 --- /dev/null +++ b/services/api/test_artifact_deliver.py @@ -0,0 +1,121 @@ +"""R24-REPORTS-BY-MOMENT — "shared, not just downloaded": mail a finished job's artifact. + +The entry's remainder reads "scheduled and shared, not just downloaded", and the two halves have +DIFFERENT blockers. Its own wording says this "still wants a delivery surface and SMTP" — both of +which already ship: `mailer.py` sends real mail and `POST .../notifications/digest` is a working +assemble-then-send surface. What was actually missing was smaller and more specific: the mailer had +no way to carry a FILE. That is what this covers. + +The SCHEDULED half is deliberately not here: it needs a recurring-trigger record and a runner, and +this tree has no scheduler of any kind, so picking one is a deployment decision. + +Run: PYTHONPATH=src ./.venv/bin/python test_artifact_deliver.py""" +import os + +os.environ["DATABASE_URL"] = "sqlite:///./test_artifact_deliver.db" +os.environ["STORAGE_DIR"] = "./test_storage_artifact_deliver" +os.environ.pop("AEC_RBAC", None) +os.environ.pop("AEC_SMTP_HOST", None) # unconfigured: sends must report "disabled", not fail +for _f in ("./test_artifact_deliver.db",): + if os.path.exists(_f): + os.remove(_f) + +from fastapi.testclient import TestClient # noqa: E402 + +from aec_api import mailer, storage # noqa: E402 +from aec_api.db import SessionLocal # noqa: E402 +from aec_api.main import app # noqa: E402 +from aec_api.models import AuditLog, Job # noqa: E402 + +# --- the pure half first: build_message must actually carry the bytes --------------------------- +# `build_message` is documented as pure and testable, so the attachment shape is checked without +# any SMTP at all. The ORDER matters and is the reason this is asserted rather than eyeballed: +# add_alternative has to run before add_attachment, or the html body lands inside the mixed part +# and mail clients render the attachment where the message should be. +msg = mailer.build_message("a@example.com", "Subj", "plain body", "

html body

", + [("pack.pdf", b"%PDF-1.4 fake", "application/pdf")]) +atts = list(msg.iter_attachments()) +assert len(atts) == 1, [p.get_content_type() for p in msg.walk()] +assert atts[0].get_filename() == "pack.pdf", atts[0].get_filename() +assert atts[0].get_content_type() == "application/pdf", atts[0].get_content_type() +assert atts[0].get_payload(decode=True) == b"%PDF-1.4 fake" +body = msg.get_body(preferencelist=("html",)) +assert body is not None and "html body" in body.get_content(), "the html body must survive attaching" + +# a message with no attachments must be byte-identical in shape to before — the parameter is +# additive, and an existing digest send must not silently become multipart/mixed. +plain = mailer.build_message("a@example.com", "S", "t") +assert not list(plain.iter_attachments()), "no attachments must mean no mixed part" + +with TestClient(app) as c: + pid = c.post("/projects", json={"name": "Deliver P"}).json()["id"] + + # --- a finished artifact job, built the way the job runner leaves one ---------------------- + key = f"{pid}/jobs/deadbeef-owner-monthly.pdf" + storage.put(key, b"%PDF-1.4 owner monthly package") + with SessionLocal() as s: + s.add(Job(id="job-done", project_id=pid, kind="report_package", state="done", + params={}, result={"artifact_key": key, "media_type": "application/pdf", + "filename": "owner-monthly.pdf", + "bytes": 30, "reports": ["r1"]})) + s.add(Job(id="job-running", project_id=pid, kind="report_package", state="running", + params={})) + s.add(Job(id="job-noart", project_id=pid, kind="report_package", state="done", + params={}, result={})) + s.commit() + + # --- the delivery itself: unconfigured SMTP reports "disabled", it does not 500 ------------- + # This is the shape the digest route already returns, on purpose: an operator who has not set + # AEC_SMTP_HOST gets a truthful per-recipient status rather than an error that reads like a bug. + r = c.post(f"/projects/{pid}/jobs/job-done/deliver", + json={"to": ["owner@example.com", "lender@example.com"], "note": "Draw 7 pack."}) + assert r.status_code == 200, (r.status_code, r.text) + out = r.json() + assert out["smtp_configured"] is False, out + assert out["filename"] == "owner-monthly.pdf", out + assert out["bytes"] == len(b"%PDF-1.4 owner monthly package"), out + assert sorted(out["results"]["disabled"]) == ["lender@example.com", "owner@example.com"], out + + # --- it is audited: who sent what to how many people --------------------------------------- + # A file leaving the system is exactly the event an audit log exists for. + with SessionLocal() as s: + ev = [a for a in s.query(AuditLog).all() if a.action == "job.artifact.deliver"] + assert len(ev) == 1, [(a.action) for a in ev] + assert ev[0].detail["recipients"] == 2, ev[0].detail + assert ev[0].detail["filename"] == "owner-monthly.pdf", ev[0].detail + assert ev[0].detail["bytes"] == len(b"%PDF-1.4 owner monthly package"), ev[0].detail + + # --- refusals: same answers as the download route, plus delivery's own two ----------------- + # Mirroring job_artifact matters — a caller should not learn two different answers to + # "is this artifact ready". + assert c.post(f"/projects/{pid}/jobs/nope/deliver", + json={"to": ["a@example.com"]}).status_code == 404 + assert c.post(f"/projects/{pid}/jobs/job-running/deliver", + json={"to": ["a@example.com"]}).status_code == 409 + assert c.post(f"/projects/{pid}/jobs/job-noart/deliver", + json={"to": ["a@example.com"]}).status_code == 404 + + # an empty recipient list is a refusal, not a silent success — otherwise a UI bug that drops + # the address field reports "sent" and the pack goes nowhere. + for empty in ([], ["", " "]): + r = c.post(f"/projects/{pid}/jobs/job-done/deliver", json={"to": empty}) + assert r.status_code == 422, (empty, r.status_code, r.text) + + # oversize is refused up front rather than as a per-recipient "error" from a server that + # would have bounced it anyway. + big = f"{pid}/jobs/big.pdf" + storage.put(big, b"x" * (15 * 1024 * 1024 + 1)) + with SessionLocal() as s: + s.add(Job(id="job-big", project_id=pid, kind="report_package", state="done", params={}, + result={"artifact_key": big, "media_type": "application/pdf", + "filename": "big.pdf"})) + s.commit() + r = c.post(f"/projects/{pid}/jobs/job-big/deliver", json={"to": ["a@example.com"]}) + assert r.status_code == 413, (r.status_code, r.text) + + # a job in ANOTHER project is not reachable through this project's path. + pid2 = c.post("/projects", json={"name": "Other"}).json()["id"] + assert c.post(f"/projects/{pid2}/jobs/job-done/deliver", + json={"to": ["a@example.com"]}).status_code == 404 + +print("test_artifact_deliver OK") From 87cc0e895a8a811322f6e279ca97bbdae767feb8 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 4 Sep 2026 14:02:27 +0000 Subject: [PATCH 11/12] Review round on #435: five findings, all verified real, all fixed MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit **1. A malformed recipient aborted the whole delivery (Major).** `send_email` built the message BEFORE its try block. `EmailMessage` rejects a header value containing CR/LF with ValueError, and this function is documented to never raise — so one bad address raised out of the loop after earlier recipients had already received the artifact and before the audit row was written, leaving the record disagreeing with what happened. Construction moved inside the protected flow; a bad address is now that recipient's "error" and nobody else's. Also built (and discarded) on the unconfigured path, so a malformed address does not become visible only in production. **2. STARTTLS presented an unverified context (Major, CWE-295).** The finding's stated reason was wrong — it said "Python 3.9 uses an unverified context" and this repo is on 3.12 — but the conclusion holds on 3.12 too: measured, `ssl._create_stdlib_context()` reports verify_mode=0 and check_hostname=False, so the artifact and the SMTP password went up with no certificate check. Both call sites now pass `ssl.create_default_context()`. **3. The size cap ran AFTER materialising the object (Major).** `storage.get` pulls the whole artifact into memory and `len(data)` checked it afterwards, so the memory was already spent on exactly the payload being refused — and concurrent callers multiply it. `storage.size(key)` already existed; the check now runs before the read. **4. Recipients were unbounded and undeduplicated (Major, CWE-770).** Each address is a synchronous SMTP conversation with a 15-second timeout, so an unbounded list occupies a worker for hours. Now de-duplicated case-insensitively (preserving caller order) and capped at 25 — as a 422 refusal, not a silent trim, because quietly dropping recipients is the same silent-success failure the empty-list 422 exists to prevent. **5. The test stole the runner's STORAGE_DIR (Minor).** `run_tests.py` assigns `STORAGE_DIR=./_storage_{test}` and sweeps exactly that path; the test overwrote it, so its 15 MiB blob landed somewhere the runner does not own. That is what the suite footer's "dir(s) this runner does not own" counts, and the stray directory was sitting on disk at 61 MB. Now `setdefault`. Every fix is mutation-checked. Restoring the pre-fix code fails with: build outside the try -> AssertionError on the per-recipient result map; size-after-read -> "materialised " from a patched storage.get, which proves the object was pulled in; no cap -> 26 recipients accepted; no dedup -> a@ and A@ both served; bare starttls() -> "called with no context — that context does NOT verify", asserted through a fake SMTP that captures what is actually passed rather than by reading the source. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Tt2XKB83wwNt2nrMbK6eEA --- services/api/src/aec_api/mailer.py | 22 +++++- services/api/src/aec_api/routers/jobs.py | 24 +++++-- services/api/test_artifact_deliver.py | 89 +++++++++++++++++++++++- 3 files changed, 127 insertions(+), 8 deletions(-) diff --git a/services/api/src/aec_api/mailer.py b/services/api/src/aec_api/mailer.py index d04a78a3..fa22ac65 100644 --- a/services/api/src/aec_api/mailer.py +++ b/services/api/src/aec_api/mailer.py @@ -12,6 +12,7 @@ import logging import smtplib +import ssl from email.message import EmailMessage from . import settings_store @@ -36,7 +37,7 @@ def smtp_test() -> dict: try: with smtplib.SMTP(host, port, timeout=15) as s: if settings_store.get("AEC_SMTP_TLS", "1") == "1": - s.starttls() + s.starttls(context=ssl.create_default_context()) # verified — see send_email user, pw = settings_store.get("AEC_SMTP_USER"), settings_store.get("AEC_SMTP_PASSWORD") if user and pw: s.login(user, pw) @@ -71,16 +72,31 @@ def send_email(to: str, subject: str, body_text: str, body_html: str | None = No attachments: list[tuple[str, bytes, str]] | None = None) -> str: """Send one message. Returns "sent" | "disabled" | "error". Never raises (so a digest run can't be broken by one bad address / transient SMTP failure).""" - msg = build_message(to, subject, body_text, body_html, attachments) if not smtp_configured(): + # Still built, so an unconfigured deployment fails on a malformed address the same way a + # configured one does — a bad recipient must not become visible only in production. + try: + build_message(to, subject, body_text, body_html, attachments) + except Exception as e: # noqa: BLE001 + _log.warning("email not built for %s: %s", to, e) + return "error" _log.info("email disabled (no AEC_SMTP_HOST) — would send %r to %s", subject, to) return "disabled" host = settings_store.get("AEC_SMTP_HOST") port = int(settings_store.get("AEC_SMTP_PORT", "587")) try: + # INSIDE the try, not before it: `EmailMessage` rejects a recipient containing CR/LF with + # ValueError, and this function is documented to never raise. Built outside, one malformed + # address aborted the whole delivery loop — after earlier recipients had already received + # the artifact and before the audit row was written, so the record disagreed with reality. + msg = build_message(to, subject, body_text, body_html, attachments) with smtplib.SMTP(host, port, timeout=15) as s: if settings_store.get("AEC_SMTP_TLS", "1") == "1": - s.starttls() + # An explicit verified context. `starttls()` with no argument uses + # `ssl._create_stdlib_context()`, which on this interpreter reports + # verify_mode=0 / check_hostname=False — no certificate check at all, so the + # artifact and the SMTP credentials go up unauthenticated. + s.starttls(context=ssl.create_default_context()) user, pw = settings_store.get("AEC_SMTP_USER"), settings_store.get("AEC_SMTP_PASSWORD") if user and pw: s.login(user, pw) diff --git a/services/api/src/aec_api/routers/jobs.py b/services/api/src/aec_api/routers/jobs.py index 2e8f3701..8048e2bc 100644 --- a/services/api/src/aec_api/routers/jobs.py +++ b/services/api/src/aec_api/routers/jobs.py @@ -99,6 +99,7 @@ def job_artifact(pid: str, job_id: str, db: Session = Depends(get_db), # record AND a runner, and there is no scheduler of any kind in this tree (no APScheduler, croniter # or cron), so choosing one is a deployment decision rather than a wiring task. _DELIVER_MAX_BYTES = 15 * 1024 * 1024 +_DELIVER_MAX_RECIPIENTS = 25 @router.post("/projects/{pid}/jobs/{job_id}/deliver") @@ -126,13 +127,28 @@ def deliver_artifact(pid: str, job_id: str, to: list[str] = Body(..., embed=True key = res.get("artifact_key") if isinstance(res, dict) else None if j.state != "done" or not key or not storage.exists(key): raise HTTPException(404, "job has no artifact" + (f" (state {j.state}: {j.error})" if j.error else "")) - addrs = [a.strip() for a in to if isinstance(a, str) and a.strip()] + # Normalise, de-duplicate (case-insensitively — SMTP domains are not case-sensitive and the + # local part is not worth guessing at), and preserve the caller's order so the response reads + # the way the request was written. `dict.fromkeys` does both in one pass. + addrs = list(dict.fromkeys(a.strip() for a in to if isinstance(a, str) and a.strip()).keys()) + seen: set[str] = set() + addrs = [a for a in addrs if not (a.lower() in seen or seen.add(a.lower()))] if not addrs: raise HTTPException(422, "at least one recipient is required") - + # Each address is a SYNCHRONOUS SMTP conversation with a 15-second timeout, so an unbounded + # list is a request that occupies a worker for hours. The cap is a refusal, not a silent trim: + # quietly dropping recipients is the failure the 422 above exists to avoid, one level up. + if len(addrs) > _DELIVER_MAX_RECIPIENTS: + raise HTTPException(422, f"at most {_DELIVER_MAX_RECIPIENTS} recipients per delivery " + f"({len(addrs)} given)") + + # Size BEFORE read. `storage.get` materialises the whole object, and an artifact job can park a + # large geometry export, so checking `len(data)` afterwards means the memory has already been + # spent on exactly the payload being refused — and concurrent callers multiply it. + nbytes = storage.size(key) + if nbytes > _DELIVER_MAX_BYTES: + raise HTTPException(413, f"artifact is {nbytes} bytes; the delivery cap is {_DELIVER_MAX_BYTES}") data = storage.get(key) - if len(data) > _DELIVER_MAX_BYTES: - raise HTTPException(413, f"artifact is {len(data)} bytes; the delivery cap is {_DELIVER_MAX_BYTES}") fname = res.get("filename") or "artifact.bin" subject = f"{j.kind.replace('_', ' ')}: {fname}" body = (f"{user} sent you {fname} from project {pid}.\n\n" diff --git a/services/api/test_artifact_deliver.py b/services/api/test_artifact_deliver.py index b9021794..41ca2b27 100644 --- a/services/api/test_artifact_deliver.py +++ b/services/api/test_artifact_deliver.py @@ -13,7 +13,10 @@ import os os.environ["DATABASE_URL"] = "sqlite:///./test_artifact_deliver.db" -os.environ["STORAGE_DIR"] = "./test_storage_artifact_deliver" +# setdefault, not assignment: run_tests.py assigns STORAGE_DIR=./_storage_{test} and sweeps exactly +# that path afterwards. Overwriting it sent this test's 15 MiB blob to a directory the runner does +# not own, which is what the suite footer means by "dir(s) this runner does not own". +os.environ.setdefault("STORAGE_DIR", "./_storage_test_artifact_deliver") os.environ.pop("AEC_RBAC", None) os.environ.pop("AEC_SMTP_HOST", None) # unconfigured: sends must report "disabled", not fail for _f in ("./test_artifact_deliver.db",): @@ -113,9 +116,93 @@ r = c.post(f"/projects/{pid}/jobs/job-big/deliver", json={"to": ["a@example.com"]}) assert r.status_code == 413, (r.status_code, r.text) + # --- a malformed recipient is that recipient's error, not everyone's ----------------------- + # `EmailMessage` rejects a header value containing CR/LF with ValueError. `send_email` is + # documented to NEVER raise; built outside its try block it did, which aborted the delivery loop + # after earlier recipients had already been served and before the audit row was written — so the + # audit disagreed with what actually happened. The bad address must degrade to "error" alone. + assert mailer.send_email("bad@example.com\r\nBcc: injected@example.com", "S", "b") == "error" + r = c.post(f"/projects/{pid}/jobs/job-done/deliver", + json={"to": ["good@example.com", "bad@example.com\r\nBcc: x@example.com"]}) + assert r.status_code == 200, (r.status_code, r.text) + res = r.json()["results"] + assert res.get("disabled") == ["good@example.com"], res + assert res.get("error") == ["bad@example.com\r\nBcc: x@example.com"], res + + # --- recipients are de-duplicated, case-insensitively -------------------------------------- + # Every retained address is a synchronous SMTP conversation, so a duplicate is not merely untidy. + r = c.post(f"/projects/{pid}/jobs/job-done/deliver", + json={"to": ["a@example.com", "A@Example.com", " a@example.com "]}) + assert r.status_code == 200, (r.status_code, r.text) + assert r.json()["results"]["disabled"] == ["a@example.com"], r.json()["results"] + + # --- the recipient cap REFUSES, it does not silently trim ---------------------------------- + # Trimming would be the same silent-success failure the empty-list 422 exists to prevent. + many = [f"u{i}@example.com" for i in range(26)] + r = c.post(f"/projects/{pid}/jobs/job-done/deliver", json={"to": many}) + assert r.status_code == 422, (r.status_code, r.text) + assert "25" in r.text, r.text + + # --- oversize is refused from the STORED SIZE, without materialising the object ------------- + # storage.get() pulls the whole artifact into memory; checking len() afterwards spends exactly + # the memory being refused. Patching get() to explode proves the refusal happens before it. + _boom = storage.get + storage.get = lambda k: (_ for _ in ()).throw(AssertionError(f"materialised {k}")) + try: + r = c.post(f"/projects/{pid}/jobs/job-big/deliver", json={"to": ["a@example.com"]}) + assert r.status_code == 413, (r.status_code, r.text) + finally: + storage.get = _boom + # a job in ANOTHER project is not reachable through this project's path. pid2 = c.post("/projects", json={"name": "Other"}).json()["id"] assert c.post(f"/projects/{pid2}/jobs/job-done/deliver", json={"to": ["a@example.com"]}).status_code == 404 +# --- STARTTLS must present a VERIFYING context --------------------------------------------------- +# `starttls()` with no argument uses `ssl._create_stdlib_context()`, which on this interpreter +# reports verify_mode=CERT_NONE and check_hostname=False — the artifact and the SMTP password go up +# with no certificate check. Asserted through a fake SMTP rather than by reading the source, so the +# test measures what is passed at the call, not what the file appears to say. +import ssl # noqa: E402 + + +class _FakeSMTP: + captured: list = [] + + def __init__(self, host, port, timeout=None): + pass + + def __enter__(self): + return self + + def __exit__(self, *a): + return False + + def starttls(self, context=None): + _FakeSMTP.captured.append(context) + + def login(self, u, p): + pass + + def send_message(self, m): + pass + + +_real_smtp, _real_get = mailer.smtplib.SMTP, mailer.settings_store.get +mailer.smtplib.SMTP = _FakeSMTP +mailer.settings_store.get = lambda k, d=None: {"AEC_SMTP_HOST": "smtp.example.com", + "AEC_SMTP_PORT": "587", + "AEC_SMTP_TLS": "1"}.get(k, d) +try: + assert mailer.send_email("a@example.com", "S", "b") == "sent" +finally: + mailer.smtplib.SMTP, mailer.settings_store.get = _real_smtp, _real_get + +assert len(_FakeSMTP.captured) == 1, _FakeSMTP.captured +_ctx = _FakeSMTP.captured[0] +assert _ctx is not None, "starttls() was called with no context — that context does NOT verify" +assert _ctx.verify_mode == ssl.CERT_REQUIRED, _ctx.verify_mode +assert _ctx.check_hostname is True, _ctx.check_hostname + print("test_artifact_deliver OK") From 67dfc366de3ccde14631bcac9fee8b0444878ef1 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 4 Sep 2026 14:14:00 +0000 Subject: [PATCH 12/12] Second review round on #435: the port fix is the root cause my first fix missed MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Three new findings on the fix commit. Two were real defects, one is a design question answered rather than obeyed. **A mistyped SMTP port escaped the no-raise boundary (Major) — and this is the SAME defect class the previous commit fixed, one line above the guard.** That fix moved `build_message` inside the try and left `int(AEC_SMTP_PORT)` outside it. Settings are stored as arbitrary strings (`settings_store.set_value(db, k, str(v))`, no numeric validation), so a typo in the Settings form raised ValueError straight through a function documented never to raise, aborting the delivery loop before its audit row — exactly the failure the CR/LF fix was for. Treating the instance instead of the class is what left it. The whole prologue is now inside the boundary: this function returns a status for ANY input, configuration included. **A recipient could forge log lines (Minor, CWE-117).** Both exception handlers logged `to` with `%s`, so CR/LF in an address writes literal newlines into the stream and a recipient can append a plausible-looking record of its own. Now `%r`, which escapes them — the value is still reported, never as its own line. This one was introduced by my previous commit, not found in old code. **Cleartext SMTP auth: warned, not refused — deliberately.** The finding asks to reject `send_email`/`smtp_test` outright when `AEC_SMTP_TLS=0`. That is a documented deployment choice for a self-hosted product relaying through localhost or a trusted internal MTA, where cleartext is not an exposure; hard-refusing would break those installs to protect against a risk they do not have. What is not defensible is doing it silently, so a credential sent without TLS now logs a warning naming the setting and the remedy. The password is never logged, and the test asserts that. Mutation-checked: %s in place of %r puts the forged line back in the stream; moving the port parse back outside the try loses the "error" status; removing the warning loses the cleartext notice. The password assertion was rewritten after it passed for the wrong reason — the fixture used "p" as the password and the haystack was full of the letter p, so it now uses a distinctive value. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Tt2XKB83wwNt2nrMbK6eEA --- services/api/src/aec_api/mailer.py | 32 ++++++++++----- services/api/test_artifact_deliver.py | 58 +++++++++++++++++++++++++++ 2 files changed, 81 insertions(+), 9 deletions(-) diff --git a/services/api/src/aec_api/mailer.py b/services/api/src/aec_api/mailer.py index fa22ac65..371f094e 100644 --- a/services/api/src/aec_api/mailer.py +++ b/services/api/src/aec_api/mailer.py @@ -78,17 +78,22 @@ def send_email(to: str, subject: str, body_text: str, body_html: str | None = No try: build_message(to, subject, body_text, body_html, attachments) except Exception as e: # noqa: BLE001 - _log.warning("email not built for %s: %s", to, e) + # %r, not %s: `to` is attacker-influenced and a CR/LF in it writes literal newlines + # into the log stream, so a recipient can forge whole log lines (CWE-117). repr escapes + # them. Same at the send handler below. + _log.warning("email not built for %r: %s", to, e) return "error" - _log.info("email disabled (no AEC_SMTP_HOST) — would send %r to %s", subject, to) + _log.info("email disabled (no AEC_SMTP_HOST) — would send %r to %r", subject, to) return "disabled" - host = settings_store.get("AEC_SMTP_HOST") - port = int(settings_store.get("AEC_SMTP_PORT", "587")) try: - # INSIDE the try, not before it: `EmailMessage` rejects a recipient containing CR/LF with - # ValueError, and this function is documented to never raise. Built outside, one malformed - # address aborted the whole delivery loop — after earlier recipients had already received - # the artifact and before the audit row was written, so the record disagreed with reality. + # EVERYTHING that can raise belongs inside this boundary, not just the message build. The + # first fix moved `build_message` in and left `int(AEC_SMTP_PORT)` outside — and settings are + # stored as arbitrary strings (`settings_store.set_value(db, k, str(v))`, no numeric check), + # so a mistyped port raised ValueError one line above the guard that exists to prevent + # exactly that. Treating the instance rather than the class is what left it; the rule is that + # this function returns a status for ANY input, configuration included. + host = settings_store.get("AEC_SMTP_HOST") + port = int(settings_store.get("AEC_SMTP_PORT", "587")) msg = build_message(to, subject, body_text, body_html, attachments) with smtplib.SMTP(host, port, timeout=15) as s: if settings_store.get("AEC_SMTP_TLS", "1") == "1": @@ -99,9 +104,18 @@ def send_email(to: str, subject: str, body_text: str, body_html: str | None = No s.starttls(context=ssl.create_default_context()) user, pw = settings_store.get("AEC_SMTP_USER"), settings_store.get("AEC_SMTP_PASSWORD") if user and pw: + if settings_store.get("AEC_SMTP_TLS", "1") != "1": + # Deliberately a loud warning, not a refusal. `AEC_SMTP_TLS=0` is a documented + # deployment choice for a self-hosted product relaying through localhost or a + # trusted internal MTA, where cleartext is not an exposure; hard-refusing would + # break those installs to protect against a risk they do not have. What is not + # defensible is doing it SILENTLY, so the operator is told each time. + _log.warning("SMTP auth over cleartext: AEC_SMTP_TLS=0 and a password is set, " + "so the credential leaves this host unprotected. Set AEC_SMTP_TLS=1 " + "unless the relay is local or on a trusted network.") s.login(user, pw) s.send_message(msg) return "sent" except Exception as e: # noqa: BLE001 — one bad send must not abort a batch - _log.warning("email send failed to %s: %s", to, e) + _log.warning("email send failed to %r: %s", to, e) return "error" diff --git a/services/api/test_artifact_deliver.py b/services/api/test_artifact_deliver.py index 41ca2b27..23e5fb18 100644 --- a/services/api/test_artifact_deliver.py +++ b/services/api/test_artifact_deliver.py @@ -205,4 +205,62 @@ def send_message(self, m): assert _ctx.verify_mode == ssl.CERT_REQUIRED, _ctx.verify_mode assert _ctx.check_hostname is True, _ctx.check_hostname +# --- a mistyped port is a status, not an escaped exception --------------------------------------- +# The first fix moved build_message inside the boundary and left `int(AEC_SMTP_PORT)` outside it — +# the same defect class, one line above the guard. Settings are stored as arbitrary strings +# (settings_store.set_value(db, k, str(v)), no numeric validation), so a typo in the Settings form +# raised ValueError straight through a function documented never to raise, aborting the delivery +# loop before its audit row exactly as the CR/LF recipient did. +_real_get = mailer.settings_store.get +mailer.settings_store.get = lambda k, d=None: {"AEC_SMTP_HOST": "h", + "AEC_SMTP_PORT": "not-a-number"}.get(k, d) +try: + assert mailer.send_email("a@example.com", "S", "b") == "error" +finally: + mailer.settings_store.get = _real_get + +# --- an attacker-influenced recipient cannot forge log lines (CWE-117) -------------------------- +# `%s` writes a literal CR/LF into the stream, so a recipient can append whatever it likes as a +# separate, plausible-looking log record. `%r` escapes it. +import io as _io # noqa: E402 +import logging as _logging # noqa: E402 + +_buf = _io.StringIO() +_h = _logging.StreamHandler(_buf) +_ml = _logging.getLogger("aec.mail") +_saved, _prop = _ml.handlers[:], _ml.propagate +_ml.handlers[:] = [_h] +_ml.propagate = False +try: + mailer.send_email("v@x.test\r\nFAKE: forged log line", "S", "b") +finally: + _ml.handlers[:], _ml.propagate = _saved, _prop +_out = _buf.getvalue() +assert "FAKE: forged log line" in _out, _out # the value is still reported... +assert "\nFAKE: forged log line" not in _out, repr(_out) # ...but never as its own line + +# --- cleartext SMTP auth is allowed but never silent ------------------------------------------- +# AEC_SMTP_TLS=0 is a documented deployment choice (a local or trusted-network relay), so this is a +# warning rather than a refusal — but sending a credential unprotected without telling anyone is +# what would be indefensible. +_FakeSMTP.captured.clear() +_buf2 = _io.StringIO() +_h2 = _logging.StreamHandler(_buf2) +_saved, _prop = _ml.handlers[:], _ml.propagate +_ml.handlers[:] = [_h2] +_ml.propagate = False +_real_smtp, _real_get = mailer.smtplib.SMTP, mailer.settings_store.get +mailer.smtplib.SMTP = _FakeSMTP +mailer.settings_store.get = lambda k, d=None: {"AEC_SMTP_HOST": "h", "AEC_SMTP_PORT": "587", + "AEC_SMTP_TLS": "0", "AEC_SMTP_USER": "u", + "AEC_SMTP_PASSWORD": "hunter2-secret"}.get(k, d) +try: + assert mailer.send_email("a@example.com", "S", "b") == "sent" # still allowed +finally: + mailer.smtplib.SMTP, mailer.settings_store.get = _real_smtp, _real_get + _ml.handlers[:], _ml.propagate = _saved, _prop +assert "cleartext" in _buf2.getvalue(), _buf2.getvalue() +assert "hunter2-secret" not in _buf2.getvalue(), "the password must never be logged" +assert not _FakeSMTP.captured, "starttls must not run when TLS is off" + print("test_artifact_deliver OK")