1736 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
xarmian	c4d429d14c	fix: three codex round-6 findings, one premise corrected (TASK-2878) ... Round 6 confirmed round 5 and found three. All three are real; one arrived with an account of its own cause that the test refuted, and the corrected route is narrower than the report. ## A NON-STRING RELATION DEFAULT, AND WHERE IT ACTUALLY GETS IN The finding: injected defaults are never type-checked, so `42` or `[]` can persist in a relation field. True, but not by the route described. `MigrateFields` injects destination defaults ITSELF, so in the ordinary case the key is present when `ValidateFieldsDetailed` runs and its type IS checked — a numeric default lands in needs_value with "must be a string", which is correct behaviour. My first test asserted the wrong thing and FAILED against the fixed build, which is how I found this out. The unchecked route is narrower: a NULL OVERRIDE deletes the key after MigrateFields filled it, so validation injects the default itself — and its own injection branch `continue`s PAST the type check. That is the one way a non-string reaches a relation field unchallenged. The late-default pass owns values that arrive from defaults, so it reports this one: `invalid_shape`, a new reason, because every existing reason describes a lookup that never happened. Retargeting the test then exposed a second defect IN MY OWN FIX: the late pass's `if len(late) == 0 { return nil, nil }` discarded the non-string drops it had just recorded. The value vanished from all three buckets. Green on the first route, silent on the second. THE PARITY GATE FROM AN EARLIER COMMIT CAUGHT THE NEW REASON: adding `invalid_shape` failed TestCopyPreflightDropReasonsAreRenderedByTheDialog until the TypeScript union and CopyItemDialog learned it. That gate exists because `referent_not_portable` shipped unrendered in BUG-2674, and it just did its job on its author. ## A WHITESPACE-ONLY VALUE IS "NO REFERENCE", NOT A BAD ONE The store resolver trims and ignores `" "`. The server wrapper checked the UNTRIMMED string, so the value fell through to the visibility loop — and since round 1's vanished-target arm turns a missing lookup into a refusal, `" "` came back as not_found instead of an empty field. A defect my own round-1 fix introduced: before it, that path did `continue`. ## A MALFORMED CARRIED VALUE IS NOT "NOT PORTABLE" The cross-workspace branch dropped every carried value without looking, including non-strings, and labelled them `referent_not_portable` — a false account of why the value is going. It is not a reference at all. Left in place now for ValidateFields to reject on shape, which is what the SAME-workspace branch already did with it: the two modes disagreeing about one malformed value was the defect. ## Counterfactuals Skip non-string defaults again -> TestCopyEndpoint_NonStringRelationDefault DETECTED. Restore the untrimmed skip -> TestRelationDoors_WhitespaceOnly DETECTED. Both build-checked, and the first form of the second mutant did NOT build (unused import) — reported as such rather than scored, since a non-compiling mutant produces no failures and reads as survived. Gates: internal/server ok 324.8s · internal/store ok 344.5s · internal/mcp ok 16.9s · go vet clean · gofmt clean · make lint 0 issues · npm run check 0 errors. Postgres green on the parent commit (store 596.1s, server 299.4s); re-running on this tree.	2026-09-04 18:10:53 +00:00
xarmian	ae8551274b	fix: codex round-5 finding — the other direction of the origin guard (TASK-2878) ... One finding, P2, and it is the tail of round 4's fix. Round 4 stopped labelling a null-source key `migrated`, because validation treats null as missing and fills the DESTINATION's default in its place — so `migrated` named the source for a value the destination chose. With NO destination default there is nothing to fill it: the null is what carries, and `default` names a value the schema never declared. One guard, wrong in both directions, and the reason is the same in both: "was the key present in the source" is not "where did the final value come from". The label now follows the value: - source value, non-nil -> migrated - source null, destination default -> default - source null, NO default -> migrated `from` is what a dialog uses to say "this came across" versus "this is the destination's default", so either error is the preview misreporting the thing it exists to report. ## Counterfactual Remove the round-5 branch so a null source always reads as `default` -> TestCopyEndpoint_NullSourceWithoutDefaultIsNotReportedAsDefault DETECTED, build-checked first. The mutant also confirms the key really is in `carried` in that scenario — the test returns without asserting if it is not, so without the mutant its green would have been consistent with a vacuous pass. Gates: internal/server ok 288.8s · internal/store ok 302.4s · internal/mcp ok 13.7s · go vet clean · gofmt clean · make lint 0 issues. Postgres green on the parent commit (store 626.4s, server 311.9s, private container port 5481); re-running on this tree.	2026-09-04 17:46:53 +00:00
xarmian	f4d733e57e	fix: two codex round-4 findings — oracle race, null-source provenance (TASK-2878) ... Round 4 confirmed round 3 and dropped from P1 to P2, which is what convergence looks like. Both still real. ## THE ORACLE COLLAPSE HAD A HOLE, AND MY OWN COMMENT ASSERTED IT DID NOT Round 3's fix collapses `wrong_collection` to `not_found` when the requester cannot see the target. It needs the item to ask that, and when the second lookup came back nil — deleted between the resolver's read and this one — it did `continue` under a comment reading "vanished since; already the safe answer". That comment was wrong. Nothing had rewritten the reason, so the issue still said `wrong_collection`, whose message tells the caller the value named something a moment ago. The disclosure round 3 closed, reachable by a race. Collapsed now. Worth stating plainly because it is the same defect twice: I wrote a comment asserting a state ("already safe") that the code did not establish, and I wrote it in the fix for exactly that disclosure. ## A NULL SOURCE VALUE IS NOT A CARRIED ONE The preflight marked any key PRESENT in the source's field map as `from: "migrated"`. A source key holding `null` is present and carries nothing: MigrateFields keeps the key, the relation pass skips a nil value, and validation then treats it as missing and fills the DESTINATION's default in its place. So the response reported the source as the origin of a value the destination chose. `from` is what a dialog uses to say "this came across" versus "this is the destination's default", so naming the wrong one is the preview lying about the thing it exists to report. Presence with a VALUE is the test now. Not relation-specific — any nulled source field with a destination default had it — so the guard is on the shared origin loop rather than beside the relation pass. ## Counterfactuals Remove the null guard from the origin loop -> TestCopyEndpoint_NullSourceRelationIsNotReportedAsMigrated DETECTED (build-checked first). The oracle-race collapse has NO test, for the reason the vanished-target refusal has none: reproducing it means deleting a row between two lookups inside one request, and a test that faked the interleaving would pin the fake. Both are listed in the PR body under "Not tested, and why". Gates: internal/server ok 343.8s · internal/store ok 349.9s · internal/mcp ok 22.1s · go vet clean · gofmt clean · make lint 0 issues. Postgres green on the parent commit (store 553.9s, server 297.1s, private container port 5481); re-running on this tree.	2026-09-04 17:28:46 +00:00
xarmian	8fedc5487c	fix: three codex round-3 findings — oracle, bulk defaults, required (TASK-2878) ... Round 3 confirmed round 2's fixes and found three more. Codex still could not execute anything, so all three were static reads I verified myself. ## `wrong_collection` DISCLOSED EXISTENCE The store emits `wrong_collection` when a value names a LIVE item outside the field's declared target, and the server's visibility layer skipped any key that already carried an issue. So the message — "is not an item in collection X" — told a caller the value EXISTS, distinguishably from the `not_found` a nonexistent value gets. An existence oracle for anyone who cannot see that item, and the exact shape the `not_found` collapse exists to prevent. Collapsed to `not_found` when the requester cannot see the target, and KEPT otherwise: "you linked a task where a person belongs" is the useful half of this reason, and blanket-collapsing would have passed the security leg while destroying it. Both legs are in the test for that reason. Needed one new store export, `ResolveRelationTarget`: deciding what to disclose about a live item requires the item, and the resolver is the only thing that maps a value to one under the no-slug rule. ## BULK STATUS / PRIORITY BYPASSED RELATION DEFAULTS `bulkFieldUpdate` resolves only the keys `changes` names — correctly, since re-litigating stored values would freeze legacy items — but `ValidateFields` runs BEFORE it and INJECTS schema defaults. A defaulted relation was persisted raw: never canonicalised, never checked against its collection. The same late-arrival the migrate doors hit, reached by a different route, and the narrow pass built for them covers it unchanged. `dropped_fields` now rides every bulk op's activity row, not just the move branch: a status or priority change can discard a relation default too, and a drop nobody records is the defect BUG-2674 closed. ## A REQUIRED RELATION COULD END UP ABSENT AND REPORTED VALID The late pass deletes a key AFTER validation passed, so nothing re-checked required-ness: a required relation whose default did not resolve left the item with the field absent, and the preflight reported `valid: true`. Re-running validation is not the fix — it would re-inject the same broken default. There is no valid value for that field, so the doors refuse: `missing_required_fields` on move and bulk move, a FieldValidationError on the copy, and on the preflight a `needs_value` row with `valid: false`. That split is the one this pair has everywhere else — the preview says what is wrong, the copy refuses. ## Counterfactuals Remove the oracle collapse -> the visibility leg DETECTED. Remove the bulk-update late pass -> DETECTED. Remove the required-relation refusal at the copy door -> DETECTED. All build-checked first. Gates: internal/server ok 352.1s · internal/store ok 358.7s · internal/items ok · internal/mcp ok 21.0s · go vet clean · gofmt clean · make lint 0 issues. Postgres green on the parent commit (store 596.7s, server 294.7s, private container port 5481); re-running on this tree.	2026-09-04 17:04:52 +00:00
xarmian	2e9df62c80	fix: two codex round-2 findings — late defaults, UUID disclosure (TASK-2878) ... Round 2 confirmed the three round-1 fixes and found two more. Both real, both verified in the code before acceptance; codex still could not run anything ("the read-only filesystem prevented Go cache/temp creation"). ## THE DESTINATION-DEFAULT FIX ONLY COVERED HALF THE WAYS IN The migrate doors resolve BEFORE they validate, and that order is load-bearing: the required-field check has to see a value referent resolution dropped, or a dropped value in a REQUIRED relation field would store the item with the field absent instead of refusing. But `ValidateFields` INJECTS schema defaults, so a default can land after the resolver has finished. Two ways in, both now closed: - a NULL OVERRIDE deletes the key and the default fills the hole, arriving uncanonicalised — a `PEOP-1` default reached the row as the literal string; - a default the resolver DELETED as unresolvable is put straight back by validation, and `StillDropped` then suppresses the warning about it. Dropped, reported, restored, and reported as not-dropped. `ResolveLateRelationDefaults` is a narrow second pass over exactly the keys validation added. Reordering the two would have traded this defect for the required-field one; a second pass costs one lookup in the rare case a relation field declares a default and nothing otherwise. A default is asserted by nobody, so an unresolvable one is DROPPED and reported, never refused — the same disposition the main pass gives RelationOriginDestinationDefault, which is what this is: the same origin, arriving late. THE SNAPSHOT IS TAKEN AFTER THE MAIN PASS, NOT BEFORE, and getting that wrong is what the second sub-case caught. Snapshotting before the pass treats a key the pass DELETED as already examined, so the late pass skips the very value validation just put back — the arrangement that hid it. My first version did exactly this and the second sub-case failed on it. ## A REFUSAL FOR AN INVISIBLE ITEM DISCLOSED ITS UUID The store resolver rewrites a supplied ref into its target's id before the visibility check runs, so a message built from the resolved value handed back the canonical UUID of an item the requester may not see — confirming both its existence and its identity. That is the existence oracle the `not_found` collapse exists to prevent, reopened by the message. Every issue this function raises now quotes what the CALLER sent. ## Prior findings, per codex Override visibility: fixed. Bulk move dropped list: fixed. Nil-target race: no dereference. Destination defaults: this commit. ## Counterfactuals Neuter the late-default pass -> TestCopyEndpoint_LateInjectedRelationDefault DETECTED on both sub-cases. Restore the canonical UUID in the message -> TestCopyEndpoint_InvisibleRelationOverrideIsRefused DETECTED. Both mutants build-checked first. Gates: internal/server ok 346.3s · internal/store ok 351.3s · internal/items ok · internal/mcp ok 22.9s · go vet clean · gofmt clean · make lint 0 issues. Postgres green on the parent commit (store 534.5s, server 268.5s, private container port 5481); re-running on this tree.	2026-09-04 16:41:39 +00:00
xarmian	ed03d488da	fix: four codex round-1 findings — origin, visibility, bulk reporting (TASK-2878) ... Codex round 1 named four; three were real P1s and I verified each in the code before accepting it. Codex could not run anything ("Go could not create its build cache because the workspace is read-only"), so every finding here is a static read that I confirmed and pinned. ## A THIRD ORIGIN, not two `items.MigrateFields` injects the DESTINATION schema's defaults for keys the source item has nothing for. My classifier split on `supplied` versus everything-else, so a destination default was filed as CARRIED — and on a cross-workspace copy every carried relation drops without a lookup. The destination's own default was discarded and reported `referent_not_portable`, which is flatly false about a value the destination chose. There are three origins: SUPPLIED (refuse on failure), CARRIED from the source item (cross-workspace: drop as not-portable), and DESTINATION DEFAULT (resolve against the destination in BOTH modes; drop with the resolver's own reason on failure, because nobody in this request typed it). Telling the last two apart needs the source field map, which all four migrate doors have as `currentFields`, so it is now a parameter. Empty values are skipped at every origin. An empty relation is a cleared field, not a referent, and reporting it as dropped tells a user they lost something they never had. WHAT THE FIRST VERSION OF THIS TEST PROVED: nothing. The mutant that reverts the classifier SURVIVED it. `ValidateFields` re-injects the default after my resolver deleted the key, so the value comes back either way and `StillDropped` filters the false report out — the end state is identical unless the default is a REF. A UUID default is already its own canonical form, so "resolved" and "dropped then re-injected raw" produce the same bytes. With `PEOP-1` as the default the mutant is DETECTED, because only a resolved default lands as the id. ## SUPPLIED OVERRIDES AT THE MIGRATE DOORS SKIPPED THE VISIBILITY CHECK The four write doors go through `s.resolveRelationReferents`, which adds `checkItemVisible` on top of the store resolver. The migrate doors called `store.MigrateRelationReferents` directly — it is a store function and cannot answer a request-scoped question — so their SUPPLIED half, which this unit's own rule calls an ordinary write, resolved against the database alone. A caller able to edit both collections could point a relation at an item they cannot see. The ROLE is the part worth getting right. For `move` it is `workspaceRole(r)`. For copy and preflight it is the caller's role in the DESTINATION, and `CrossWorkspaceAccess.Role` is exactly that — its own doc says never to substitute `workspaceRole(r)`. So `resolveRelationReferents` now takes the role explicitly (`resolveRelationReferentsAs`), and the new `refuseInvisibleRelationOverrides` runs at all three doors with the right one. At the copy it runs in the HANDLER, before the store call: a pre-write refusal must not open a transaction to roll it back, and the preflight runs the identical check — DR-6's "the preview IS the copy" only holds if both doors refuse the same request. ## BULK COLLECTION MOVE DISCARDED FIELDS SILENTLY `bulkMoveCollection` has populated `result.Dropped` since MigrateFields existed and NOTHING read it — the only reference in the file was my own append. BUG-2674 fixed the single-item door and left this one, so a bulk move discarded values with no record anywhere. Pre-existing, and routing relation drops into the same dead list is what made it mine to fix. Reported on the activity row, same key, same joined-string shape and the same BUG-2628 reason as `handleMoveItem`, filtered against the final map so the report is true when written. Threaded as an out-parameter, deliberately: only this branch produces drops, the caller needs them for ONE activity row per item, and a third return value would put `nil` in fourteen unrelated returns. ## THE P2, AND WHAT IT IS NOT PINNED BY `resolveRelationReferents` did `if item == nil { continue }` after the visibility read — "treat a race as someone else's 404". It now refuses with the same `not_found` the resolver would have given moments later. This whole unit exists to keep a dangling referent out of the blob, and a target that vanished mid-request is the one case where waving it through would have been deliberate. NO TEST. Reproducing it means deleting a row between two reads inside one request, and a test that faked that would pin the fake. Stated here rather than left to look covered. ## Counterfactuals Every fix has a mutant that its own test detects, each build-checked first: classifier reverted -> DETECTED (destination default); empty-skip removed -> DETECTED; visibility helper neutered -> DETECTED at both the move door and the copy/preflight pair; bulk-move report removed -> DETECTED. Gates: internal/server ok 224.6s · internal/store ok 261.5s · internal/items ok · internal/mcp ok 15.1s · go vet clean · gofmt clean · make lint 0 issues.	2026-09-04 16:16:03 +00:00
xarmian	34861f8658	feat(mcp): ToolSurfaceVersion 0.29, and the drop-reason renderer it exposed (TASK-2878) ... PLAN-2857 U1. The bump, its documentation sweep, and the consumer this change turned from a rare wart into a routine one. THE BUMP, at 0.29 rather than 0.28. Rebasing onto main found b437cc58 (IDEA-2641, reminders) had ALSO taken 0.28 — a SEMANTIC collision, not a textual one: two different contracts under one number, and a client pinning "0.28" would have had no way to know which it got. Renumbered to 0.29, and main's 0.28 entry kept intact ahead of it. Also swept while resolving: main's CLAUDE.md carried v0.28 straight after v0.26, because the v0.27 bump (BUG-2850) never reached that file. Both places in CLAUDE.md now read v0.26 -> v0.27 -> v0.28 -> v0.29, and the README changelog line gains the v0.28 entry it never got. A BEHAVIOR bump on the 0.27 / 0.26 / 0.16 / 0.10 / 0.9 grounds — not on 0.28's, which was purely additive — no tool name, action enum or parameter shape changed, and `pad_item` now refuses calls it used to accept. A `relation` value must name a live item in the collection the field declares; a caller writing a resolvable value sees no difference, and one writing an unresolvable value was storing something no surface could render, so the break is the fix. No escape hatch, deliberately: unlike 0.10's `allow_draft` there is no legitimate call this refuses, and the case with a real claim to leniency — a CARRIED value — is already exempt by provenance rather than by a flag. Full entry in internal/mcp/version.go. instructions.md and README.md follow the constant because `internal/mcp`'s own drift gates require it; CLAUDE.md does not, which is exactly why it drifted. CLAUDE.md's `pad item move` / `pad item copy` reference also gains the relation semantics, which is the part a reader of that file is most likely to need and the part that just changed. THE CONSUMER, which is the interesting half. `dropped[].reason` is a wire enum with its renderer on the other side of a language boundary, and nothing made the two meet. BUG-2674 added `referent_not_portable` server-side; the TypeScript union and CopyItemDialog's `dropReason` switch never learned it, so it fell through `default: return reason` and the dialog showed a user the raw string. It went unnoticed because only `github_pr` produced it — and this change makes it the reason for EVERY carried relation on a cross-workspace copy, plus three more (`not_found`, `wrong_collection`, `target_missing`). A latent defect going live because my emission made the form routine. So the reasons are ENUMERATED rather than left as literals: `store.RelationIssueReasons()` owns the four the store decides, `preflightDropReasons()` composes them with the five this package originates, and the emission sites now use the constants. The new gate requires every entry to have a union member and a switch case. The gate is SCOPED to `dropReason`'s own body rather than searching the component, because another switch matching `case 'not_found':` for an unrelated purpose would satisfy it while the dialog still rendered the raw enum — a guard passing on the wrong evidence. If that function is renamed the test FAILS rather than silently passing on a body it can no longer find. Negative controls, all DETECTED: remove the dialog's `referent_not_portable` case; remove `wrong_collection` from the TS union; rename `dropReason` (which checks the scoping guard's own premise). What the gate does not claim: that a case EXISTS, not that its sentence is good — no test judges that. It is also blind to a renderer handling a reason the server never sends; that direction is a dead branch, the other is the defect. Gates: internal/server ok 162.8s · internal/mcp ok 13.6s · internal/store ok 192.2s · `npm run check` 0 errors (6 pre-existing warnings, unrelated files) · go vet clean · gofmt clean · make lint 0 issues.	2026-09-04 15:42:46 +00:00
xarmian	94eddb9b8a	test(server): the per-door x per-provenance table, and the defect it found (TASK-2878) ... PLAN-2857 U1. `internal/store` already tests the resolver exhaustively, but those tests call it DIRECTLY: they vouch for the component and say nothing about whether any door is bound to it. A door that never calls the resolver passes every one of them. This table is the binding claim — one leg per (door, provenance) pair, driven through the handler a client reaches. PROVENANCE IS THE SECOND AXIS BECAUSE THE ANSWER DEPENDS ON IT, not for symmetry. A SUPPLIED value is the caller's assertion and an unresolvable one is refused; a CARRIED value was asserted by nobody, and refusing it makes legacy items un-updatable, un-movable and un-copyable — the failure this unit would otherwise CAUSE while fixing another. Which provenance a door sees is a property OF THE DOOR, and getting it wrong is invisible until a legacy item meets it. THE TABLE FOUND ONE, ON ITS FIRST RUN. `bulkFieldUpdate` merges the item's STORED fields blob with the caller's `changes` before validating, and the resolver was pointed at the MERGED map — so a bulk status move or set-priority re-litigated every stored relation value and REFUSED the item. An item carrying a legacy relation value had its status and priority frozen by a field the operation never mentioned. Fixed the way the fields_patch door already handles it: resolve only the keys the operation CHANGES, read out of the coerced map so the value is final, written back so a supplied ref is still canonicalised. Verified by prediction before the run and by the leg failing against the unfixed code. THE DISPATCH MUTANT, which is what makes the table's coverage a measurement rather than a hope. Wire ONLY the two `extractParentLink` doors (update fields, update fields_patch) and neuter the other six by swapping their field-map argument for an empty one — types unchanged, so the mutant compiles and its verdict means something: build OK · failing legs: create (both), move (both), bulk move, bulk update supplied, copy, preflight. Update and update-patch pass. Exactly the six unwired doors, and only those. Then each door alone, eight runs: every one detected by its own legs and no other door's. That is the claim the table exists to make — each leg reaches its OWN door rather than being satisfied by a neighbour's check. ONE DOOR NEEDS A WEAKER INSTRUMENT, AND THE TEST SAYS SO. No bulk op puts a relation key into `changes` — `op` is a closed list and the only field values any of them set are `status` and `priority` — so that door's SUPPLIED branch is unreachable from outside. The first mutant run proved it: unwiring door 4 alone left every black-box leg passing. It gets a direct-call leg, labelled as vouching for the FUNCTION and not for a binding that does not exist yet, and kept for the same reason `bulkMoveCollection`'s refusal branch is kept: the day the bulk path grows per-field overrides, the branch must already refuse rather than be a silent no-op nobody notices is missing. Every refusing leg has a resolvable counterpart. Without them the table is equally consistent with a build that refuses every relation value. Gates: internal/server ok 156.1s · go vet clean · gofmt clean · make lint 0 issues.	2026-09-04 15:40:55 +00:00
xarmian	ee607047dd	feat(copy): the two cross-workspace doors resolve referents, with their pin (TASK-2878) ... PLAN-2857 U1, doors seven and eight. `migrateCopyFields` and `handleCopyItemPreflight` now take their relation decision from `store.MigrateRelationReferents` — the same function the four write doors and the two move doors already call, which is the entire reason it exists. The defect this closes: MigrateFields matches on key and TYPE, so a same-named `relation` field carried a SOURCE-workspace item id across the boundary and the preflight reported it as a clean carry. What landed in workspace B was a value naming a row in workspace A — unrenderable, and indistinguishable on read from a legitimate reference. Provenance decides, as at the move doors. A CARRIED value on a cross-workspace copy is dropped without a lookup (no id from A can mean anything in B) and reported through the `dropped_fields` channel BUG-2674 established; a SUPPLIED override is an ordinary write and an unresolvable one is refused, 400 validation_error on both doors, rendered by the same `store.RelationIssuesMessage` so one refusal cannot acquire two phrasings. `internal/server`'s `relationIssuesMessage` now delegates to it: the eighth door refuses from inside `store`, so the sentence had to be reachable there. Two things are threaded rather than re-derived, and both are load-bearing: - The TRANSACTION, not the pool. `migrateCopyFields` becomes a method taking a Queryer, and `copyItemAcrossWorkspacesTx` passes its `tx`. That function has held a transaction since its second statement, so a pool read from inside it can wait for a free connection while every pooled connection is blocked on this transaction's locks — the starvation shape BUG-2409 fixed for the attachment planner and this repo keeps a deterministic test for. This is what the day-70 handoff named as the reason these two doors were not wired with the other six. - The MODE comes from the `scope` MigrateFields was already given, not from a second boundary test. Two independent answers to "is this crossing a workspace" is how one request gets migrated one way and validated the other, and this path also serves a copy whose target IS the source workspace, where relations resolve and survive exactly as on a move. The destination workspace id is the resolution scope: a supplied override is a write into B and must name something that exists there. THE PIN, and why it is not a per-door table. These two doors sit in different PACKAGES and the code at both sites says so is how they drift unnoticed. A table with a row per door can be fully green while the two disagree about one request, which is the defect rather than a gap in coverage of it. So every case sends ONE body to BOTH endpoints: - carried relation — must drop on both, and the preflight must say referent_not_portable rather than the generic no_target_field, which is false here (the destination DOES declare the key, so that answer sends the reader to fix a schema that is fine); - supplied + unresolvable — both refuse, same status, same code, both name the offending field and value, and nothing is written; - supplied + resolvable — the positive control, supplied as a REF so resolution is visible in the result. Without it the first two legs are equally consistent with "relations always fail". Negative controls run, all three mutants BUILD-CHECKED first (a non-compiling mutant produces no `--- FAIL` lines and reads as survived): both doors unwired = DETECTED; preflight unwired alone = DETECTED; store unwired alone = DETECTED. Each single-door mutant failing is the pin's whole claim — neither door can be wired without the other. CONVE-23 sweep: the preflight's LIMITATION comment said this gap belonged in MigrateFields "for both callers at once". That is now false in its prescription as well as its premise — `internal/items` is DB-free by construction and cannot ask whether a string names a live item — so the comment records where the fix actually went and what of it remains open (`computed`, `terminal_options`, `unique_scope`). Gates: internal/server ok 170.0s · internal/store ok 296.1s · internal/items ok · go vet clean · gofmt clean · make lint 0 issues.	2026-09-04 15:40:55 +00:00
xarmian	f7caba5657	refactor(store): thread a Queryer through referent resolution (TASK-2878) ... Preparation for the two cross-workspace copy doors, landed on its own because it is independently correct and the doors are not. `migrateCopyFields` runs inside `copyItemAcrossWorkspacesTx`, which opens a transaction as its second statement. A resolver reading from the POOL there would issue pool reads while holding a tx — the deadlock this repo keeps a deterministic test for. So `ResolveRelationReferentsQ` and `MigrateRelationReferentsQ` take the executor, following the store's own convention (`GetItemQ`, `uniqueSlugQ`, `getCollectionInWorkspaceTx`); the pool-backed names stay as one-line shims for the six wired doors. Two small read helpers come with it. `collectionIDBySlugQ` returns the ID only — the referent check compares `item.CollectionID`, and the full model would pull in per-collection counts nothing here uses. `itemByRefQ` keeps `GetItemByRef`'s fallback to a bare item-number lookup, because a relation written as COLO-3 must keep resolving after its target collection is renamed, which is exactly what BUG-2873 made possible. internal/store ok (341.7s), vet and gofmt clean. WHY THE COPY DOORS ARE NOT IN THIS COMMIT. They were written and building, and I reverted them. Team CONVE-29 and the lead's condition both say the copy pair lands WITH its pin — one case driving BOTH doors, asserting identical drop-and-report for a carried relation and refusal for a supplied override — and I measured 58.9% context against a 65% ceiling, which is not enough for that pin plus the 270s server suite plus the commit. Landing the behaviour change unpinned would have been worse than landing nothing: the preflight and the store copy are the pair the code already warns will drift unnoticed, so they are the last place to accept an untested agreement. The design is complete and on the trail: derive the carry mode from the existing `items.MigrateScope` rather than a second flag, pass `tx` on the store side and the pool on the preflight side, refusals through the copy's existing validation-error channel, drops appended to `migrated.Dropped`.	2026-09-04 15:40:55 +00:00
xarmian	f6b1dd96cc	feat(server): the two same-workspace migrate doors resolve and report (TASK-2878) ... PLAN-2857 U1: `handleMoveItem` and `bulkMoveCollection` now take their relation decision from `store.MigrateRelationReferents` — the same function the two copy doors will call, which is the point of it existing. Within a workspace the targets are still present, so a correctly-related item KEEPS its relation across a move; only an unresolvable value is dropped, and it joins the `dropped_fields` report BUG-2674 established rather than failing the move. Refusing carried values here would make every legacy item permanently unmovable, and `internal/items` has accepted any string for a relation all along, so "legacy" is most of them. The bulk path carries no per-field overrides — only `status` — so every relation value reaching it is CARRIED and nothing there can refuse. It passes nil for `supplied` to say so, and keeps the refusal branch: it is unreachable today and stops being a silent no-op the day that path grows overrides. internal/server ok (270.8s), internal/store ok. KNOWN GAP, recorded rather than half-built: the two CROSS-workspace doors are not wired yet, and the reason is a real constraint rather than running out of road. `migrateCopyFields` is called from `copyItemAcrossWorkspacesTx` with a transaction already open (`s.db.Begin()` at the top of that function), so resolving a SUPPLIED override there would issue POOL reads while holding a tx — the deadlock shape this repo keeps a deterministic test for. The carried half needs no lookup at all and is safe; the supplied half needs `GetCollectionBySlugQ` / `GetItemByRefQ` so the resolver can run on the tx's connection, which is exactly the `...Q` convention the store already uses (`GetItemQ`, `getCollectionInWorkspaceTx`, `uniqueSlugQ`). Adding those two is the remaining work, and it is what makes one function genuinely serve all four doors.	2026-09-04 15:40:55 +00:00
xarmian	9b19a78459	feat(store): one migrate decision for all four carrying doors (TASK-2878) ... PLAN-2857 U1, third slice, on the lead's refined ruling: PROVENANCE decides, not which door you came through. * SUPPLIED (an explicit `--field` override on a move or copy) is a write like any other, so an unresolvable value REFUSES. * CARRIED (everything the source item already held) was asserted by nobody. `internal/items` has accepted any string for a relation all along, so most stored values are legacy — refusing them would make those items unmovable and uncopyable. Dropped and REPORTED instead. And carried values are not all alike, which is the refinement that keeps this from being one rule wearing four coats: * WITHIN a workspace (move, bulk move) the targets are still here, so a valid relation SURVIVES the move and only an unresolvable one is dropped, through the `dropped_fields` channel BUG-2674 established. * ACROSS workspaces (copy, and its preflight) every carried relation is dropped WITHOUT a lookup: the value names a source-workspace row and v1 excludes cross-workspace targets, so no amount of resolving in the destination changes what it means. Reported as `referent_not_portable` — the same reason `github_pr` uses, because it is the same fact about the same kind of value. `MigrateRelationReferents` is one function because the four doors sharing it is the point, not tidiness: the preflight lives in `internal/server` and the copy in `internal/store`, and the code already carries a comment saying those two sit in different packages and that is how they drift unnoticed. A preflight that says "carried" while the copy drops is one request answered two ways. Tests drive both provenances against both modes, because the same bad value must be a drop when carried and a refusal when supplied — a suite that only drove carried values would pass against a build that never refuses anything.	2026-09-04 15:40:55 +00:00
xarmian	987fc79fde	feat(server): refuse unresolvable relation values at the four write doors (TASK-2878) ... PLAN-2857 U1, second slice: the doors that take CALLER-SUPPLIED field values now refuse a relation value that does not name a live item in the declared target collection — create, update (full fields), update (fields_patch), and bulk update. The server half adds the one thing the store resolver deliberately does not: visibility. It folds into the SAME `not_found` reason rather than getting its own, because "that item exists but you may not see it" is an existence oracle, and this codebase has a standing rule against handing one out. Ordering at every door is after the shape check and after coercion, so one bad value produces one error rather than two describing it differently, and so the value is in its final form when it is resolved. `fields_patch` examines only the keys the patch carries — the resolver skips absent keys — so an unresolvable value already stored on an item is not re-litigated by an update that does not touch it. That mirrors the undeclared-key rule immediately above it, and it is what stops this turning every edit of a legacy item into a failure. Refusals use the ORDINARY `validation_error` shape with no new details key. The MCP stdio transport classifies errors by matching CLI stderr prose, so a structured field it cannot see would help nobody there, and a new error shape is a contract change for every client. Existing suites unchanged: internal/server ok (224.5s), internal/store ok (258.0s), internal/items ok. Nothing in the tree was writing a bogus relation value through these doors, which is what made this slice safe to land before the per-door pins.	2026-09-04 15:40:55 +00:00
xarmian	977132387d	feat(store): referent resolution for relation values (TASK-2878) ... PLAN-2857 U1, first slice: the rule itself, with no door wired to it yet. `ResolveRelationReferents` canonicalises every `relation` value in a field map to the target item's ID and reports the ones that cannot be resolved — same workspace, and the collection the field DECLARES. WHERE IT LIVES was forced, not chosen. `internal/items` is DB-free by construction and keeps the shape check only. `internal/server` cannot own it either: six of the eight coercion doors live there, but the eighth is `store.migrateFieldsForCopy`, and `store` does not import `server`. Putting it here is what lets the cross-workspace copy door and the preflight door reach the SAME function instead of two implementations of one rule — those two already carry a comment saying they sit in different packages and that is how they drift unnoticed. VISIBILITY IS NOT HERE, deliberately. "Can this requester see that item" is request-scoped and needs the user, role and auth mode; the server layer adds it via `checkItemVisible`, which already exists as the context-free predicate for exactly this reason. NO SLUG FALLBACK, which is a deliberate divergence from `ResolveItem` (UUID, then ref, then slug). Found by a test failing rather than by reading: "red" resolved, because it is the slug of the live Red colour. A relation field's contract is that it stores an item ID; a slug is neither an ID nor stable, so the same stored value could point elsewhere tomorrow. Worse, "red" is exactly the free-text value the pre-U2 editor wrote into these fields, so accepting it makes the corruption this unit exists to stop indistinguishable from a legitimate write. The client refuses the same match for the same reason (TASK-2868). Exact-TITLE resolution is U6. Issues are reported in SCHEMA order, not map order, because the copy preflight is one of the callers and is specified to be safe to call repeatedly and return identical results. Unresolvable values are left EXACTLY as supplied: the caller quotes them back, and a half-canonicalised map would make a drop report lie about what the source held. Verified rather than asserted: both lookups exclude soft-deleted rows (`ResolveItem` by contrast with `ResolveItemIncludeDeleted`; `GetItem` via `getItemScanQ`, which appends `AND i.deleted_at IS NULL`). That is what keeps "target was deleted" distinguishable from "never resolved" — the read half U2 shipped.	2026-09-04 15:40:55 +00:00
xarmian	b437cc582d	feat: item reminders — the fire-at-an-instant primitive, and one overdue rule for all four surfaces (IDEA-2641, closes #1010) (#1244) ... * feat(store): item reminders — the fire-at-an-instant primitive (IDEA-2641) Adds the storage, the scheduler tick, and the canonical event for one-shot item reminders (GitHub #1010). Nothing in Pad acted at a target time before this: a due_date makes an item show up as overdue once somebody asks the dashboard, so "revisit TASK-X on the 1st" had to live in an external cron. A TABLE, NOT A SCHEMA-FIELD ANNOTATION. The design sketch proposed marking schema date fields with a `reminds: true` key on models.FieldDef; recon overturned it. Such a key does not survive an ordinary collection edit, two independent ways: the web editor destructures each field into an EditableField and rebuilds a fresh definition key-by-key on save, so unknown keys are dropped (`pattern` and `unique_scope` survive only because two lines were hand-added for them), and models.CollectionSchema has fixed fields with no catch-all, so any Go unmarshal+marshal round-trip strips unknown properties — the hazard retargetRelationFieldsTx mutates raw JSON to avoid. Both failures are silent and both disarm a whole collection's reminders at once. It is the same defect class that moved traits out of the schema column in TASK-2657. The table also gives the lifecycle a home. A reminder is armed, then fired, then acknowledged, and a re-arm returns it to armed — per-reminder state a field definition has nowhere to keep. remind_at is an RFC3339 UTC instant, deliberately not a `date` schema value: those admit both YYYY-MM-DD and full RFC3339 and are compared against the SERVER'S LOCAL calendar day. A fire-at time cannot carry that ambiguity. The remaining timezone question for due_date is filed separately. Firing is one transaction per reminder carrying BOTH the fired_at write and the outbox insert. That pairing is the point: a fired_at committed without its event is a reminder that silently notifies nobody and can never be retried, because the row has left the armed set; an event without fired_at fires every tick forever. The UPDATE's own `fired_at IS NULL` predicate is the arbiter, so two instances ticking at once produce exactly one winner. item.reminder_due is admitted to the closed events/1 set as v1.2, with a new PayloadReminder family and no SSE name. The subject is the REMINDER, not the item: two reminders can be armed on one item, so an item-subject event could not say which fired, and the reminder id is what an acknowledgement addresses. A new payload family rather than reusing the item snapshot for the same reason — a snapshot would validate and still not answer the only question the event exists to answer. No SSE name in v1 because the poll surface is the contract; adding one later is additive, removing one is not. Ack is explicit and nothing else acks. An item reaching a terminal status deliberately does NOT ack: that would make every status write a reminder mutation, and it would silently consume a reminder set to fire after the work was done. * feat(server): reminder surfaces, and one shared overdue rule for all four Second half of IDEA-2641: the HTTP surface, the scheduler tick's wiring, and the fix for the finding that justified the unit — `ready` / `next` did no date handling at all. OVERDUE NOW HAS ONE IMPLEMENTATION. It used to live inline in the dashboard's attention loop, which meant `pad project stale` inherited it (it filters that very list) and the recommendation surface never saw it. So a deadline reached the two surfaces that REPORT on work and never the one an agent PULLS from. overdue.go is now the only place that decides, and all four call it. Two behaviour changes fall out, both deliberate: - An overdue item bypasses the orphan branch's high/critical priority gate. That gate was where a deadline quietly stopped: a low-priority item three weeks late was reported by `stale` and never suggested by `next`. - Overdue sorts above in-progress. The list is capped at three, so a rank below in-progress would not merely order the deadline lower — on any workspace with three things in flight it would keep an overdue item off the surface entirely, which is indistinguishable from not shipping this. The server-local-today comparison is UNCHANGED and known to be wrong for multi-timezone deployments; it is filed as its own item with the cloud case stated. Changing what "overdue" means on every existing instance inside a change about where the rule LIVES is the kind of behaviour change nobody reviews. Fired reminders reach `next` / `ready` two ways, from one filtered list: PendingReminders is the addressable form (it carries the id an ack needs), and a prepended suggestion is the rendered form. They are prepended AFTER the cap rather than entered as ranking candidates — a reminder is not a task competing on priority, and whether it appeared should not depend on how busy the workspace is. Terminal-item reminders are FILTERED from the surface, never acked. Acking on terminal status would couple every status write to reminder state and would consume a reminder armed to fire after the work was done. The row stays exactly as the user left it; the distinction is observable, and asserted. Three guard tests caught this change and each was answered rather than silenced: - The request-body reader guard was right: the handlers now go through decodeJSON, inheriting the NUL refusal and the size cap. - The canonical-events guard was right: item.reminder_due is admitted to the duplicated contract table as SPEC-3 v1.7, with the reminder subject kind and the new payload family. SPEC-3's own text owes the same amendment. - The NUL census asked for a decision on eight new columns. None carries caller text: ids and FKs are server-generated, four are the server clock, and remind_at is now re-parsed and re-formatted in the STORE as well as at the edge — so the stored value is always machine-produced from a parsed time and no caller bytes reach the column. The doc comment that used to say "the caller normalizes" protected nothing. Regenerating the baseline also found that GEN_NUL_BASELINE=1, which the test's own instructions name, was never implemented — the flag did nothing, so the documented path was hand-editing the file. Implemented, so the next reader gets the mechanism the instructions promise. * test(reminders): the lifecycle, the four surfaces, and 22 killed mutants Every test here was designed against a specific mutation and the mutation was RUN. A green suite proves nothing about a suite nobody tried to break, and three of the mutants I first wrote were not experiments at all. Store (10 mutants, all killed): candidate predicate <= flipped to >=; the event emission lifted out of the fire transaction; the fire UPDATE's `fired_at IS NULL` arbiter removed; the RowsAffected check ignored; re-arm clearing fired_at but not acked_at; ack losing `fired_at IS NOT NULL`; the poll surface losing `acked_at IS NULL`; normalizeRemindAt no longer refusing; it dropping .UTC(); GetReminder losing its workspace scope. Surfaces (12, all killed): the priority gate no longer bypassing on overdue; the sort no longer ranking overdue first; attention leaving the shared helper; the reason losing its OVERDUE prefix; the comparison flipped to >; terminal items no longer skipped; terminal reminders no longer filtered; the filter ACKING instead of hiding; reminders appended instead of prepended; the tick running on a far-future clock; ack answering 200 for an unfired reminder; parseRemindAt accepting a bare date. THREE MUTANTS DID NOT COUNT ON THE FIRST PASS and were rewritten. Two failed to compile (`if false` orphaned a variable; deleting a parse orphaned an import) and one had an anchor matching two call sites. A non-compiling mutant emits zero FAIL lines and reads exactly like a surviving one — it invents a hole that is not there — so the harness reports BUILD-FAIL and ANCHOR-BAD as outcomes distinct from SURVIVED. It also restores files from an in-memory copy rather than `git checkout`, which would delete uncommitted work in the tree. ONE MUTANT GENUINELY SURVIVED and the test was at fault, not the mutant: appending rather than prepending reminder suggestions was undetectable because the fixture had a single item, so the reminder sat at index 0 either way. The fixture now fills the three-item cap with in-progress work, where an appended reminder lands fourth and vanishes. Faithful mutant, weak test — checked in that order. The same lesson shapes the four-surface fixture: it is a LOW-priority open orphan, because that is the case the old code handled worst. A high-priority task would have made the ready/next leg pass against the unfixed tree, which is a green that measures nothing. Negative controls throughout: a future deadline is not overdue and does not reach the gate bypass; a tick with nothing due fires nothing; a completed item is neither overdue nor suggested. Without them a helper that reported every date, or a tick that fired everything, would satisfy every positive leg. The lead's pin is asserted in both directions: a fired reminder on a done item is ABSENT from the surface and PRESENT and still unacknowledged in the table. Asserting only the absence would pass against an implementation that consumed the row, which is the behaviour the pin exists to forbid. * feat(mcp): pad_item.remind + ack-reminder, ToolSurfaceVersion 0.28 An agent that can RECEIVE a reminder but not set one has half the primitive. The poll surface is pad_project.next / ready, both long exposed, so reminders already reached agents — what was missing is the other half: deferring a piece of work is exactly the moment an agent knows when it wants to be asked again, and it had no way to say so. Two additive actions, two optional params. Nothing existing moved, so a v0.27 consumer enumerating neither is unaffected — the v0.13 / v0.11 / v0.8 disposition, which likewise wired existing CLI verbs onto the catalog. remind_at REFUSES a bare date rather than reading it as midnight. Worth stating because the `date` schema type accepts YYYY-MM-DD and a caller will reasonably try it here: a bare date names a 24-hour span, and choosing an hour inside it would fire at a time nobody picked. Re-arm and disarm stay CLI-only. Both address a reminder by an id the agent would have to list first, and no listing action exists on this surface — a door with no handle. Adding them later is additive. Five guards had to be taught, and each was answered on its merits rather than excluded: the HTTP parity test (route mappers added, so the actions work on the remote transport rather than being advertised and unrouted), the read-only catalog's cmdhelp fixture and expected cmdPath map, the field- conflict classifier (remind_at / reminder_id are NOT field writers — a reminder is a row in its own table addressed by its own id, so listing them as classified sources would have pointed detectFieldConflicts at something that is not a field source), and the instructions.md / README action tables. That machinery is why the version bump is safe to make now, and it earned its keep on this change: every one of the five failed on the first build after the catalog entry landed. CONVE-23 sweep for prose this falsifies: - SPEC-3 (DOC-2653) amended to v1.7 in the room, recording item.reminder_due with its new subject kind and payload family — the first canonical event with no user mutation behind it, since a scheduler tick produces it. - CLAUDE.md gains the reminder routes, the CLI verbs, and the v0.28 entry. It was also stale at 0.26 with NO v0.27 entry at all: the 0.27 unit swept instructions.md and README.md and missed this file. Both added. - skills/pad/SKILL.md gains the verbs and a routing entry, including the two things an agent will get wrong — the time is an instant, so ask for a time of day rather than picking one, and finishing the item does not acknowledge the reminder. * fix(reminders): codex round 1 — four findings, all real, all with a pin Round 1 found four defects and refuted none of them. Each fix carries a test that fails against the code as it was, and each of those was mutation-checked. **P1 — pending reminders bypassed item-level visibility.** Every other dashboard section reads `allItems`, which the store already scoped to the caller's collections AND their granted item ids. The pending-reminder list is a direct workspace-wide query and inherited none of that, so a guest holding a grant on ONE item could read the refs and titles of every other item in the collection through its reminders — an item-level leak wearing a notification's clothes. Now filtered with the same `isItemVisibleToGuest` call the sibling sections use. The test's two items share a COLLECTION on purpose: a collection-level filter was already applied, so separate collections would have made it pass against the unfixed code. **P1 — soft-deleted items could starve the queue permanently.** Candidate selection ignored `deleted_at`, and `fireOneReminder` rolls back when it finds the item gone — which leaves the reminder ARMED and therefore a candidate again on the next pass. Candidates are ordered oldest-first and bounded by a limit, so enough archived reminders fill every batch and no live reminder ever fires. Silent, too: the tick reports zero fired and looks idle. Excluded in the candidate query rather than skipped downstream, so those rows never occupy a slot; the reminders themselves are kept, so restoring an item restores its reminder with it — asserted, because a fix that reaped them would pass the starvation test alone. **P2 — the pass stopped at the first failing reminder.** The per-reminder transaction exists precisely so one unfireable row cannot hold back the rest, and `return fired, err` made that comment false — with candidates oldest-first, one persistently broken old reminder blocks every newer one forever. Now continues and joins the errors, so a pass that fired seven and failed three reports both halves rather than reading as clean. The loop is split behind an injected seam because a real mid-transaction failure is not reachable from outside: the database refuses the corrupt rows that would cause one (verified — invalid JSON in items.fields is rejected by the schema). **P2 — suggestions dropped the reminder id.** The docs tell an agent to acknowledge what it sees in next/ready, and the payload carried no handle: a stateless poller could read the reminder and had no way to retire it, so it would be shown the same item forever. `DashboardSuggestion` now carries `reminder_id` (omitempty), `pad project next` prints the exact ack command, and the test acks with the id the surface handed out rather than merely checking the field is populated — a wrong-but-present id satisfies equality with itself. Four mutants, four killed; one was rewritten first because its anchor matched two call sites and was therefore not an experiment. * fix(reminders): codex round 2 — four findings, all real **`--rearm` was unusable.** `ExactArgs(1)` forced an item ref that the rearm branch then ignored, so the flag could not be reached without supplying a ref that was silently discarded. Now `MaximumNArgs(1)`, with each mode checked explicitly: a ref is required to arm, and a ref supplied ALONGSIDE `--rearm` is refused rather than ignored — it names an item the reminder may not even belong to, and quietly dropping it is how a user learns nothing about the reminder they just moved. **`unremind --format json` emitted plain text**, breaking the parseable-output contract every sibling command honours. **The MCP `ref` param did not list `remind`.** Agents read that flat description to decide what to send, so an action missing from it is an invalid call waiting to happen. It now also says what `ack-reminder` takes instead, and why: a reminder is addressed by its own id because an item can carry several. **Fractional seconds fired early.** `time.Parse` accepts `09:00:00.900Z` and `Format(RFC3339)` drops the fraction, so it was stored as `09:00:00Z` and fired 900ms BEFORE the moment the caller named — silently, having rewritten their value on the way in. Seconds are genuinely the stored resolution (the column is compared as a string against a whole-second clock, and the tick runs every 30s), so the only question was which way to resolve it, and truncation resolved it the wrong way. `NormalizeInstant` now rounds UP: at most a second of lateness, in exchange for a guarantee that can be stated — a reminder never fires before the instant it was set for. Late is a reminder; early is a wrong answer. Whole seconds round-trip exactly, which is asserted, because an implementation that added a second unconditionally would otherwise pass. Three mutants for this round, three killed (round-up→truncate, round-up→unconditional-add, MaximumNArgs→ExactArgs). Thirty across the unit. Two fixes carry no dedicated test and it is worth being explicit rather than implying coverage: the `--format json` branch on `unremind` is a one-line output change with no server-free way to drive it, and the MCP `ref` description is prose the drift tests do not read — they assert an action is DOCUMENTED, not that a param's sentence lists it. * docs(reminders): the ack id is on the surface an agent polls, not only on the arm response CONVE-23 follow-through on the round-1 fix. Both agent-facing docs told a caller to acknowledge a reminder with the id "returned when you armed it" — true, and useless to the caller that matters: a poller reading next/ready never armed anything. The suggestion now carries reminder_id and `pad project next` prints the exact ack command, so the docs say that instead. The prose was written before the fix existed, which is exactly the case CONVE-23 is about: a change that makes an instruction stale without touching the file the instruction lives in. * test(reminders): bind the tick LOOP to the work, not just the pass (CONVE-19) Every other test in this file calls runReminderTick directly. That vouches for the component and says nothing about whether anything ever calls it — a tick that is never started is indistinguishable, from those tests, from one that is. It is the convention's exact case, and the failure I recorded on my own identity doc three times in one unit: I test the component and not the binding. Driven through the injectable tick channel so the assertion pins a SPECIFIC pass instead of racing a 30-second ticker, and polled to a bounded deadline so a loop that never runs FAILS rather than hanging the suite. Mutant: drop `s.runReminderTick()` from the select and this goes red while every direct-call test stays green. Killed. The idempotence leg exists because a second Start spawning a second loop would leave one running after Stop, making the BUG-842 drain invariant false for this sweeper specifically — the one property a copied lifecycle is most likely to get right by accident and least likely to be checked. The cmd/pad call site (cmd_server.go, alongside StartTokenReaper) stays verified by inspection: a source-scanning guard for it would be an instrument asserting facts about source, which is code with an adversary and not worth it for one line that sits in the middle of five identical neighbours. * fix(reminders): codex round 3 — a deferred reminder fired anyway, and the poll surface was unbounded **A re-arm mid-pass did not stop the fire.** The candidate scan selects an id; before the UPDATE runs, a `--rearm` can move that reminder into the future. Re-arm clears `fired_at`, so a predicate checking only `fired_at IS NULL` still matched — the pass fired a reminder the user had just deferred and emitted its event. The re-arm cannot undo that: it can clear the mark, but the event is already on the outbox and at-least-once means a consumer has seen it. The fire UPDATE now revalidates `remind_at <= nowTS` against the SAME nowTS the candidate scan used. Same-value deliberately: the arbiter and the scan must agree about when this pass is, or a reminder could pass one and fail the other for no reason but clock drift inside a single pass. **The poll surface was unbounded.** Every fired-and-unacknowledged reminder was loaded and turned into a suggestion prepended to a list that is otherwise capped at three, so a workspace with five hundred unacknowledged reminders returned five hundred suggestions — in the dashboard response, the hottest read in the product, growing until somebody acknowledged them. Two bounds, because they are two different guarantees: the query takes a window (default 50, oldest-fired first, so it holds what has waited longest), and the prepended suggestions are capped at 5 so `suggested_next` stays a recommendation rather than a second inbox. The full set stays addressable in `pending_reminders`. Truncation is REPORTED as a boolean, not a count. A count would have to be post-visibility-filter to be true for the caller reading it, and the store cannot compute that — the filter runs per item, above. "There are more than you can see here" is the strongest claim the data supports, so it is the one made. Four mutants; two killed outright, two survived and were run down under CONVE-28: - **Uncapped suggestions survived because the fixture had ONE reminder** — capped and uncapped are the same list at n=1. That is the SECOND time a single-item fixture hid a count-or-order property in this file. Fixture now arms eight; it also asserts all eight remain in `pending_reminders`, so the cap is pinned to the recommendation and not to the data. - **Removing the SQL LIMIT survived, correctly, and the test comment now says so.** The Go slice cap bounds the PAYLOAD; the SQL LIMIT bounds the DATABASE'S work. Only the first is observable at this level — with the LIMIT gone the response is still bounded, while the query silently goes back to materialising every pending row before discarding most of them. That is a memory and I/O property with no assertion available here, so it is stated as a coverage boundary rather than papered over with a green that would not have measured it. * docs(reminders): the fire predicate arbitrates against two actors, not one CONVE-23 inside the file the round-3 fix touched. The comment described the UPDATE as an arbiter for concurrent TICKS, which is what it was written for and is why I did not re-read it when asked whether a user edit could race the pass. It now says what it actually defends against, and names the general shape: an arbiter is only an arbiter with respect to the writers it can see. * fix(reminders): codex round 4 — the round-3 bound recreated the round-1 starvation Round 3 bounded the poll surface. Round 4 caught what that bound did: the query took the first N rows and the dashboard then discarded the ones it could not show — hidden items, unauthorised items, completed items — so N such rows hide a visible reminder behind them indefinitely, with no continuation to reach it. That is the SAME defect I had removed from the fire path one round earlier, reintroduced in the read path within the hour. The general form is worth stating because I clearly did not hold it: **a bounded window is only safe when the discarding happens BEFORE the bound.** Filtering above a limit is a starvation every time, and it does not matter what the filter is for. Two halves, because the two filters are not the same kind of thing: **Visibility is now scoped IN SQL**, using the same collection-id / item-id sets every other dashboard section gets through `allItems` — the same three-way shape as ItemListParams, where holding both collection grants and item grants is an OR. Invisible rows no longer occupy the window at all, which is strictly better than filtering them out afterwards and is what the sibling sections have always done. **Terminality is paged**, because SQL cannot evaluate it — a collection's schema defines which statuses are terminal. The collector refills from the next page when a page comes back short, bounded by a max scan so a workspace full of completed items cannot turn a dashboard read into a table scan. The bound is 10x the window: the common shape fills on the first page, and the pathological shape terminates in a fixed number of indexed reads. Stopping at the scan bound reports truncation, which is honest — there may be more, and we did not look. The empty-scope case is a THIRD state that reads like the second: nil CollectionIDs means unrestricted, a non-nil EMPTY slice means this caller sees no collections. Without an explicit guard they collapse, because the switch matches none of its cases at length zero and adds no clause at all — so "nothing visible" would return the whole workspace. Three mutants, one survived: the empty-scope guard, because no dashboard-level test produces that state (callers that would are refused earlier by workspace access). Faithful mutant, missing test — it now has a direct one, with a sanity leg so a build returning nothing cannot pass it by accident. A guard for a state nothing exercises is exactly the one that rots. * fix(reminders): codex round 5 — the MCP action I shipped did not work over stdio **P1: local stdio MCP `remind` was unusable.** cmdhelp derives positionals by regex from a command's `Use` string, and `<instant>` inside `remind <ref> --remind-at <instant>` matched — it became a second REQUIRED positional, so dispatch failed with `missing required argument "instant"`. The action was advertised on a transport where it could not run. **The MCP catalog's own tests did not catch it, and the reason is the finding.** That suite builds its cmdhelp document BY HAND: I wrote `Args: mkArgs("ref")` in it, so the fixture agreed with what I meant rather than with what the CLI says. Five parity and drift tests passed against a document I authored to match my own intention — the "a test that agrees with whatever the table says is not a test of the table" shape, which the canonical-events test warns about in its own comment two packages away. The new test reads the REAL command tree via cmdhelp.Build, which is the only thing in this repo that can disagree with me about what the CLI declares. **P2: `pad project ready` withheld the ack handle** that `next` prints. Showing a fired reminder on the surface an agent polls while withholding the id it needs to retire it means the same entry comes back on every poll, forever. **P2: suggestions asserted a collection they did not have.** The orphan branch admits ANY collection — its own comment claimed it gated on tasks "mirroring the active-plan branch", and that comment was simply false — while the output hardcoded `Collection: "tasks"` and the reason said "Open task". Pre-existing for high-priority items since BUG-1082; my overdue bypass widened it to any overdue item, which is how it surfaced. Fixed by carrying the item's REAL collection rather than by narrowing the branch: narrowing would silently drop the non-task items this has surfaced for a year, and the defect is the mislabelling, not the inclusion. The false comment is replaced with what the code actually does. The first version of that test used an overdue IDEA and SKIPPED — ideas use `new`, and the branch requires `open` or an active status, so it never became a candidate. A test that cannot fire is a failed reconstruction, not a pass; the fixture is now a bug-like collection whose vocabulary contains `open`, which is the population the defect can actually reach. Three mutants, three killed. Forty-one across the unit. * fix(reminders): codex round 6 — reminders fired from soft-deleted workspaces **P1, and the only defect in this unit whose consequence leaves the process.** Workspace soft-delete deliberately keeps items for the 30-day restore window, so the candidate query's filter on the ITEM's deleted_at found nothing wrong — and the tick kept firing, emitting outbound webhook events for a workspace whose owner had deleted it, possibly while deleting their account. Both queries now join workspaces and require `w.deleted_at IS NULL`. Nothing is destroyed: a restored workspace resumes firing, which the test asserts, because "stops firing" and "is destroyed" are very different answers to someone who restores a workspace and only one of them is right. That test first failed for the WRONG REASON and the fixture was at fault: it counted every outbox row in the workspace, and item creation writes its own, so the assertion was satisfiable by the fixture itself and discriminated nothing. Scoped to the reminder event type. **`Use: "remind <ref>"` declared a requirement the command contradicts.** cmdhelp derives the machine-readable arg spec from that string, and `--rearm` takes no ref — so the published contract said "required" for something optional. The requirement is CONDITIONAL, which cmdhelp cannot express, so the honest declaration is `[ref]` plus the explicit check that names both call shapes. The round-5 test grew a `required` column, which is what makes this observable at all: asserting only the arg NAMES would have passed. **The pad_item tool description omitted both new actions.** The params were declared and the actions dispatched, but the prose an agent reads to decide what a tool can do did not mention them — discoverable only by someone who already knew to look. It now describes both, including the two things an agent gets wrong: remind_at is an instant, and nothing but an explicit ack retires a fired reminder. Three mutants, three killed. Forty-four across the unit. * fix(reminders): codex round 7 — one predicate for the scan and the arbiter Third instance of one class, so this fixes the SHAPE rather than the instance. The class: the candidate scan filters on something the fire transaction does not revalidate, so a change committed between them fires a reminder that no longer qualifies. Round 3 was a re-armed instant. Round 1's soft-deleted item was the same thing caught from the other side. Round 7 is a workspace deleted between the scan and the fire — the round-6 fix added the condition to the SCAN only, and the arbiter went on not knowing about it. Fixing those one at a time is what let the third happen. `reminderFireable` is now a single string that both sites reference: the scan asks it and the fire UPDATE re-asks it, so they cannot disagree, and a fourth condition is one edit in one place rather than two edits someone has to remember are paired. Written as a correlated EXISTS on item_reminders.item_id rather than a JOIN precisely so the identical text is valid in both a SELECT and an UPDATE, and the scan drops its table alias so the two uses are the same characters. What deliberately stays outside it: `fired_at IS NULL` and `remind_at <= ?` live on the reminder row itself, are already spelled identically at both sites, and folding them in would need a parameter order the shared form cannot express. Said in the comment so the omission reads as a decision. Both directions are now tested at the arbiter — a workspace deleted mid-pass and an item deleted mid-pass — because the item case previously relied on the item load coming back nil, and someone simplifying the EXISTS down to the workspace check alone would otherwise still see green. Three mutants, three killed: the arbiter dropping the shared predicate, and the predicate dropping each of its two halves. Forty-seven across the unit. * fix(reminders): codex round 8 — workspace export silently dropped every reminder WorkspaceExport is a hand-maintained field list, so a new table joins it only if someone remembers. Reminders did not: a backup/restore, or a SQLite→Postgres migration via `pad db migrate-to-pg`, dropped every pending reminder with nothing in the destination to show anything had gone. The line that list has always drawn is item-scoped workspace CONTENT (comments, links, versions — exported) versus per-user state (stars, watches — not). A reminder has no user column and hangs off an item, which puts it on the exported side. Stating the rule rather than just adding the field, because the next person adding a table needs to know which side they are on. LIFECYCLE MARKS ARE CARRIED, not reset. A fired-and-unacknowledged reminder is still owed to whoever armed it, so it arrives pending; an armed one whose instant has passed fires once on the destination's first tick, which is what would have happened had the workspace never moved. Re-arming everything on import would invent a schedule the user did not set. NULL rather than empty string for the unset marks — the lifecycle is defined by NULL-ness, and "" would make a never-fired reminder read as fired at "". TestMigratedTablesCoversTheExport caught the second half, which I would have missed: `pad db migrate-to-pg`'s NUL preflight decides what to REFUSE on from MigratedTables, so a table the migration copies and the preflight does not know about is a gap in exactly the guard that exists to prevent one. Added there too, with the reason it can never actually fire — every column is machine-produced, so it is listed for coverage rather than expectation — and the "six tables" prose it falsified is now seven. Two mutants, two killed: export dropping the block, and import discarding the marks. Forty-nine across the unit. * test(reminders): state the fire-path invariant and pin it from the invariant The lead's read on why rounds 4 and 7 were the same class: the fire path had no stated invariant, so each fix defended an instance. This states it, and derives the pin from the paragraph rather than from the bug history. THE INVARIANT: the candidate scan is a hint and may be assumed to prove nothing. Every condition that made a row a candidate is re-asserted inside the transaction that marks it fired, in the same statement that does the marking, so checking and writing are one atomic act. Worded as "the scan proves nothing" rather than as a list on purpose — a list invites the next person to add a condition to the scan and stop, which is exactly what happened four times here. TestFirePathInvariant is the pin: one table, one row per scan-side condition, each invalidating that condition in the window between the scan and the fire and asserting the same three things — nothing fires, no event leaves, the reminder is not consumed. The earlier per-defect tests are folded in as rows; they said the same thing one instance at a time, which is how four of these shipped. Adding a fifth condition to the scan without a row here should feel like an omission. It carries a positive control, because four cases that all assert nothing happens would pass against a build that never fires at all. The matrix immediately falsified a claim in the paragraph I had just written. I wrote that the item load inside the transaction is "for the payload, not for the check"; removing the item half of reminderFireable alone changes no observable behaviour, because the load then returns nil and the deferred rollback undoes the write. Item liveness is defended TWICE and a single-mutant experiment cannot say which guard is carrying it — removing both is what kills the test. Both are kept, the predicate is named as primary (the row never matches, so no write happens at all), and the asymmetry is stated: workspace liveness has no second line, which is why dropping ITS half does fail the pin. Six mutants: five singles plus the pair. Five killed alone; the item single survives by design and is documented as such rather than left as an unexplained green. Fifty-five across the unit. * fix(reminders): codex round 9 — one legacy row could hide every reminder **P1: items.item_number is NULLABLE and I scanned it into an int.** Migration 006 added the column to existing rows, so a pre-numbering item still carries NULL — and scanning NULL into an int fails the Scan, which fails the QUERY, which degrades the whole pending-reminder section. One old row, and the feature is dark for everyone in that workspace. ListWatchesForUser, which this query was modelled on, uses sql.NullInt64 for exactly this column. I copied its shape and dropped the part that handles the column's actual nullability — the same way of being wrong as the round-5 cmdhelp fixture: borrowing a form without borrowing what it knows. The legacy row now carries no ref rather than a fabricated "PREFIX-0", which would name a different item. **P1: export shipped reminders that import could only discard.** The items section filters on deleted_at IS NULL, so a soft-deleted item is not in the bundle and its reminder can never be reunited with it. My comment claimed the item_links rationale — round-trip the raw graph so a restore reunites them — which is true for links and false here, because links keep soft-deleted endpoints in the bundle and items do not. A link is a row ABOUT two items; a reminder whose item is absent is a dangling schedule. **P2: import wrote remind_at raw.** Import is a writer, and a bundle is not necessarily one this server produced — hand-edited, or from another instance. A local offset or a bare date would land in the one column every comparison downstream treats as a UTC instant, firing early, late, or never. It now normalizes like every other door. An unparseable value is SKIPPED with a warning rather than failing the restore, matching the lenient import-side precedent already in this file, and the raw value's LENGTH is logged rather than its content. Three mutants, three killed; two needed rewriting because the single-line form did not compile — reverting the nullable scan also requires reverting the render, and dropping the normalization orphans a variable. PROCESS FAULT, recorded because it makes this round's findings weaker than they look: I edited the tree while this review was reading it — committed the invariant work and ran five mutation experiments, which write and restore source, over the same files. A review binds to the tree it read and I moved it underneath. Every finding above was re-verified against the current tree before being acted on, and the next round runs with no concurrent edits. * fix(reminders): codex round 10 — one orphaned item aborted a whole restore An ORPHANED item — one whose collection is missing from the bundle — still gets an itemMap entry. It has to: the entry is written before the skip because parent resolution inside the same loop reads the map for items it has not reached yet. So `itemMap[x] != ""` is satisfied by an id that names no row, and inserting a foreign key to it fails (SQLite enforces FKs here via the DSN's `_pragma=foreign_keys(on)`; Postgres always does). The pre-existing mapping is the sharp edge. The aggravating half was mine: this loop treated a failed reminder insert as FATAL, where item_links and item_versions both skip, so one orphaned item carrying a reminder rolled back an entire 900-item workspace restore. A reminder is the least critical thing in a bundle and it had the strictest failure handling in the file. Both halves fixed: the loop gates on items that actually landed, and a failed insert warns and skips like its siblings. TWO GUARDS THAT ONLY DIE TOGETHER, and this is measured rather than assumed. Reverting either alone leaves the test green — with the map gate restored the skip survives the FK failure, and with the fatal return restored the gate means the insert never fails. Removing both is what fails it. They are kept as a pair because they defend the same failure at different depths (prevent the bad write / survive a bad write arriving some other way), and the pair is recorded in the code so a future reader does not delete one as dead after watching its mutant survive. Second time this shape appeared today; the first was item liveness on the fire path. The bundle in the test is hand-built, because ExportWorkspace cannot produce an orphan — which is the reason it needed a test. That shape only arrives from a hand-edited or foreign bundle, and surviving those is what import is for. Three mutants: two singles that survive by design, plus the pair that kills. Sixty-one across the unit. * fix(reminders): codex round 11 — four contract slips, one of them another unit's **suggested_next returned up to eight entries against a cap of three.** Round 3 prepended reminders PAST the list's own cap, reasoning they should not compete for slots. Every consumer — the web dashboard, `pad project next`, `pad project ready` — is written for three. Worse, it silently falsified a decision recorded elsewhere: BootstrapDashboard deliberately has no suggested_next_overflow_count BECAUSE this list is capped at three upstream, and its comment names raising that cap as the moment to add one. My change made another unit's reasoning wrong in a file I never opened. The combined list is now trimmed back to three, reminders still leading — a reminder can push a task suggestion out, which is the right way round, and the full set stays addressable in pending_reminders. My first version of that trim used `limit`, which is REASSIGNED above to len(candidates) — so on a workspace whose only entries are reminders it would have truncated to zero, killing precisely the case the surface exists for. Caught by reading the surrounding lines before running anything; it has its own test now. **pending_reminders was uncapped in the bootstrap projection.** BootstrapDashboard embeds *DashboardResponse, so every new field joins the boot payload automatically — here, a window of up to 50, which is the budget PLAN-1410 spent a unit trimming. Capped at 5 with an overflow count, under its own constant rather than borrowing bootstrapAttentionCap: they answer different questions and a future change to one must not silently move the other. **Truncation was reported from the wrong question.** The collector used the store's `more` flag, which answers "is there another PAGE", not "did I read all of THIS one" — so a window filling part way through the final page reported that the caller had seen everything while unread rows sat behind the fill point. The paging bounds are now injectable so the case is testable at all: building it with a window of 50 needs ~75 rows in a specific pattern, with a window of 3 it is four. **Import accepted acked-without-fired**, which is not one of the lifecycle's three states. Such a row fires, is excluded from the pending surface because it is already acked, and can never be acknowledged because AckReminder requires acked_at IS NULL — an event emitted into permanent invisibility. The acknowledgement is dropped and the schedule kept, since an ack of something that never fired means nothing. Five mutants, five killed (one rewritten — removing the flag orphans a variable). Sixty-six across the unit. * fix(reminders): codex round 12 — a read is not a hold; scope the arm; ack from the ack Four P2s from round 12 (two independent runs, both landing on the same line of the fire path), each closed at the layer where it lives: - fireOneReminder pins the item and workspace rows FOR NO KEY UPDATE on Postgres before the arbiter UPDATE. reminderFireable re-asserted liveness at the predicate's instant and nothing held it to the commit instant; under READ COMMITTED an archival could commit in between and the event left the process about a deleted resource. Same idiom and same lock strength as CreateAttachmentForLiveItem; SQLite is excluded by its BEGIN IMMEDIATE, not skipped for convenience. Two PG-only pins verify "blocked" in pg_stat_activity, not by elapsed time; the pin-removed mutant fails both. - CreateReminder asserts "live item of THIS workspace" in the INSERT's own SELECT and returns ErrReminderItemGone otherwise. The table had an FK and no same-workspace constraint; a mismatched pair fed another workspace's title to this one's dashboard and webhooks. Handler maps it to 404. - AckReminder matches every fired row (COALESCE keeps the first ack, updated_at moves only when acked_at does), so a no-match means exactly "not fired at the instant of the ack". The handler no longer decides 409-vs-200 from the row it read before the UPDATE. - The invariant paragraph gains its missing sentence: "at that instant" means the commit instant, and the pin is what makes the predicate's instant and the commit instant the same one. Round-12 caveat carried: both runs were static reads (sandbox blocked Go's build cache), so "four" is a floor, not a measurement. Refs IDEA-2641 * fix(reminders): codex round 13 — a reminder's workspace must agree with its item's, at every read Every reader scoped by r.workspace_id and then joined the item without asserting the two agree. No door writes a disagreeing row today (CreateReminder derives the pair from the item; import maps within the workspace), and the table has nothing that forbids one — so a hand-edited bundle, a future move door, or a direct write would carry one workspace's item into another's dashboard, export, and webhooks. The identity goes into reminderFireable (scan + arbiter), the Postgres row pin, ListPendingReminders and the export query. One test writes the row raw — the only way one can exist — and asserts it is inert at each site; the predicate-removed mutant scans and fires it. Refs IDEA-2641 * fix(reminders): codex round 14 — the by-id and by-item reads assert the same identity as every other read GetReminder scoped by the row's own workspace_id and ListRemindersForItem by item_id alone, so a row whose two columns disagree — the class rounds 12 and 13 closed at the scan, the arbiter, the pin, the pending surface and the export — was still readable through the two reads that reach a single row. reminderOwned is that identity on its own, without the liveness half those two reads must not have (a fired reminder on an archived item is history worth showing). The write paths reach a row only through GetReminder, so scoping it scopes them; a row no door can write needs no door to delete it. ListRemindersForItem now takes the workspace its caller already resolved the item in. The raw-row test asserts both reads refuse the row from both sides; the reminderOwned-removed mutant surfaces it through GetReminder. Refs IDEA-2641 * fix(reminders): codex round 16 — an archived item's reminders are readable, and its verbs say "archived" The doors resolved the item live. Listing an archived item's reminders answered 409 from a GET, and ack/re-arm/delete answered a bare 404 for a reminder that exists on an item that exists — while the store, since round 14, deliberately keeps that history readable. The API already has a posture for archived items: GET reads them, mutations answer 409 "archived … restore it before editing" (writeItemResolveError). The list now follows handleGetItem; the lifecycle verbs load the item include-deleted, run the visibility check first, and then answer the same 409 every other item mutation does. One test walks archive → list 200 / ack 409 / arm 409 → restore → ack 200 on the same rows. Refs IDEA-2641 * fix(reminders): codex round 17 — one suggestion per item, the archived 409 by slug, and the door courtesy named Three findings on the server pass. (1) An item that was both a fired reminder and an ordinary candidate appeared in suggested_next twice; the ordinary entry is dropped, the reminder entry (which carries the ack id) stays, and two reminders on one item remain two entries. (2) Round 16's 409 for an archived item's reminder was written by re-resolving item.Ref, which is derived and empty for a legacy item with no item_number — so the class most likely to be legacy fell through to a bare 404. The slug is handed over instead. (3) The archived check in resolveReminderForWrite is check-then-write, and an archive landing in between lets the verb through: accepted and documented — it is the posture of every item mutation here (UpdateItem's UPDATE has no liveness clause), the outcome is benign, and putting liveness in AckReminder's WHERE would re-create the no-match ambiguity round 12 removed. Refs IDEA-2641	2026-09-04 11:36:11 -04:00
xarmian	a1716d8170	ci(web): decide the npm audit gate from the report, not the exit code, and run it last (BUG-2881) (#1247) ... * ci(web): decide the npm audit gate from the report, not the exit code, and run it last (BUG-2881) `npm audit` exits non-zero identically for "a HIGH/CRITICAL advisory exists" and "the advisory service was unreachable". The Web job ran it before Build / Type check / vitest under `bash -e`, so a registry timeout (main, 03:50Z) and a 503 (#1246, 04:33Z) on 2026-09-04 each produced a red row with every frontend verification step SKIPPED — a lane that read like a failure and had asked nothing. scripts/ci-audit.mjs runs the audit in --json mode and decides from the report: metadata.vulnerabilities present → fail iff high+critical > 0, naming the advisories; an error envelope or unparseable output → a GitHub warning annotation saying the gate did not run, exit 0. The step moves to the end of the job so the frontend's own verdict always exists whatever the audit does. Verified locally against five report shapes (transport timeout envelope, E503 envelope, one high advisory, clean, garbage) and two live runs (the real registry: clean; a dead registry: warning, exit 0). `--input <file>` is the seam those checks use. Fixes BUG-2881 * ci(web): the audit gate fails closed — retry an unreachable advisory service, then fail under its own title Codex round 1 on #1247: the first draft warned and exited 0 when the advisory service could not be asked, which made the only supply-chain gate pass exactly when it had not run. A gate that passes when it cannot run is not a gate. Now: up to three attempts with backoff (registry blips are usually seconds long), then `::error title=npm audit did not run` and exit 1. The title is distinct from `::error title=npm audit` (a real advisory) so the checks tab tells the two apart without opening the log; re-running is the remedy for the first and never for the second. Because the step runs last, Build / Type check / vitest have already produced their result either way — the original blindness is gone regardless of which way this step fails. Verified against the same five saved shapes (transport and E503 envelopes and garbage now exit 1 under the did-not-run title; a high advisory exits 1 under the advisory title; clean exits 0) and two live runs (real registry: clean; dead registry: three attempts logged, exit 1). Refs BUG-2881 * ci(web): the audit gate refuses counts it cannot read, and refuses bad tuning without crashing Codex round 2 on #1247. (1) metadata.vulnerabilities was checked for presence, not for shape: Number("x") + Number(null) > 0 is false, so a malformed count read as a clean audit — a second fail-open, one layer deeper than round 1's. high/critical must now be non-negative integers or the report is unreadable, which is the fail-closed path. (2) The two env knobs are operator-set, but CI_AUDIT_ATTEMPTS=NaN left the retry loop unexecuted and threw a TypeError, and CI_AUDIT_BACKOFF_MS=Infinity parked Atomics.wait forever; both now fall back to the default with a line saying so. Refs BUG-2881 * build: the local preflight runs the same audit gate CI does, and runs it last Codex round 3 on #1247 (blast radius): `make web-check` still chained bare `npm audit && npm run check`, so a registry blip stopped svelte-check locally exactly as it had in CI, and CONTRIBUTING documented the bare command as the way to reproduce the gate. New `web-audit` target runs `npm run audit:ci`; `check` runs it after web-check and web-test, mirroring the Web job's order. CONTRIBUTING and docs/architecture.md say so. Refs BUG-2881 * build: web-audit stands alone — no `web` prerequisite, so `check` runs npm ci once and no new target reaches it Codex round 4 on #1247: `web-audit: web` made `check` run `npm ci` twice (`web` is .PHONY) and added a target CLAUDE.md's worktree rule did not list as reaching `npm ci`. `npm audit` reads the lockfile and needs neither node_modules nor a build — verified by running it with node_modules removed — so the prerequisite goes; CLAUDE.md's safe list gains `web-audit`. Refs BUG-2881	2026-09-04 10:45:21 -04:00
xarmian	a15b4951ae	Merge pull request #1245 from PerpetualSoftware/feat/task-2877-inline-create ... feat(web): inline create from the relation picker (TASK-2877)	2026-09-03 23:43:03 -04:00
xarmian	552230bbea	fix(web): a cleared picker owes a refresh even on an unchanged scope (TASK-2877) ... Codex review round 13, and it collapses round 12's fix into a simpler one. `lastScope` means "the scope the rows on screen answer for". The not-ready branch REMOVES those rows, so afterwards they answer for nothing — which is what null says, and the next run therefore owes a refresh whether or not the scope itself moved. Leaving the old value there meant rehydrating on the SAME workspace and collection compared equal, so a server-sourced picker took the early return and sat empty permanently: its rows were cleared and nothing was left to re-query it. Round 12 deferred the COMMIT past the early return to keep a cold-window scope change from being forgotten. With this invalidation in place that deferral changed no outcome — its mutant could not be killed — so it went and the commit moved back to where the value is computed. One rule stated once, rather than two mechanisms aimed at two halves of it. Also hardened the mutation harness, after it bit: a harness timeout kills the runner with SIGTERM, which does not run `finally`, so an earlier killed run left the working tree MUTATED. I then read a pre-existing test "failing" in that tree and had a plausible defect and a fix half-written before checking the file — the failure was M31's mutant, not my change. The runner now restores from its backups on SIGTERM/SIGINT/SIGHUP. Cheap, and the alternative is reasoning about code nobody wrote. Matrix: 35 mutants, all killed; baseline and restore both 97/97.	2026-09-04 02:30:10 +00:00
xarmian	60fe815300	fix(web): a scope refresh stays owed until a run serves it (TASK-2877) ... Codex review round 12, and the tail of round 11's fix. `lastScope` was committed as soon as the effect computed it, before the not-ready branch — which clears the picker and gives up WITHOUT serving the scope. So a scope change arriving while the workspace state is dropped was recorded as handled by the run that handled nothing: at hydration `scopeChanged` read false, a server-sourced picker took the early return, and it sat empty until the user retyped or it remounted. Committed now only by a run that is actually going to serve the scope. Leaving it stale is what keeps the refresh owed. Matrix: 35 mutants, all killed; baseline and restore both 96/96. The new one — committing `lastScope` early again — dies on the added leg.	2026-09-04 01:39:38 +00:00
xarmian	268594e57e	fix(web): a scope change re-queries a server-sourced picker too (TASK-2877) ... Codex review round 11 — the tail of round 10's fix, and mine. The refresh effect now tracks the scope, but it returns early for server-sourced non-empty queries. That early return is right for an index DELTA — the index is not that caller's source of truth, and a request per delta is the rate-limiter pressure the debounce exists to avoid — and wrong for a scope CHANGE, where the rows on screen are answers to a different question and stay selectable under the new scope. A scope change happens when a schema is edited or a pane is retargeted, not per delta, so the rate-limiter argument does not reach it. Two lines that looked like guards went, both measured rather than argued: * `void collection` — the scope pair reads `collection` to build itself, which IS the subscription, so the separate read added nothing and its mutant could not be killed. * the `lastScope !== null` first-run guard — at mount the query box is empty, and the only reader of `scopeChanged` needs a non-empty query, so the first run cannot change an outcome either way. `lastScope` starts null rather than seeded from the props: seeding captured their mount-time values outside a reactive scope, which svelte-check flagged (`state_referenced_locally`) — two warnings this branch introduced and has now removed. svelte-check is back to the six pre-existing warnings in files this branch does not touch. Matrix: 34 mutants, all killed; baseline and restore both 95/95.	2026-09-04 01:08:28 +00:00
xarmian	74d6564c4e	fix(web): the picker's collection scope is a tracked input (TASK-2877) ... Codex review round 10. The refresh effect read `collection` inside `untrack`, so a relation field whose declared target CHANGES under an open picker — a schema edit, or an SSE-driven collection refresh; `ItemDetail` does not remount the picker for either — kept listing rows from the collection it used to point at, still selectable under the new scope. Everything else in that effect is untracked to keep it off the keystroke path, and the scope was swept up in that. But `collection` is not a per-keystroke value: it is the question the results answer. Predates this unit — it arrived with the U3 extraction (TASK-2862) — and is fixed here rather than filed because U8 makes `collection` load-bearing in a new way: it is now the destination an inline create writes to, so a stale scope means rows from one collection listed beside a create row aimed at another. The test drives the change through a NEW single-prop setter on `ItemPickerProbe`, not through `rerender`. That distinction is the whole reason the probe exists, and its own header says so: `rerender` replaces the entire props object and re-runs the effect whether or not it tracks the prop under test, so a rerender-driven version of this test passes against the untracked build. Verified rather than assumed — the mutant that restores `untrack` dies against the setter version. Matrix: 32 mutants, all killed; baseline and restore both 94/94.	2026-09-04 00:10:58 +00:00
xarmian	ded64ce232	docs(web): record why three races are deliberately not fenced (TASK-2877) ... Codex review round 9, two P1s, both declined — and the reasoning goes beside the fences rather than into a commit message, which is the lesson round 7 taught when a round-3 decline was re-raised because a reviewer reading the diff had no way to see it. A CONCURRENT FIELD CHANGE (SSE, another tab) landing mid-POST is ordinary last-write-wins on a field the user is actively editing, and it is what every other type in this component already does — a text field blurred after a remote change overwrites it too. The race is adjudicated at the server: `ItemDetail.updateField` sends `expected_updated_at` and refetch-retries a 409 (BUG-2273 / IDEA-1480). Fencing it here would make relation fields alone behave differently from every other field, on a rule the item's own optimistic-concurrency check already enforces. A LOST RESPONSE on a create that committed is real and is not fixable here. `item create` has no idempotency key and titles are not unique (colliding slugs get `-2` suffixes, `store.uniqueSlug`). Nothing auto-retries — a retry is a person clicking Create again with the picker's state in front of them — and the repo's standing rule for the identical shape is exactly that ("Never retry it automatically" for `item copy`). Filed as IDEA-2880. Deliberately NOT patched client-side: checking for a same-title item before retrying would rest on the same ranked, paged, possibly-stale evidence the create row itself rests on, and would look like a guarantee the client cannot make. No behaviour change; gates re-run rather than assumed — 2104 web tests, svelte-check 0 errors.	2026-09-03 23:42:11 +00:00
xarmian	c516871328	fix(web): read page completeness from the page, not from total (TASK-2877) ... Codex review round 8, one P1, and the mechanism checks out in the server source rather than only in the abstract. Round 7 gated the cold answer on `(res.total ?? rows.length) <= rows.length`. `store.search` makes that unreliable in exactly the case it was guarding: when the count query errors it sets `total = -1`, floors it to 0, and then floors it again to `len(results)` — "Ensure total is never less than actual results", `internal/store/search.go:604-608`. So a broken count is indistinguishable on the wire from an exact-fit page, and the check calls it complete. The `?? rows.length` fallback was the same mistake a second time: unknown read as fine, which is the polarity error rounds 3 and 5 already went around on `coldFailed`. Completeness now comes from the PAGE: a page SHORTER than the limit the server echoes back is proof there is no next page, and that holds whatever the count did. A full page is not proof either way, so it does not count as an answer. No `total` in the decision at all. The U8 fixtures now carry the real response shape. `total`, `limit` and `offset` are non-optional on `SearchResponse` and the Go handler always sends them, so `{ results: [] }` was not a smaller version of a real response — it was one that cannot occur, and it was quietly deciding the very question these tests are about. Matrix: 31 mutants, all killed; baseline and restore both 93/93. M28b — the previous `total`-based implementation — SURVIVED at first, and the fixture was why: it asserted against `total: 84, limit: 2`, which both implementations reject. The leg that discriminates is the floored one (`total: 2` on a full page of 2 with 84 really matching), i.e. the shape the server actually emits when the count fails. A mutant that survives because the fixture never reproduces the real failure is a fixture finding, not a code finding.	2026-09-03 23:31:56 +00:00
xarmian	ff44e917ae	fix(web): count the 401 drop; a truncated page is not an answer (TASK-2877) ... Codex review round 7. Two taken, one answered in the code. P1 — `resetGenerationFor` counted `reset()` and missed the OTHER drop. `bootstrap()`'s unauthorized/forbidden branch clears `state.items`, resets the MiniSearch index and wipes the persisted cache without going through `reset()`, so the fence added in round 6 did not see the revocation case it exists for. Both droppers now call one `markWorkspaceDropped(ws)` helper. Two call sites, because deleting the state entry and clearing rows in place are genuinely different operations; the helper is what makes the pairing greppable, and a test fails if a third site starts clearing rows without it. That test is STRUCTURAL, and deliberately so. Reaching the 401 branch through the front door needs a warm cache plus a pending resync plus a 401 from /items-changes — a fixture larger than the invariant it would check, and I tried it first. The invariant that actually has to hold is "clearing rows and counting the drop travel together". The site-count assertion is what keeps it honest: a NEW clear site fails loudly rather than going silently unexamined, which is how this kind of instrument usually rots. Its own mutant (the 401 branch stops counting) dies. P2 — a TRUNCATED cold page is not an answer to "does this exact title exist"; the row may be on a page nobody fetched. `SearchResponse` carries `total`, so `coldAnswered` now requires a complete page. Same defect as trusting the local ranker's window, arriving from the server side — the third variant of one mistake, which is why the rule is now stated once and asked everywhere: offer only where something authoritative has answered. P2 (query change mid-create) was raised for the second time, having been declined in round 3 with reasons that lived only in a commit message — which a reviewer reading the diff never sees. The reasoning is now a comment beside the fences: the three that exist each stand for an act meaning "not this one" (escaping out, choosing another row, landing on a different item or workspace); typing is mid-thought, the user did ask for the item being created, and cancelling would orphan that row with the field still empty. A decision worth keeping is worth putting where the next reader is looking. Matrix: 29 mutants, all killed; baseline and restore both 93/93.	2026-09-03 22:54:38 +00:00
xarmian	7b32e57cc9	fix(web): a dropped workspace needs an identity signal, not an epoch (TASK-2877) ... Codex review round 6, and it corrects the reasoning round 5 shipped. Round 5 fenced the create on `scopeEpochFor(ws) === epoch` and recorded the residual as needing a coincidence — a purge plus resyncs landing back on the captured number. That was wrong, and wrong in the direction that matters: `reset()` deletes the state and the replacement starts at `scopeEpoch` 0, which is ALSO the value whenever no projection resync has ever run. That is the ordinary case, so the equality check passed trivially across exactly the event it was added to catch. A residual I called exotic was the default path. The fix is the signal the store did not expose: `resetGenerationFor(ws)`, a monotonic per-workspace count of drops, deliberately kept OUTSIDE the `workspaces` map because `reset()` deletes that entry. Both existing counters — `scopeEpoch` and the internal `generation` — live on the state object and restart with its replacement; they are safe only because their readers hold a REFERENCE to the object, which a caller outside the module cannot. It is bumped even when the reset found no state to drop, so a purge racing a first bootstrap does not read as no purge. `createRelationTarget` now asks two questions rather than one: * `indexStillOurs()` — is this the index the request was authorized against? It gates the UPSERT, which was previously unconditional on the argument that a real row belongs in the index. That argument does not survive a purge: a brand-new id was never in `upsert`'s fenced set (nothing to fence — the row did not exist when the purge ran), so the write lands and is persisted to IDB, resurrecting a row into a workspace the user may have just lost access to. This is the gap BUG-2098's own comment describes. * `stillWaiting()` — is the user still waiting on THIS create? It gates the link and the toast, and it is now ONE predicate rather than two hand-copied condition lists. The failure path had drifted from the success path by exactly the reset half (round 6 P2); sharing the predicate is what stops that recurring. Matrix: 27 mutants, all killed; baseline and restore both 91/91. New store surface carries its own suite, including a CONTROL asserting that `scopeEpochFor` genuinely cannot answer this question — if that ever stops holding, the cheaper round-5 fence was sufficient after all and this accessor should go.	2026-09-03 22:36:10 +00:00
xarmian	f7bb735771	fix(web): state the cold rule positively; catch the epoch reset (TASK-2877) ... Codex review round 5, two P1s, both about `localIndex.reset()` — the sign-out / 403-purge / deleted-workspace path. THE FLAG WAS THE WRONG WAY ROUND. `coldFailed` asked "did the last search fail", and that was false in three states that are not answers at all: before the first request, after a failure, and after a reset drops every row while the query sits in the box. Each one read as "fine" and put a create row on screen backed by nothing. Inverted to `coldAnswered` — set in exactly one place, by the event that earns it, and cleared wherever the answer stops describing what is in the box. A flag that must be cleared everywhere is one that will be missed somewhere; this is the same defect arriving twice (round 3 caught the failure case, round 5 the reset case) because the polarity made silence indistinguishable from success. THE EPOCH FENCE HAD TO BE TWO-SIDED. `upsert`'s own guard refuses a captured epoch BELOW the current one, which catches a resync. But `reset()` DELETES the workspace state and the next bootstrap starts a fresh one at `scopeEpoch` 0 — so a captured 7 is not below 0, sails through, and links a row minted under an identity that no longer holds. `createRelationTarget` now requires equality. The residual is in the code comment rather than papered over: a reset plus resyncs landing back on exactly the captured number would compare equal, which an exposed reset generation would catch and this does not. Also dropped the `loading` term from `showCreate`. It and the per-query `coldAnswered` reset were a redundant PAIR — each survived removal while the other stood, which is one guard and one line that looks like a guard, not defence in depth (this repo has a note about exactly that shape). `coldAnswered` is the one kept: it states the rule (something authoritative has answered FOR THIS QUERY) where `loading` is a UI state that correlates with it. Matrix: 24 mutants, all killed; baseline and restore both 85/85. Killing the per-query reset needed `aria-expanded`, not the row's absence — with `loading` still gating the MARKUP, `.picker-create` is missing either way and asserting on it measures the branch instead of the rule. Third time this suite has been fooled by that same separation. Re-verified end to end in a real browser on this exact build: create row offered for a non-matching query and keyboard-reachable; Enter created COLO-6 "Chartreuse" in COLORS (colors 2 -> 3, cars unchanged) with `status: approved` — the schema's declared default, which the "+ New" `options[0]` heuristic would have gotten wrong; the car's field holds that id; a second pass at the same text offers the existing row and no create; Escape leaves the value untouched; no bare UUID anywhere on the page.	2026-09-03 22:14:47 +00:00
xarmian	6a335dd120	fix(web): absence is only evidence from a settled index; fence the error toast (TASK-2877) ... Codex review round 4. Two taken, one declined. P1 — `bootstrapState === 'ready'` was the wrong authority for the create row. It coexists with `pendingResync`: `localIndex` hydrates from the IDB cache and serves those rows while delta-sync catches up, so during that window an item that EXISTS can be missing from the snapshot. The create row is derived from ABSENCE, and a cache snapshot cannot support that inference — presence still can, since the row was real when it was cached. `indexCanProveAbsence()` is asked ONLY by `showCreate`; search and listing keep using `isWarm`, because showing cached rows during a resync is right and it is only the "therefore no such item exists" step the cache cannot bear. The window is seconds and a duplicate outlives it. That leaves one rule across the whole unit, applied in four places now: offer only where something authoritative has answered. Cold is authorized by `/search` (the server answered); a settled index is authorized by the in-RAM collection; a resyncing index and a failed search authorize nothing. P2 — the failure path was unfenced while the success path was not, so a create the user escaped out of, or one belonging to a workspace they have since left, still threw its error over whatever they were looking at. Same three conditions, same reasoning: the difference between reporting and not is whether they are still waiting on it. DECLINED, with reasons, so it is not re-flagged: the "A->B->A gap" in the workspace fence. The classic gap bites when an identifier can be REBOUND to a different object between capture and compare. Here the pair (workspace slug, item slug) is what the fence compares, and the parent subtree is keyed on the item slug, so returning to the same pair returns to the SAME item — applying the create there is correct, not stale. Item refs are sequential and never reused, so the identifier cannot be rebound within a workspace. Matrix: 22 mutants, all killed; baseline and restore both 82/82. Four anchors went stale this round because the fence now appears on two paths and matched twice — the harness refused to score them rather than silently mutating the wrong copy, which is the reason it checks.	2026-09-03 21:45:26 +00:00
xarmian	761e6e2453	fix(web): a failed cold search is not evidence that nothing matched (TASK-2877) ... Codex review round 3 P2. `coldSearch`'s catch leaves exactly the state a successful empty answer leaves — no rows, not loading — and the result list is right to render both as "No results". The create row is not: an empty answer is evidence that no such item exists; a failed one is no evidence at all, and offering to create on no evidence is how a duplicate gets minted while the index is cold and the network is unhappy. Same rule the permission gate already follows — no answer must not read as permission. A `coldFailed` flag now separates the two, and where it is CLEARED was settled by the matrix rather than by symmetry. Three reset sites looked obviously needed and three mutants removing them survived: * the cold branch of `runQuery` — `loading` is true for that entire window and already suppresses the row, and both `coldSearch` branches assign the flag outright when the request settles; * the empty-query branch — covered twice over, since an empty query offers no create row at all; * the workspace-reset effect — same as the first. All three are gone rather than carrying a comment claiming a protection they do not provide, which is the disposition this plan's own U3 note records for an unkillable guard. The ONE reachable reset is the warm branch: it is the only path that produces a fresh verdict without going through `coldSearch`, so without it a single network blip suppresses the affordance for the rest of the session even once the authoritative in-RAM answer is available. That one has a test, and its mutant dies. Round 3 also raised a P1 I am NOT taking: typing a new query while a create is in flight does not cancel it. The three fences that exist — escape, picking another row, retargeting — each stand for an act that means "not this one". Typing is not such an act; it is mid-thought, and the user did explicitly ask for the item that is being created. Treating it as a cancel would leave the created row orphaned and the field unset, which is a worse outcome than a field that ends up holding exactly what was asked for. Told to Codex in the next round rather than left to be re-flagged. Matrix: 20 mutants, all killed; baseline and restore both 80/80.	2026-09-03 21:45:26 +00:00
xarmian	5dffd734c1	fix(web): fence the create against cancel and against a workspace switch (TASK-2877) ... Codex review round 2, two P1s, both confirmed at the lines they name. CANCEL. `oncancel` only closed the picker, so backing out did not supersede an in-flight create — the pending promise then resolved and selected an item the user had just declined. Backing out is as explicit a choice as picking a different row, and now bumps the same counter. WORKSPACE SWITCH. `ItemDetail` keys its fields subtree on `itemSlug` ALONE, so switching workspaces to an item carrying the SAME ref — and every workspace has a TASK-5 — reuses this component rather than remounting it, and `destroyed` never fires. The completion then wrote an item ID from the previous workspace into the new workspace's item. `createRelationTarget` already captured `ws` and `collSlug` before the request; it now compares them to the live props before applying, which is the DR-6b shape `ChildItems.submitCreate` uses for the same reason. The `localIndex.upsert` still runs ahead of all three fences and still uses the CAPTURED workspace: the item genuinely exists in the workspace it was created in, and the fences are about where the VALUE is written, not about hiding a real row. Matrix now 17 mutants, all killed; baseline and restore both 78/78. The two added here — cancel not bumping the counter, and the ws/collection comparison removed — are what stand in for having seen these two tests red before the fix, since pin and fix landed in one edit.	2026-09-03 21:45:26 +00:00
xarmian	83e4abc966	fix(web): fence the in-flight create; ask the index, not the ranking (TASK-2877) ... Codex review round 1, three findings, all confirmed by reading the code they name rather than taken on the report. P1 — the create completion had no fence, and there are two ways past it. `ItemDetail` wraps its fields section in `{#key itemSlug}`, so an item switch DESTROYS this component; the promise survives, and `onchange` calls into the persistent parent, whose `updateField` builds its PATCH against whatever item is current at CALL time. A create started on car A therefore wrote its colour onto car B. Separately the picker stays open across the round trip, so the user can settle on another row (or clear the field) before it lands — and last-write-wins is the wrong rule there, because the later write is an explicit choice and the earlier one is a promise they have moved past. A `destroyed` flag and a supersede counter, checked together, close both. The `localIndex.upsert` deliberately runs BEFORE the fences: the row exists on the server whatever happened locally, and withholding it would leave a picker offering to create it a second time. P2 — `targetCollection` read the global collection list with no freshness gate, so during a workspace switch a slug match against the PREVIOUS workspace's rows yielded a foreign collection ID, and `canEditCollection` answered about that. Same gate `knownCollectionSlugs` already had, which this derivation was missing. P2 — the exact-title suppression was asking the RANKING. `warmSearch` requests `limit + excluded.size` hits, so an exact row the ranker placed outside that window is simply absent from `rawResults` and the picker offers a duplicate. The question has an authoritative answer in `localIndex`, already in RAM, so the warm path now scans the collection directly. The `rawResults` check stays and is NOT redundant: while the index is cold there is nothing to scan, and the server's rows are the only evidence the row exists — pinned by its own leg, which is what killed the mutant that removed it. Mutation matrix now 15 mutants, all killed; baseline and restore both 76/76. Two rounds of it earned their keep beyond the fixes: M3 SURVIVED once the index scan landed, and the mutant was faithful — the suite had no cold-path exact-match leg, so the surviving mutant found a real hole in my tests rather than a redundant line in the code.	2026-09-03 21:45:26 +00:00
xarmian	e331342450	feat(web): relation fields create their target inline, permission-gated (TASK-2877) ... PLAN-2857 U8, caller half. `FieldEditor` hands the picker an `oncreate` only when the viewer may create in the field's DECLARED TARGET, so it decides both of the unit's gates by deciding whether to pass one. The gate is `canEditCollection` on the target collection — the same predicate behind the collection page's "+ New" — asked about where the item would LAND, not about where the user is standing. It needs the collection's ID, which only the loaded collection list carries; a target the list does not know yields no create row, because "no answer" must not read as "allowed". NO FIELD VALUES ARE SENT, and that is a decision with a receipt. The server fills every missing key that declares a `Default` and stores the defaulted map (`items.ValidateFields`, then "Marshal validated/defaulted fields back" in `createItemChecked`), so the schema's own answer is already the right one. The collection page's "+ New" guesses `status.options[0]` instead; driven live against a Colors collection whose status options are [draft, approved] with `default: approved`, the created row came back `{"status":"approved"}` — the declared default, which that heuristic would have gotten wrong. The cost is that a target carrying a REQUIRED field with no default refuses the create; that surfaces as a toast naming the field, which is the honest outcome for a row this picker cannot fill in. The new item is upserted into `localIndex` under the epoch captured BEFORE the request (BUG-2098 — a projection resync landing mid-flight means the response was authorized under a scope that no longer applies). That upsert is what makes the picker's exact-title suppression true on the very next keystroke; without it the same text offers to create a second item. Mutation matrix, all killed: creating in a collection other than the declared target, the permission gate removed, the upsert removed, and the epoch read after the request rather than before.	2026-09-03 21:45:26 +00:00
xarmian	322b461606	feat(web): the scoped picker offers an inline create row (TASK-2877) ... PLAN-2857 U8, picker half. When a scoped picker's query matches nothing — or nothing EXACTLY — it offers a trailing "Create "<query>" in <collection>" row, keyboard-reachable like any other row. The affordance is opt-in at the call site: it appears only when the host passes `oncreate`, which is how both of U8's scope rules are expressed without this component knowing either. "Relation fields only" is the Relationships tab passing nothing; the permission gate is the caller's, because "may this user create in the target collection" is the collection-level `canEditCollection` cascade that lives in the workspace store. Result rows and the create row become ONE `options` list, in render and keyboard order, so arrowing onto the create row needs no special case and cannot fall out of step with what is on screen. `activeId` already addressed rows by identity; the create row takes a NUL-prefixed sentinel id in the same namespace, which no UUID can collide with. Two suppressions carry weight and both are pinned: * EXACT-TITLE. Tested against `rawResults` — the source's answer before exclusion and the row bound — because an exact match pushed past `limit` or excluded by the caller would otherwise read as "no such item" and offer to mint a duplicate of a row that exists. This IS the no-duplicate half of the unit's proving test: there is no create-time uniqueness check anywhere, because the second pass at the same text never reaches a create. * LOADING. Mid-flight, "nothing matched" is not yet known. The one assertion that can fail here is `aria-expanded`, not the row's absence: the markup renders the loading branch INSTEAD of the listbox, so a build that offered the row mid-flight would still show no `.picker-create` and merely leak a combobox announcing itself expanded over no listbox. That is trap #1 from this plan's false-green note, met in my own diff. Re-entrant creates are dropped while one is in flight, so two Enters inside a single round trip cannot mint two items — a duplicate the exact-title check cannot catch, since no row exists yet to match. Mutation matrix, all killed: exact-title suppression removed (3 tests), re-entrancy guard removed, `loading` term removed, `collection` term removed, Enter dispatching over `results` (the pre-U8 line), create row prepended rather than trailing.	2026-09-03 21:45:26 +00:00
xarmian	e94e9afbea	Merge pull request #1240 from PerpetualSoftware/fix/bug-2850-field-coercion ... fix(server,mcp,cli): type field values server-side; carry the fields object natively (BUG-2850)	2026-09-03 17:21:57 -04:00
xarmian	56c46ae0ea	fix(store): propagate a collection rename into relation fields that target it (BUG-2873) (#1243) ... fix(store): migrate relation fields when their target collection is renamed (BUG-2873)	2026-09-03 16:51:42 -04:00
xarmian	80be76a3ce	docs(mcp): the detectFieldConflicts header stated the pre-round-14 reach (BUG-2850) ... Comment-only. The lead caught it in the package review. The "SCOPE:" paragraph still said the pass runs only when a `fields` object is present, and that a top-level-vs-`field:[]` collision without one is outside it. Round 14 falsified both halves — the pass runs from both action entry points on every call — and the body's own comment said so while the header contradicted it. On the one boundary this loop spent eighteen rounds on, the header is what a future reader trusts. CONVE-23 is exactly this and I missed it: the round-14 commit swept the version.go prose and the test comments, and left the header of the function it had just changed. The paragraph now states the actual reach: both entry points regardless of `fields`; alias collisions adjudicated always and refused even on equal values; same-name collisions adjudicated only when the `fields` object carries THAT key, which is a per-key question; the round-7 exemption as the sole carve-out, itself narrowed to keys the CLI can express (the compat IDs refuse, but only when a top-level compat value is present), with padded entries outside it. It closes with the instruction the loop earned: say a new condition's QUANTIFIER out loud before writing it. Rounds 15, 16, 17, 19, 20 and 21 were each that question answered by assumption. gofmt clean · go vet clean · go test ./internal/mcp/ ./cmd/pad/ green	2026-09-03 20:44:01 +00:00
xarmian	9ecc59af1e	fix(store): refuse a schema with trailing content instead of truncating it (BUG-2873) ... Codex round 3, one P2. `json.Decoder.Decode` stops at the end of the FIRST value and ignores whatever follows, where `json.Unmarshal` refuses it — so a stored schema with junk after the object would be silently truncated by the rewrite. It is now treated as unparseable and left alone, the same posture as any other schema this migration cannot faithfully reproduce. **The Postgres gate then failed the new test, and the failure is the finding.** It failed at the SEED, not the assertion: `ERROR: invalid input syntax for type json (SQLSTATE 22P02)`. `collections.schema` is TEXT on SQLite (`005_collections.sql:10`) and JSONB on Postgres (`pgmigrations/001_initial.sql:114`), so a value with trailing content cannot be STORED on Postgres at all. The state this guard defends against is reachable on one dialect and forbidden by the column type on the other. So the test skips on Postgres with that reason recorded. Asserting there would be asserting about a state that cannot exist — and reading WHICH LINE failed is what separated "my test is not portable" from "the product is broken on PG". **Second instance of the mutation harness reporting a false survivor**, same cause as the last: deleting the guard leaves `io` unused, the mutant fails to compile, and counting `--- FAIL` lines sees zero. With `_ = err` in place of the return it dies immediately. Twice in one unit makes it a harness defect, not bad luck: a runner that counts test failures must check the BUILD separately, or every non-compiling mutant reads as a hole in the tests. Mutation matrix 7 of 7 killed. Gates: `gofmt` clean, `go vet ./...` ok, full `go test ./...` green on SQLite, full `internal/store` green on Postgres (502.2s, private container at 127.0.0.1:5473, detached with a sentinel).	2026-09-03 20:08:53 +00:00
xarmian	a1b8e63a29	fix(mcp): a nil top-level value is absence, for every key (BUG-2850) ... Codex round 21, one P2 and no P1 — a false refusal, and the finding named a strict subset of it. topLevelValueProvided returned true unconditionally for the compat IDs, and fell through to true for everything else, so a nil counted as a supplied value and refused against a `fields` entry for the same key. Nothing writes a nil: the HTTP mapper's `.(string)` assertion drops it and BuildCLIArgs has no flag value to emit, so both doors resolve to the `fields` value. The finding named `assigned_user_id` / `agent_role_id`. Probing the population first — the habit this unit has been beating into me — showed all five top-level keys behaving identically, because the non-compat path fell through to `return true` as well. Fixing the named pair alone would have left `status: null` refusing. Mutation matrix, three directions: remove the nil check -> all five key legs fail fix ONLY the named compat pair -> status / priority / parent fail treat the empty compat clear as absence too -> both clear-semantics tests fail The middle mutant is the population-versus-instance distinction made executable: a fix that satisfies the reviewer's example and nothing else is red, by name, in three legs. Gates: gofmt clean · go vet clean · go test ./... green (29 packages) · contract-drift gate green	2026-09-03 19:59:16 +00:00
xarmian	499387e99d	fix(store): never regress a migrated token; keep large integers intact (BUG-2873) ... Codex round 2: four findings, two fixed here and two filed as their own items. **Migrated siblings' OCC tokens could REGRESS.** A sibling updated between this rename's timestamp and the scan already holds a newer `updated_at`; stamping the rename's value on it moved the token BACKWARDS — breaking the strictly-increasing invariant the transaction above exists to maintain, and re-validating a token the client should have lost. Each rewritten row now takes `max(current + 1ns, renameToken)`, computed in Go from the value read under the row lock rather than by comparing timestamp TEXT, which the existing comment warns is never safe. **Large integers in unknown properties were corrupted.** Round 1 fixed the typed round-trip dropping unknown keys, but decoding into `interface{}` turns every JSON number into float64, so `9007199254740993` came back CHANGED. A rename would silently damage a property it exists only to carry through. `UseNumber` keeps the literal text. ## Filed, not absorbed — both because their dependents are not the relation feature - **BUG-2875** — a collection CREATED during a rename escapes the scan's `FOR UPDATE` and keeps a relation aimed at the old slug. Closing it means `CreateCollection` takes the workspace lock, which changes the concurrency behaviour of every collection creation on the instance. Same reasoning that split IDEA-2874 out; this unit's reviewability rests on affecting zero live rows. - **IDEA-2876** — migrated siblings emit no `collection_updated` event, so an open page keeps the pre-rename schema until reload. Handler/event layer; the store publishes nothing. ## The mutation harness was reporting a false survivor Counting `--- FAIL` lines treats a mutant that FAILS TO COMPILE as one that survived — zero failures either way. Removing the token guard leaves `rowUpdatedAt` and `renameToken` unused, so that is exactly what happened, and it read as "the guard is untested". With a compiling mutant (`_ = rowUpdatedAt`) it dies immediately. Worth stating because the failure mode is silent and points the wrong way: it invents doubt about code that is fine, and would equally hide a real survivor behind an unrelated build break. Mutation matrix 6 of 6 killed. Gates: `gofmt` clean, `go vet ./...` ok, full `go test ./...` green on SQLite, full `internal/store` green on Postgres — 460.9s, private container at 127.0.0.1:5473, run detached with a sentinel.	2026-09-03 19:43:36 +00:00
xarmian	a9f2405903	fix(mcp): the compat exception turns on a top-level value, not on the key (BUG-2850) ... Codex round 20, one P2 and no P1 — another false refusal from a reason of mine applied past the source it was verified on. Round 15's reason was specific: a TOP-LEVEL compat param has no CLI flag, so BuildCLIArgs drops it while HTTP reads it, and the doors receive different writes. I then keyed the exception on the KEY being a compat one, which caught `field:["assigned_user_id=A", "assigned_user_id=B"]` — two array entries, no top-level value, no asymmetry: both doors keep the last and lift the same column. Refused a call that resolves deterministically. The gate now asks whether a top-level compat value is actually present, which is the condition the reason describes. Mutation matrix, both directions: broaden it back to any compat-keyed contribution -> only the two-entry legs fail drop the exception entirely -> only the top-level legs fail (round 15's defect returns) Round 15's own case is a leg of the new test deliberately: without it this pin would pass on a build that dropped the compat exception altogether, which is the defect round 15 existed to fix. Gates: gofmt clean · go vet clean · go test ./... green (29 packages) · contract-drift gate green	2026-09-03 19:27:32 +00:00
xarmian	6428e7db31	fix(store): lock, stamp and preserve on the relation retarget (BUG-2873) ... Codex round 1: four findings, three P1, all real. **The migrated siblings' concurrency token was not advanced.** `collections.updated_at` doubles as the OCC token (BUG-2265), so rewriting a sibling's schema without touching it left a client holding the PRE-rename schema — and a token that still matched — able to write it straight back and undo the migration. Every rewritten row now takes the rename's own token, so the whole rename shares one instant. Pinned by asserting the stale token now 409s. **The scan did not lock the rows it rewrites.** A concurrent schema update to a sibling could commit between the SELECT and the UPDATE, and this transaction would then overwrite the newer schema with its stale copy. `FOR UPDATE` on Postgres, ordered by id so the multi-row acquisition is deterministic; SQLite is covered by its BEGIN IMMEDIATE write lock. **The old slug came from the pre-transaction snapshot.** Two tokenless concurrent renames of the same collection both read the ORIGINAL slug outside the lock; the loser would migrate `original -> its own new slug` while the relations already said the WINNER's, matching nothing and stranding them at a name no collection holds. The slug is now re-read alongside the token under the row lock. This is the READ — the ALLOCATION of the new slug is still outside the transaction and still IDEA-2874's, deliberately. **Re-marshaling through `models.CollectionSchema` dropped unknown properties.** That struct has fixed fields, so unmarshal+marshal silently erased anything it does not declare — a rename would quietly strip forward-compatible metadata from every relation-bearing schema in the workspace. It now edits the raw decoded JSON, touching only `fields[i].collection`. ## Two instruments that were not instruments Both found by mutation, not by reading: - **The deadlock test passed against its own mutant in 0.44s.** Two unsynchronised goroutines never collided. With a start barrier and 40 rounds it now fails in 1.4s with `ERROR: deadlock detected (SQLSTATE 40P01)` — so Rook's hazard was reproducible, not theoretical. - **The pre-tx-slug mutant survived the first matrix**, because nothing forced the interleaving. Rather than call it untestable, it is pinned by an end-state invariant that holds under ANY interleaving — whatever slug the collection ends up with, every relation aimed at it points there — over 40 concurrent rounds. It fails at round 1 under the mutant. Mutation matrix 4 of 4 killed. Gates: `gofmt` clean, `go vet ./...` ok, full `go test ./...` green on SQLite, and the full `internal/store` suite green on **Postgres** — 448.6s on a private container at 127.0.0.1:5473, never the shared 5445 a sibling seat may tear down. Run detached with a sentinel after the first attempt was killed at a turn boundary; the harness kills backgrounded tasks, it does not kill disowned ones.	2026-09-03 19:22:36 +00:00
xarmian	052850f613	fix(mcp): both gates ask the per-key question; compare like with like (BUG-2850) ... Codex round 19, two P2 and no P1. Both were FALSE REFUSALS my own fixes introduced — the first is round 17's mistake in the sibling gate. [P2] THE SAME-NAME GATE WAS STILL PER-REQUEST. Round 17 made the padded gate per-key and left this one asking whether the request has any `fields` object. With `fields:{"other":"x"}` and `field:["effort=l","effort=s"]`, `effort` is not in the object, nothing arbitrates it but the doors themselves, and both keep the last entry — so a call that resolves deterministically was refused. The predicate is now `canonicalized`, the same per-key question the other gate asks. `fieldsPresent` no longer exists anywhere in the pass, and its absence is commented as the fix's shape: a future gate reaching for "does the request have a fields object" is almost certainly this mistake a third time. [P2] TRIMMED AND UNTRIMMED VALUES WERE COMPARED. Entry values are trimmed for comparison because ingestFieldKVP trims them; the `fields` object's value was compared raw. `fields:{"note":" x "}` with `field:["note= x "]` read as " x " vs "x" and refused, though both doors write " x ". Only the COMPARISON key is trimmed now — `raw` and the re-emitted wire value keep the caller's whitespace. Mutation matrix: same-name gate back to per-request -> only the unrelated-key leg fails stop trimming for comparison -> only the whitespace-equal leg fails trim the EMITTED value too -> only the re-emission leg fails THE THIRD MUTANT SURVIVED AT FIRST, and it was unreachable rather than unobserved: the whitespace test's entry is already canonical, so the re-emission path never ran and a mutant trimming the emitted value changed nothing it could see. Added a leg whose KEY is padded, which forces the re-emission, and asserted the emitted value still carries the caller's whitespace. Third time this loop that asking "is the mutant faithful" before "is the test weak" found a real hole (CONVE-28). Control legs, both directions: a `fields` object that DOES carry the key still refuses differing values, and genuinely different values are still refused however they are padded. Gates: gofmt clean · go vet clean · go test ./... green (29 packages) · contract-drift gate green	2026-09-03 19:17:31 +00:00
xarmian	4687c46f94	fix(store): migrate relation fields when their target collection is renamed (BUG-2873) ... `models.FieldDef.Collection` holds the target's SLUG, and it is the ONLY pointer a relation field carries — there is no id beside it to fall back on. `UpdateCollection` re-slugifies on rename and nothing migrated the definitions aimed at the renamed collection, so every relation field pointing at it was stranded: the picker filters on a slug that resolves to nothing and the field silently stops being fillable. `retargetRelationFieldsTx` re-points them in the SAME transaction as the rename, for the reason the field-value migrations already run there: a failure must roll the rename back rather than commit collections pointing at a slug that no longer exists. **It parses instead of string-replacing.** A schema's JSON contains the old slug in places that must not move — a text field's `default`, a select's `options`, a label. Only `FieldDef.Collection` on a `relation` field is a reference. Export's `remapFieldIDs` gets away with a blind replace because it substitutes UUIDs, which cannot collide with prose; a slug is a word. A control test pins that. **The renamed collection is included deliberately** — a relation targeting ITSELF needs the same rewrite — and the rewrite lands after the caller's own `schema` write in the transaction, so a simultaneous schema edit composes rather than being reverted. Both have tests. ## The deadlock hazard, and why the existing comment does not cover it The lock-order comment above this transaction is a Codex P1 fix that orders the workspace lock against ONE collection row lock, because until now nothing took more than one. This change writes SIBLING collection rows, so two concurrent renames of mutually-referencing collections take those locks in opposite orders. **Reproduced, not theorised:** with the serialization removed, the test fails in 1.4s with `ERROR: deadlock detected (SQLSTATE 40P01)` on Postgres. Renames now take the workspace lock — previously acquired only when `len(input.Migrations) > 0` — BEFORE the row lock, which closes it without inventing a second ordering rule to keep in sync with the first. **The first version of that test was not an instrument.** Two unsynchronised goroutines passed against the same mutant in 0.44s, having simply never collided. It takes a start barrier and 40 rounds to be evidence. ## Scope The out-of-tx slug allocation (`uniqueSlugExcluding(s.db, …)` at :420, before `s.db.Begin()` at :503) is deliberately NOT touched — filed as IDEA-2874. Its dependents are every collection rename in every workspace, not the relation feature, so it does not belong in a change whose reviewability rests on affecting zero live rows. `UNIQUE(workspace_id, slug)` makes today's behaviour loud rather than lossy, so it can wait. A census found ZERO relation fields across all 11 accessible workspaces on this instance, and no shipped template declares one — this repairs the rename path before PLAN-2857 creates the population, which is why a migration is not needed. Gates: `gofmt` clean, `go vet ./...` ok, `go build ./...` ok, full `go test ./...` green on SQLite, and the full `internal/store` suite green on **Postgres** (private container on 127.0.0.1:5473, never the shared 5445 a sibling seat may tear down). Pin written and run BEFORE the fix per team CONVE-29: 2 propagation tests failed, the control passed.	2026-09-03 18:56:38 +00:00
xarmian	21a3057389	fix(mcp): keep per-entry multiplicity in the conflict pass (BUG-2850) ... Codex round 18, one P2 and no P1 — and the fix is upstream of the rules rather than another rule. parseFieldArray indexes by NORMALIZED key, so two entries naming one key collapsed into a single index slot, and this pass walked that index. Its own input was lossy: `field:["effort=l", " effort=l"]` arrived as ONE contribution, fell under the len < 2 early exit, and passed unchecked — HTTP trims both to `effort` while stdio writes `effort` AND a junk `" effort"`. The pass claims to adjudicate one canonical key offered by multiple sources; two array entries ARE multiple sources, and it could not see them. It now walks the raw entries, so multiplicity survives and the existing rules apply unchanged — no new branch. The index is deliberately discarded here and the discard is commented, because reaching for it is the natural thing to do next. I NEARLY CHANGED THE CODE TO SATISFY A WRONG TEST. The third leg was first written asserting that two canonical entries with DIFFERING values are refused. The code disagreed, and the code was right: ingestFieldKVP (HTTP) and the --field loop in cmd_item.go (CLI) both do `map[key] = val` in entry order, so each door keeps the LAST entry and they agree. That is the round-7 boundary exactly — a visible duplicate with a resolution the caller can predict — and refusing it would have contradicted the boundary the lead confirmed, on two doors pinned to agree. Verified by reading both loops before touching anything. The leg is kept, inverted, because it is the one that stops a future "refuse every repeated key" simplification from looking correct. Mutation: restoring the collapse (walk one contribution per key) fails exactly the padded-twin leg, and leaves the two control legs green. Gates: gofmt clean · go vet clean · go test ./... green (29 packages) · contract-drift gate green (go test ./internal/mcp/ -run 'CoversEveryCatalogAction|VersionMatchesToolSurface')	2026-09-03 18:55:15 +00:00
xarmian	130c854052	fix(mcp): canonicalization is a per-KEY property, not a per-request one (BUG-2850) ... Codex round 17, one P1, and it is the third consecutive round where my own fix generalized a property verified on one subset to the whole. Round 16 gated the padded-entry refusal on "no `fields` object", reasoning that a `fields` object makes reshapeItemFields re-emit the entry canonically. That holds for keys IN that object. With `fields:{}`, or a `fields` carrying some OTHER key, nothing canonicalizes `field:["status = done"]` and it reaches the doors padded exactly as it does with no `fields` at all — HTTP writes `status`, the CLI writes a junk `"status "` beside it. The predicate is now the actual question: will anything canonicalize THIS key. The pattern is worth naming because it is now a habit rather than an accident: round 15 — a premise true of schema-declared params, applied to the compat IDs, which are undeclared precisely so it cannot hold round 16 — the check placed below the exemption, so it covered one key class (caught by my own test's control leg) round 17 — a per-key property read as per-request Each time the fix was correct for the case in front of me and wrong for its siblings, which is the same shape as the defects this unit started with. The canonical restructure removed it from the CODE; it evidently did not remove it from how I reason about the code. Mutation matrix, both directions: revert to the per-request gate -> only the two uncovered-key legs fail refuse even when canonicalized -> only the canonicalized control fails The third leg of the new test is the control that makes the distinction real: with the key present in `fields` the entry IS canonicalized, so the call must still succeed. A fix that refused whenever anything was padded passes the first two legs and fails this one. Gates: gofmt clean · go vet clean · go test ./... green (29 packages) · the contract-drift gate ran green (go test ./internal/mcp/ -run 'CoversEveryCatalogAction|VersionMatchesToolSurface')	2026-09-03 18:41:00 +00:00
xarmian	e64a1eb76b	Merge pull request #1242 from PerpetualSoftware/feat/task-2868-relation-field ... feat(web): relation fields — linked chip + picker (TASK-2868)	2026-09-03 14:32:49 -04:00
xarmian	3696686377	fix(mcp): a padded entry colliding with a param is not an equal duplicate (BUG-2850) ... Codex round 16, one P1, and its placement is the whole lesson. The conflict index is normalized — that is what lets a padded entry be recognized as a collision at all — so `field:["k = A"]` compared EQUAL to a top-level `k:"A"` and the pair was accepted while the entry stayed padded on the wire. HTTP trims it and writes `k`; the CLI does not, and writes a junk `"k "` key instead. The normalization that makes the collision VISIBLE is exactly what made accepting it wrong: equality on the normalized form licensed a collapse of the RAW forms, which are not equal at all. So equality only licenses a collapse when both doors receive the same write, and this check now runs BEFORE the same-name exemption. MY FIRST DRAFT PUT IT AFTER, which is round 15's mistake repeated one round later. Round 15 was a premise verified for declared params and generalized to two keys it did not hold for; placing this below the exemption meant only the compat IDs were checked, when padding breaks the exemption's own premise — both doors resolve the duplicate identically — for EVERY key class. The declared-param leg of the new test caught it, and the mutation matrix pins the placement rather than just the behaviour. Scope held: a padded entry standing ALONE, with no colliding param, is untouched. That is BUG-2870, ruled out of this PR, and fixing it changes what every CLI caller receives rather than only callers who supplied one key twice. There is an executable test for that boundary, so growing into BUG-2870's territory without a ruling goes red. Mutation matrix, three directions: remove the check -> both padded legs fail restrict it to compat IDs -> only the declared-param leg fails (the first draft) extend it to a lone entry -> the BUG-2870 scope-boundary test fails gofmt clean · go vet clean · go test ./... green (29 packages) context: 56.4% (session-shape)	2026-09-03 18:26:10 +00:00
xarmian	dae7bbf233	fix(mcp): the same-name exemption holds only where the doors agree (BUG-2850) ... Codex round 15, one P1, and it lands on the boundary I defended at round 7 and the lead confirmed. The exemption's premise is "both doors resolve a same-name duplicate identically". That is TRUE for a schema-declared param: the CLI has a real flag, so stdio receives BOTH forms (`--status open --field status=done`) and its overlay order resolves them exactly as the HTTP mapper does. I verified that per door and pinned it. It is FALSE for the v0.16 compat IDs, and being undeclared is precisely why. BuildCLIArgs emits the CLI's real flags; there is none behind `assigned_user_id`, so the top-level value is DROPPED and stdio sees only the field entry while HTTP reads the param. `assigned_user_id:"A"` with `field:["assigned_user_id=B"]` assigns two different people depending on transport — with no `fields` object anywhere, which is why the canonical pass's `fields`-gated half never saw it. So I generalised a premise from the params I had verified to the two whose whole nature is being unverifiable that way. The exemption is now narrowed to keys the CLI can express; the compat pair refuses. Swept for the prose this falsifies (CONVE-23): the v0.27 changelog entry said the no-`fields` same-name case is "NOT refused, deliberately", full stop. It now states the narrower rule and why the compat IDs are outside it — the entry is the artifact a consumer reads to decide what this version does, and leaving it broader than the code would have been worse than never writing it. Mutation matrix, both directions: restore the blanket exemption -> only the two compat legs fail remove the exemption entirely -> only the declared-param control fails The over-narrow mutant did NOT compile on the first attempt (`declared and not used: fieldsPresent`), which proves nothing about the tests, so it was rewritten to compile before being counted. A compiler-killed mutant is a failed experiment, not a passing one. The declared-param control is in the same test deliberately: without it this pin would pass on a build that abandoned the round-7 boundary outright, which is the opposite defect and just as wrong. gofmt clean · go vet clean · go test ./... green (29 packages)	2026-09-03 18:08:06 +00:00
xarmian	4b6e321924	feat(mcp): bump ToolSurfaceVersion to 0.27 (BUG-2850) ... The contract this branch changes is advertised in the handshake under capabilities.experimental.padToolSurface, and agents branch on it. It still said 0.26. Caught by reading the artifact a CONSUMER reads rather than the code — and the repo already had the instrument: tool_surface_drift_test.go fails when instructions.md or README.md drift from the constant, so the bump immediately named both documents. They are updated with what actually changed, not just re-titled. Bump grounds are v0.26's own, and v0.25's, v0.16's, v0.10's and v0.9's: no tool name, action enum or parameter shape changed, and the behaviour did. This branch REFUSES calls 0.26 accepted: - two names for one target in a single call (parent/plan, assign/assigned_user_id, role/agent_role_id), refused even when the values match, because the names address one thing through incomparable vocabularies and the doors resolved them differently; - the same key through the `fields` object and another source with differing values (equal ones collapse); - a non-string `assign`/`role`, which one door dropped silently and the other rejected; - an empty hierarchy value inside `fields`, which promoted onto a param both doors read as "not supplied" and so reported success having detached nothing. Every one of those replaced a call that SUCCEEDED while doing something other than what it said, so the break is the fix in each case. The additive halves are in the same entry because they are one contract change: server-side coercion (a declared number/json field was unwritable from the remote transport at all), the `fields` object carrying native types, and `warnings.undeclared_fields` on write responses. Deliberately NOT refused, and stated in the entry so it reads as a decision: a top-level param colliding with a `field:[]` entry under the same name with no `fields` object. Both doors resolve that identically and it is visibly a duplicate. gofmt clean · go vet clean · go test ./... green (29 packages)	2026-09-03 17:59:40 +00:00
xarmian	bb62cfdc95	test(mcp): derive the conflict property's population from the declared schema (BUG-2850) ... The lead's finding after round 14, and it is a sharper statement of what went wrong than mine was. The property test enumerated its sources by hand, and that hand-written list came from the same head as detectFieldConflicts. A property whose input list mirrors the implementation cannot see a source the implementation forgot — which is exactly how the round-14 defect survived it: the property SKIPPED param-vs-array pairs as "out of scope", which was the implementation's assumption restated as a test assumption. So the population now comes from the DOOR'S DECLARED CONTRACT — the live pad_item ToolDef's parameter list, which is what agents read — and every declared param must be either classified by the conflict machinery or explicitly excluded with a reason. The two lists have genuinely different origins (the tool schema vs the four key sets), which is the whole point: a test that derives its expectations from the thing it checks cannot fail. It earned its place immediately by naming ten declared params I had not classified. Each is now excluded WITH its reason, because a bare list would let a future field-writing param be silenced by adding one word to it — the round-14 mistake in miniature. The interesting group is summary/details/decision/rationale. Those DO change item state, so excluding them is a real claim rather than a shrug: they write implementation_notes / decision_log through their own actions, and those exact keys are REFUSED through `field` and `fields` (BUG-2627 / BUG-2675), so they cannot reach one key by two routes — which is the only thing this pass adjudicates. The reverse direction is checked too: every key the machinery classifies must be reachable through the declared schema, or be a documented undeclared form (the v0.16 compat IDs, and `plan`, a fields_patch pseudo-key with no top-level param). That fails if a key set goes stale against the schema. gofmt clean · go test ./internal/mcp/ green	2026-09-03 17:55:51 +00:00
xarmian	eb37c0e53c	fix(mcp): give the canonical pass full reach; equal structures collapse (BUG-2850) ... Codex round 14, two P1 — both in the round-13 restructure, and the first is the restructure repeating the mistake it was built to end. [P1] THE CANONICAL PASS DID NOT REACH THE NO-`fields` CASE. It ran from inside reshapeItemFields, which returns early without a `fields` object, so an ALIAS pair arriving through the top level and the `field` array alone slipped past: `assigned_user_id:"B"` with `field:["assign=dave"]` applies the compat ID over HTTP while stdio drops it and sends only the generic field. Two different people assigned, from one call. The tell is that round 7 had ALREADY built an always-run alias guard — for the hierarchy pair only. So the restructure meant to end guard accretion had itself left two alias mechanisms with different reach, and the pair the older one covered is exactly the pair that kept working. detectFieldConflicts now parses its own inputs and runs from both action entry points regardless of `fields`; checkHierarchyAliasAmbiguity is deleted as subsumed. One mechanism. The alias half is ungated; the SAME-NAME half stays gated on `fields`, which is the round-7 boundary the lead confirmed and is unchanged. Last-write-wins is defensible when both sources name one key and indefensible when two names address one target through different vocabularies — a slug and a UUID cannot be compared, so co-occurrence is ambiguous however it arrives. [P1] EQUAL STRUCTURES WERE REFUSED. `tags:["a"]` plus `fields:{"tags":["a"]}` is one unambiguous value, and scalarEqual had always collapsed it; the round-13 pass refused whenever either side was structured. A regression I introduced, that nothing in the suite caught because every existing tags test passes a structure on one side only. Equal structures now collapse, differing ones still refuse. The property test is widened rather than merely extended: it previously SKIPPED param-vs-array pairs as out of scope, and that exclusion is precisely where the round-14 defect lived. It now covers every source pair — 72 combinations, up from 48. Mutation matrix: re-gate the alias half on `fields` -> property fails on the param×array legs revert equal-structure collapse -> only EqualStructuredDuplicateCollapses fails make the collapse unconditional -> only DifferingStructuredDuplicateRefused fails The last two are the both-directions pair: under-apply and over-apply each fail exactly one leg, so the pins bracket the behaviour instead of agreeing with it from one side. Control kept explicit: the round-7 same-name boundary still passes on BOTH doors (internal/mcp + cmd/pad SameNameDuplicate tests), so widening alias detection did not quietly swallow the case that resolves. gofmt clean · go vet clean · go test ./... green (29 packages) context: 45.1% (session-shape)	2026-09-03 17:52:19 +00:00