874 Commits

Author	SHA1	Message	Date
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	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	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	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
xarmian	1de4fd48dc	refactor(mcp): one canonical view, one conflict check (BUG-2850) ... Codex round 13 found a fourth consecutive defect in a prior round's fix, which fired the lead's restructure trigger. The finding and the ruling are the same observation from two directions. THE FINDING. `assign`/`assigned_user_id` and `role`/`agent_role_id` are two names for one target, exactly like `parent`/`plan` — and none of the five guards standing at round 12 compared them. The alias guard knew only about hierarchy; the compat guard only about same-name collisions. So `assigned_user_id:"B"` with `fields:{"assign":"A"}` was accepted and the doors disagreed: resolveAssignName gives the explicit ID precedence over HTTP, while BuildCLIArgs drops the compat ID and emits `--assign A`. One call, two different people assigned. THE RULING. Stop adding guards. Conflict handling had accreted one at every site that noticed a problem — generic path, promoted block, alias check, compat block, canonicalization predicate — and each covered only the sources its author thought about. Round 13's finding is that shape's signature, not a new one. WHAT CHANGED. `detectFieldConflicts` resolves every source (the `fields` object, the `field:[]` entries, the promoted params, the compat IDs) to a canonical key via `fieldAliasGroups`, then refuses on the resulting map. Alias collision refuses even when the values match — the names address one target through different vocabularies (a slug vs a UUID), so "equal" is not a question this layer can answer. Same name from two sources keeps the old rule: equal collapses, differing refuses. The five guards are gone; the per-key branches now do emission only, and they run knowing the input is unambiguous. A new alias pair is one line in a map rather than a sixth guard. SCOPE, unchanged and stated: this runs only when a `fields` object is present, because reshapeItemFields does. A top-level param colliding with a `field:[]` entry and no `fields` object keeps its documented last-write-wins resolution — the round-7 boundary the lead confirmed, still pinned on both doors. EVIDENCE. All 30-odd existing case tests pass unchanged against the new structure; they are the regression net the ruling asked to keep. Added: the round-13 case tests over both directions of both pairs, and a PROPERTY test derived from `fieldAliasGroups` itself — for every alias class, every ordered pair of member names, and every pair of distinct sources, the call refuses. It covers 48 combinations and a future alias pair extends it with no edit. Mutation matrix: drop assigned_user_id from the alias map -> property fails unwire detectFieldConflicts entirely -> 54 tests fail remove the alias-collision branch -> property fails (equal-value legs) The third mutant SURVIVED at first, and the reason is the useful part: my property used differing values, so the ordinary same-canonical-key comparison refused anyway and a build with alias detection wholly removed still passed. The equal-value leg is the one only alias detection catches — exactly the semantics the parent/plan ruling established — so the property now drives both value shapes. CONVE-28 again: on SURVIVED, the mutant was faithful and the test was weak. gofmt clean · go vet clean · go test ./... green (29 packages) context: 45.1% (session-shape)	2026-09-03 17:42:42 +00:00
xarmian	af686c350d	fix(mcp): a blank top-level param does not block the fields answer (BUG-2850) ... Codex round 12, one P1 — and the fix is bigger than the finding, twice over. THE FINDING NAMED ONE KEY. `{status: "", fields: {status: "done"}}` was refused, because the duplicate check treated a present-but-empty top-level param as a competing value. `""` is "not supplied" everywhere else on this surface — promotedParamValue treats it as absent, the CLI's `status != ""` guards do, `assign: ""` is documented inert — so a client that zero-fills its optional params was refused for asking one question. Driving the whole class the key belongs to (CONVE-18: the reviewer names an instance, the fix owes the population) turned `status` into all six promoted keys, which behave identically. Round 10 fixed exactly this for the hierarchy keys and I never asked whether the same reasoning covered their siblings; it did. Third time in this unit that a guard was written for the path in front of me, and this time the guard was mine. THE SAME PROBE FOUND THE EXCEPTION, which matters more than the fix. For `assigned_user_id` / `agent_role_id` an empty string is NOT absence — it is a CLEAR to NULL, the deliberate v0.16 semantics (dispatch_http_advanced.go forwards "" verbatim for exactly these two). Applying the finding uniformly, as its wording invites, would have discarded a clear in favour of the `fields` value: a spurious refusal traded for a silent wrong write, which is the worse half. They stay conflicts, with their own pin. AND THEN A SURVIVING MUTANT CAUGHT A FALSE COMMENT OF MINE. Deleting the compat carve-out failed nothing — because the carve-out lived in a helper that only the PROMOTED block called, while the compat keys were checked in a separate block that never consulted it. Dead code, and the comment I had just written called it "the whole reason this is a function". CONVE-28's rule is what caught it: on SURVIVED, ask whether the mutant is faithful before blaming the test. The mutant was faithful; the code was redundant and the prose was wrong. Both call sites now consult the predicate, so the rule has one home and the carve-out is live — re-running the same mutant against the corrected code fails BlankCompatIDIsAClearAndStillConflicts, as it always should have. Mutation matrix: revert the blank-param exclusion -> only BlankTopLevelParamDoesNotBlockFields fails (6/6 subtests) delete the compat carve-out -> only BlankCompatIDIsAClearAndStillConflicts fails (2/2) [survived before the redundancy was removed — see above] gofmt clean · go vet clean · go test ./... green (29 packages)	2026-09-03 17:27:34 +00:00
xarmian	c2bb1bad34	fix(mcp,server): close three codex round-11 findings, one of them my own bad refutation (BUG-2850) ... Two P1 and one P2. The P2 is the important one, because I had already dismissed it in round 10 and was wrong. [P2 — CORRECTION] Artifact imports DO drop undeclared-field warnings, and the case is reachable. Round 10 refuted this on the grounds that artifact.Decode populates Fields only from FieldKeysForKind, so no undeclared key could arrive. That check was real, and it was the WRONG SIDE of the comparison: UndeclaredFieldKeys compares the field map against the DESTINATION COLLECTION'S SCHEMA, not against the artifact format's key list. The destination schema is editable, so a canonical artifact key can be undeclared THERE while being perfectly legal in the artifact. Verified before reinstating, not argued: narrow the conventions collection's schema to declare only `status`, import an ordinary convention carrying trigger/scope/priority — the blob stores all three and UndeclaredFieldKeys names all three. The merge is back, and the comment now records the correction rather than the refutation, so the next reader inherits the right reason. What I got wrong is worth naming exactly: I verified a true fact and then drew a conclusion one step wider than it supported, because I never asked what the OTHER operand of the comparison could be. "No key outside the artifact's list arrives" does not imply "no undeclared key arrives" unless the destination declares every key on that list — an assumption I never stated and never checked. The test I wrote at the time could not pass, and I read that as confirming the refutation instead of as the setup being wrong. [P1] An empty hierarchy value inside `fields` was a silent no-op. `fields:{"parent":""}` promotes onto the top-level `parent`, where both doors treat empty as NOT PROVIDED — so the call reported success and detached nothing. Refused now, pointing at clear_parent and the raw `field:["parent="]` form. Not silently promoted to a clear: that decides what this door MEANS, and v0.19 already made clear_parent canonical so the empty string would not have to carry it. [P1] The v0.16 compat ID params were not conflict-checked against `fields`. Never schema-declared by design, they are invisible to padItemPromotedFieldKeys and took the generic path, where the check only consults the `field` array. `assigned_user_id:"A"` with `fields:{"assigned_user_id":"B"}` made the doors disagree outright — the remote mapper reads A, stdio emits only `--field assigned_user_id=B`, because the top-level form has no CLI flag behind it. One call, two different people assigned. Conflicting values refuse; equal ones collapse to one form. Also corrected, per CONVE-23: the round-10 test asserting that `fields:{"parent":""}` conflicts with the plan alias now refuses for a DIFFERENT reason and its stated rationale had become false. The case moved to the new test with the right reason, and the field-array clear — which really is an effective directive — stays where it was, with a control leg proving the new refusal did not swallow it. Mutation matrix, each mutant from a file backup: revert the empty-hierarchy refusal -> only EmptyHierarchyValueInFieldsRefused fails (both subtests) revert the compat-ID check -> only CompatIDConflictRefused fails (both subtests) revert the import warning merge -> only the narrowed-schema import test fails gofmt clean · go vet clean · go test ./... green (29 packages)	2026-09-03 17:12:20 +00:00
xarmian	0a71ad3aa9	fix(mcp): an empty parent param is not a hierarchy directive (BUG-2850) ... Codex round 10: three P2, no P1. One fixed, one already filed, one refuted and reverted. [FIXED] An empty top-level `parent` was counted as an alias directive, so `parent: ""` with `fields:{"plan":"X"}` refused a perfectly good call. Every declared string param on this tool treats "" as NOT PROVIDED — it is why promotedParamValue does, and why `assign: ""` is deliberately inert — so a client that fills declared optional params with their zero value rather than omitting them got a refusal for asking one hierarchy question. My own round-9 snapshot carried this forward from the out[]-based check it replaced. Deliberately NOT applied to the other empty forms: `field:["parent="]` and `fields:{"parent":""}` are the documented CLEAR signal (BUG-2013 / BUG-2078), so they are semantically effective and still conflict. One is a param left blank, the other is an instruction that happens to look like one. Both directions are pinned, and the mutation matrix drives both: remove the empty-param exclusion -> only EmptyParentParamIsNotAnAliasConflict fails extend it to the field-array clear -> only EmptyClearFormsStillConflict fails [ALREADY FILED] The transport-dependent whitespace finding is BUG-2870, ruled out of this PR's scope. Round 10 did add something the filing missed and BUG-2870 now records it: the divergence covers VALUES too (`--field "cost= 3"` stores the number 3 remotely and the string " 3" over stdio), which is worse than the key half because both doors report success and only the stored type differs. [REFUTED, REVERTED] "Artifact imports discard createItemChecked's undeclared-field warnings." True as a code reading — this handler builds its own response shape and ignores item.Warnings — but the condition is unreachable. artifact.Decode populates Fields exclusively from FieldKeysForKind via a closed switch over a typed frontmatter struct, so a key outside that per-kind list never enters the map. Verified both ways before reverting, because the import door takes raw bytes and the hand-written case is the one that mattered: Encode drops extra keys, and Decode of a hand-written artifact carrying extra frontmatter keys drops them too. I had written the merge and a test for it before checking; the test could not pass through the public door, which is what exposed the finding rather than my fix. Reverted to a comment recording the mechanism, so the next reader — or the next round — does not re-find it. A branch nothing can enter is not defence in depth, it is a claim that something is handled when it never happens. gofmt clean · go vet clean · go test ./... green (29 packages)	2026-09-03 16:53:14 +00:00
xarmian	56ee3a7e95	fix(mcp): require strings for fields.assign/role; fix the alias refusal's mechanism (BUG-2850) ... Codex round 9: one P1 and one P2. The P1 was REFUTED on inspection and the P2 confirmed; both produced a change, for different reasons. [P2, real] `fields.assign` / `fields.role` accepted a number, and the two doors then disagreed about it. The HTTP dispatcher's `rawAssign.(string)` turns a float64 into "" and treats it as NOT PROVIDED, silently dropping the write; stdio emits `--assign 123` and the CLI fails loudly on the lookup. Same call, one door silent and one red. Refused now at the door-independent layer, which is what stops them drifting apart again rather than teaching each dispatcher separately. Deliberately narrow: this does NOT walk back round 6's decision to accept non-string promoted values in general. `priority` may legitimately be a number in a custom schema and create has always passed such values through — a control leg pins that. `assign` and `role` are references that NAME something, where a number has no meaning at all. [P1, refuted] `fields:{"parent":"A","plan":"B"}` was already refused. But it was refused by ACCIDENT: keys process in sorted order, so `parent` was promoted into out["parent"] and `plan` collided with it one iteration later. Right answer, wrong mechanism — the refusal depended on `parent` sorting before `plan` AND on `parent` being a promoted key, and it told the caller their value conflicted with "the top-level parent param" when no such param was passed. The fields-vs-fields case is now checked against `obj` directly, and a snapshot of the original top-level params keeps that message honest. Reported as verified rather than as agreement: the finding's mechanism was wrong, and shipping "fixed" against a refuted claim would have put a false statement on the trail. Mutation matrix, from file backups: revert the identity-ref requirement -> only NonStringIdentityRefRefused fails (both subtests) revert to the out[]-only alias check -> only BothAliasesInOneFieldsObject fails Plus a PROBE that is not a mutant of the fix: removing `parent` from padItemPromotedFieldKeys leaves the alias pair still refused. Under the old code that mutation made the guard go silent, since nothing would write out["parent"] — which is the latent coupling this change removes. gofmt clean · go vet clean · go test ./... green (29 packages)	2026-09-03 16:32:51 +00:00
xarmian	49e533d478	test(mcp,cli): pin same-name duplicate precedence on both doors (BUG-2850) ... The lead's condition on the round-7 boundary. checkHierarchyAliasAmbiguity refuses parent+plan — two NAMES for one target, which a caller can collide without knowing — but deliberately does NOT refuse a same-name duplicate (`--status A --field status=B`), because those are visibly duplicates and both doors resolve them identically. "Both doors resolve them identically" is the load-bearing half of that argument and nothing enforced it. Two tests now do, one per door, asserting the SAME outcome: the `field` entry overlays the named param, because cmd_item.go and dispatch_http_advanced.go both apply named flags first and overlay --field after. Per-door mutation matrix, run this turn from file backups: make the named param win on the HTTP door -> only the mcp test fails make the named flag win on the CLI door -> only the cmd/pad test fails Neither mutant reddens the other door's test, which is the property worth having: the doors cannot drift apart again without exactly one of these going red and the boundary getting re-examined rather than silently becoming untrue. Also filed, per the lead's ruling: BUG-2870, the padded-`field`-key divergence with NO `fields` object (`--field " effort=l"` stores an undeclared " effort" key on the CLI door and writes `effort` on the remote one). Out of scope here — it predates this PR's claim rather than defending it — and its fix is a policy call on the CLI's input contract, so it wants a ruling, not a quick patch. gofmt clean · go vet clean · go test ./... green (29 packages)	2026-09-03 16:22:00 +00:00
xarmian	4937fd84f6	fix(mcp): canonicalize when ANY entry for the key is padded (BUG-2850) ... Codex round 8, one P2 and no P1 — the first round of this unit that did not turn up a correctness defect on the fields-vs-field seam. Round 7's canonicalization asked whether a canonical entry was PRESENT and left the array alone if one was. So `field:["effort=l", " effort=l"]` with `fields:{"effort":"l"}` kept the padded twin, and the doors then disagreed about it: HTTP trims and writes `effort`, the CLI does not and writes an undeclared `" effort"`. Transport divergence out of a call both doors accept — the shape this unit exists to remove, reintroduced one round earlier by the fix for its sibling. The predicate is now "any entry for this key is non-canonical", so the key is re-emitted once and cleanly. Collapsing the duplicate pair is not lossy: parseFieldArray already indexes both to a single value, so two entries for one key were never two writes. Mutation: restoring the round-7 predicate verbatim fails only MixedCanonicalAndPaddedDuplicatesCollapse. Round 7's two pins still pass under that mutant, which is correct — neither exercises the mixed case, and that is exactly why the new one was owed. NOT fixed here, and named so it is not mistaken for an oversight: a padded entry with NO `fields` object at all (`field:[" effort=l"]` alone) still reaches the CLI door untrimmed. That predates BUG-2850, is unrelated to the fields merge, and normalizing every entry unconditionally changes what the CLI receives for every caller — a policy change, not a defect fix. Flagged to the lead on the trail. gofmt clean · go vet clean · go test ./... green (29 packages)	2026-09-03 16:17:49 +00:00
xarmian	13892fecf7	fix(mcp): close two codex round-7 findings on the same seam (BUG-2850) ... Both are consequences of round 6's own fixes, which is the tell that the seam — a guard written for one key shape, and the keys that do not take that path — is still the thing to keep hitting. [P1] The alias guard did not fire without a `fields` object. Round 6 put it inside reshapeItemFields' per-key loop, and reshapeItemFields returns early when `fields` is absent — so `field:["parent=A","plan=B"]` walked straight past it and extractParentLink's no-early-exit loop applied `plan` while the caller had every reason to believe `parent` was what they set. A guard a caller can step around by moving the same two values into a different param is not a guard. checkHierarchyAliasAmbiguity now runs on create and update regardless of `fields`, over the merged input. SCOPE, stated rather than smuggled: the pure-`field` form was accepted before BUG-2850 too, so this closes a pre-existing silent mis-write, not a regression. Fixed here rather than filed because shipping round 6's guard without it would advertise a refusal that any caller bypasses in one edit. Deliberately NOT extended to same-name duplicates (a `parent` param plus `field:["parent=B"]`) — those resolve last-write-wins identically on both doors, which is documented behaviour, and widening the refusal to cover them is a policy change rather than a defect fix. [P2] A padded equal duplicate was retained raw. Round 6 normalized the conflict INDEX so ` effort=l` matches `fields:{"effort":"l"}` — correct, and it closed the padded-key bypass — but the raw entry stayed in `field`, and the CLI door does not trim. Over stdio that stored an undeclared `" effort"` key and left `effort` untouched: the normalization that made the duplicate visible is what made the retained entry wrong, so the fix belongs at the same place. The entry is now re-emitted canonically, and only when the raw form actually differs, so a well-formed array keeps its contents and its order. Mutation matrix, run this turn, each mutant from a file backup: unwire checkHierarchyAliasAmbiguity -> only the round-7 alias test fails (4/4 subtests) revert the canonical re-emission -> only PaddedEqualDuplicateIsCanonicalized fails Neither mutant touches round 6's in-loop alias test, which is right: that one enters through the `fields` object and is a different path — the distinction this finding exists about. Control legs: a lone hierarchy key through the array still dispatches, an already-canonical duplicate is left byte-identical and unreordered, and the padded-entry case asserts exactly one --field is emitted. gofmt clean · go vet clean · go test ./... green (29 packages) · 18 files	2026-09-03 16:11:01 +00:00
xarmian	dfee13896d	fix(mcp): close four codex round-6 findings in the fields-object merge (BUG-2850) ... All four sit on the same seam this unit keeps failing at: a guard written for one key shape, and a class of keys that does not take that path. [P1] parent/plan alias conflicts bypassed every guard. extractParentLink resolves the hierarchy link with `for _, key := range {"parent","plan"}` and no early exit, so when both arrive the LATER key wins — but every check in reshapeItemFields matched on the SAME key name. So `fields:{"parent":"PLAN-12"}` with `field:["plan=PLAN-9"]` passed and relinked the item to PLAN-9 while reporting PLAN-12. The same alias bypass BUG-2078's round-1 review found on clear_parent, reached through a different door. Refused now in both directions and against the top-level param — and refused even when the two values are EQUAL, which is what v0.19 already does for parent + clear_parent "including via the plan alias". [P1] The conflict index was not normalized the way the door normalizes. ingestFieldKVP TrimSpaces both halves of a `key=value` entry; parseFieldArray indexed the raw halves, so `field:[" status=cancelled"]` sat under " status", missed the guard against `fields:{"status":…}` and then silently overrode it. Trimming the value fixes the mirror-image false refusal (`status= done` vs `done`). ONLY the index is normalized — `entries` stay verbatim, because the CLI door does not trim and must keep receiving exactly what the caller sent. [P1] A non-string promoted value silently no-op'd on remote update. reshapeItemFields promotes `fields:{"priority":3}` with its type intact, but hasFieldChanges and the patch loop both read `.(string)` — so the dispatcher skipped the fields_patch branch entirely and answered SUCCESS having sent no PATCH. A silent no-op reintroduced by the fix for silent no-ops, and asymmetric with create, which has always passed non-strings through. promotedParamValue now accepts any scalar; empty string still means "not supplied". [P2] Equal promoted duplicates did not collapse. `fields:{"role":"x"}` plus `field:["role=x"]` resolved the role to agent_role_id AND wrote a literal `role` key into the fields blob that no schema declares — one value, two writes, one of them an undeclared field with a warning naming it. The array entry is now dropped so the value applies once through its dedicated param. Mutation matrix, run this turn, each mutant applied and reverted from a file backup (never `git checkout` — the tests were uncommitted): drop the alias block -> only HierarchyAliasConflictRefused fails (4/4 subtests) revert index normalization -> only FieldArrayKeysNormalizedForConflicts fails (both legs) revert the duplicate drop -> only the two EqualDuplicate tests fail revert promotedParamValue -> only NonStringPromotedValueIsNotDropped fails No cross-talk: each mutant is the defect at the site its test targets, and each kills exactly that test. Control legs included on purpose — a lone hierarchy key is still accepted, padding-only value differences are not conflicts, an unrelated `field` entry survives the duplicate drop, and an empty promoted string still produces no fields_patch. gofmt clean · go vet clean · go test ./... green (29 packages)	2026-09-03 13:07:36 +00:00
xarmian	7f25283a41	test(server): pin the last three coercion call sites (BUG-2850) ... Five of the eight `CoerceFields` sites had a test that goes red if that site alone is dropped. Move, bulk move and bulk update did not, so the PR's "typed on every door" claim rested on reading the code — CONVE-19 and the shape rounds 2-5 of this unit kept finding. Why the move pins are faithful rather than green-for-free: migrateValue already permits text->number (migrate.go:190), but it returns `value`, the ORIGINAL, not a parsed float. So a text field holding "42" reaches a number-typed destination as the STRING "42", and only CoerceFields at the move site turns it into a number before validation. Assertions are on the STORED NATIVE TYPE, re-read from the item rather than taken from the mutation's own response, so a handler that answered 200 and stored the string is still red. Bulk update merges request STRINGS (status, priority), so it is observable only where the schema declares one of those keys as a non-string type; a collection declaring `priority` as a number is unusual but legal and is the honest way to reach that site. Bulk ops answer 200 with per-item failures in the envelope, so the pins read the envelope too — a status-code-only assertion would pass on a dropped coercion. Per-site mutation matrix, run this turn against these tests, each mutant applied and reverted from a file backup (never `git checkout`, which would have taken the uncommitted tests with it): drop coercion at handlers_items.go:2314 -> only TestItemFieldsCoercedOnMove fails drop coercion at handlers_items_bulk.go:683 -> only TestItemFieldsCoercedOnBulkMove fails drop coercion at handlers_items_bulk.go:499 -> only TestItemFieldsCoercedOnBulkFieldUpdate fails Each mutant is the defect at the site the test targets — not a call-site patch next to a still-correct function (CONVE-28) — and each kills exactly one test, which is the per-site discrimination the PR claims. Files restored and verified identical after the matrix; suite green.	2026-09-03 12:49:33 +00:00
xarmian	baaa236d83	fix(mcp): apply the field-array conflict guard to promoted keys too (BUG-2850) ... Codex round 5, one P1. The `fields` object vs `field: ["k=v"]` conflict guard lived on the generic path, which a promoted key never reaches: `status`, `priority`, `category`, `parent`, `role`, `assign` and `tags` all return from the promoted branch above it. So the one ambiguity this function did not refuse was the one on the keys that matter most. It did not fail closed either. The promoted branch writes the top-level param (`out["status"]`) while the array entry stays in `out["field"]`, and both the HTTP mappers and the CLI overlay `--field` entries AFTER the named flags — so the array silently won. `fields:{"status":"done"}` with `field:["status=cancelled"]` cancels the item. The same shape on `parent` relinks or detaches it. The guard now runs first in the promoted branch, before the existing top-level-param check, with the generic path's semantics: differing values refuse, an equal duplicate falls through and still promotes, and a structure against a string entry (the `tags` case) refuses as "one key cannot be both". This is the fourth consecutive round where the defect was a guard written on the generic path only, and round 4's test is why: it pins `effort`, a key that takes the generic path, so it vouched for the path the guard is on rather than for the class of keys that skips it (CONVE-19). The new test drives all four promoted shapes plus an equal-duplicate control leg. Negative control: all four conflict cases fail on the unfixed tree (run before the fix, not against a synthetic mutant); the equal-duplicate leg passes both before and after, so it discriminates refuse-on-ambiguity from refuse-on-agreement. gofmt clean · go vet clean · go test ./internal/mcp/ ok	2026-09-03 12:46:25 +00:00
xarmian	b23c0dbc6f	fix(mcp): apply the null and hierarchy guards to promoted keys too (BUG-2850) ... Codex round 4, and both findings are the same defect in my own round-3 fix: ORDERING. The null guard and the hierarchy-key guard sat BELOW the branch that promotes status/priority/category/parent/role/assign/tags onto dedicated params, so every promoted key walked around both. - `fields: {"tags": null}` reached the promoted branch and became a silent no-op, instead of the refusal the null rule documents. - `fields: {"parent": 42}` was accepted here and dropped later by the handler — the same silent-drop shape this whole bug is about, reintroduced by a guard I added to prevent a different instance of it. Both guards now run before that branch, so they apply to every key. A guard a whole class of keys bypasses is not a guard. Pinned separately from the generic-path cases, because the generic-path tests passed throughout: they never exercised a promoted key, which is exactly why the hole survived round 3. Reverting the hoist fails the new test. Well-formed promoted keys still promote — tested, so the hoist did not break promotion while closing the bypass. Gates: gofmt clean, go vet clean, go test ./... 29 packages ok. Claude-Session: https://claude.ai/code/session_011Q4b1iHtJtSyMs7BA2ySxo	2026-09-03 01:41:11 +00:00
xarmian	f15f60831e	fix(mcp): guard hierarchy pseudo-keys and correct the fields description (BUG-2850) ... Codex round 3. 1. [P1] A structured `plan` could silently DETACH an item. `plan` is not in padItemPromotedFieldKeys, so it fell to the generic path — and once this branch stopped refusing structures, fields:{"plan":{…}} reached the server natively. There extractParentLink reads any PRESENT non-string plan/parent as a hierarchy directive, drops the key, and on update clears the existing parent link. Lifting the nested refusal quietly opened a path where a malformed value detaches an item from its parent. Guarded specifically: these keys take a string ref and nothing else. Both `parent` and `plan` are listed, so the guard does not depend on which other set a key happens to belong to. A string ref still works — tested, so the fix did not re-refuse the normal case while closing the hole. 2. [P2] The MCP `fields` param description still told agents that multi_select and json non-scalars are "refused, not written". This diff makes that false, and a schema an agent reads is the artifact that decides what it attempts — the reporter's agent rewrote seven playbooks after believing exactly this kind of line. Rewritten to state what is true now, including the two remaining refusals (null, structured parent/plan) and that structured values need the remote transport. Gates: gofmt clean, go vet clean, go test ./... 29 packages ok. Removing the hierarchy guard fails its test. Claude-Session: https://claude.ai/code/session_011Q4b1iHtJtSyMs7BA2ySxo	2026-09-03 01:33:54 +00:00
xarmian	2cf9f0035a	fix(mcp,server,cli): three codex round-2 findings (BUG-2850) ... 1. [P1] The structured-value refusal was in the wrong place and killed the fix. It went into BuildCLIArgs, which env.Dispatch runs for BOTH transports before handing off to whichever Dispatcher is configured — so it blocked the remote /mcp door too, and the native-field handling that is the whole point of this change was never reached. Moved into ExecDispatcher, which IS the stdio door. My own test could not see this: it called mapItemCreate directly, so it vouched for the mapper and not for the path that reaches it — CONVE-19's exact shape, in a unit where I had already written binding tests for the other half. The tests are now split along the two claims the first version conflated: nested values REACH the dispatcher (the remote door is unblocked), and refuseStructuredFieldsOverCLI refuses them at the CLI door naming the transport. 2. [P2] The CLI warning sat after the `--format json` early return, so the caller most likely to have sent a mistyped key — one piping stdout into a parser — was the one caller who never saw it. Moved above the return, and out of the `ref != ""` branch it was also trapped in. Still stderr. 3. [P2] A nil value in fields_patch DELETES the key (store/items.go), so reporting it as an undeclared field told the caller a field was stored that the same request removed. Filtered at the patch site, not inside UndeclaredFieldKeys, because nil means "store JSON null" on the full-fields path where reporting it is correct. Gates: gofmt clean, go vet clean, go test ./... 29 packages ok. Claude-Session: https://claude.ai/code/session_011Q4b1iHtJtSyMs7BA2ySxo	2026-09-03 01:07:45 +00:00
xarmian	dc3fc2d50e	feat(server,cli): name undeclared field keys on the write response (BUG-2850) ... Undeclared keys are ACCEPTED — the census found 168 live values under 14 such keys, and refusing them would break read-modify-write on items nobody edited wrongly. But once stored, a typo and a deliberate extra field are indistinguishable, so the write now says which keys it did not recognize. - models.Item gains `Warnings *ItemWriteWarnings` with `undeclared_fields`, omitempty and additive. NEW API SURFACE: item write responses carried no warnings element before. Wrapping the response as {item, warnings} was the alternative and would have broken every existing parser; a clean write is byte-identical to before. - items.UndeclaredFieldKeys consults models.IsReservedItemField rather than re-listing the reserved set — that set exists so callers ask, and its doc comment records what re-listing cost last time. So a write carrying implementation_notes or github_pr reports nothing. - fields_patch reports only the PATCHED keys. A stray key already on the item is not something this write introduced, and naming it on every touch would train the reader to ignore the field. - The CLI prints one line to STDERR. Never stdout: `--format json` output is piped into scripts, and a warning there would corrupt the JSON they parse. - CLAUDE.md documents the element as new surface. Controls: never attaching the warnings fails the pin; reverting the HTTP mapper's native overlay fails the remote-door type test; dropping the reserved-key exclusion fails its own test. Two coverage gaps the controls FOUND rather than confirmed, both now closed: the remote door's native overlay was covered by no MCP test at all (a revert left the package green), and the reserved-key exclusion had no test either. Both were written after the control survived, which is the only reason they exist. Gates: gofmt clean, go vet clean, go test ./... 29 packages ok. Claude-Session: https://claude.ai/code/session_011Q4b1iHtJtSyMs7BA2ySxo	2026-09-03 00:54:56 +00:00
xarmian	dd919dd0a9	feat(mcp): carry the fields object with its JSON types intact (BUG-2850) ... Second half of BUG-2850, ruled after a census: undeclared keys stay accepted on every door, and a value's native JSON type is preserved wherever the encoding carries one. Only two doors carry a type at all. The remote /mcp `fields` OBJECT param does — and the catalog was destroying it, flattening every value into `field: ["key=value"]` before dispatch. The direct HTTP API does. The other three (remote `field:[…]`, CLI `--field`, stdio MCP, which dispatches through the CLI) are string-by-construction: `key=value` carries no type to preserve, and a string is the correct and complete representation of `cost=42` typed at a shell. So this does not "make every door preserve types" — it stops destroying the types the object form already had. - The catalog merge now emits the native map alongside the string entries, so each transport takes what it can use. Both forms describe the same input; they differ only in fidelity. - The HTTP create and update mappers overlay the native map LAST, so it wins over the stringified copy of itself. - hasFieldChanges consults the native map. Without that a NESTED-ONLY update emits no `field` entry at all, so it reported success and wrote nothing — the silent-drop shape this bug is about, arriving through the fix for it. PR #1159's blanket refusal of nested values is LIFTED, as ruled: its precondition (server-side coercion) landed in ae793e6f, and an object cannot be preserved through a door that refuses it. The refusal moves rather than disappears — BuildCLIArgs now refuses a structured value naming the TRANSPORT limit, because stdio builds `--field key=value` and would otherwise discard the key silently. The message says which door cannot express it rather than implying Pad cannot store it: the reporter's agent rewrote seven playbooks' argument specs after reading the old refusal as a verdict on the data. NULL stays refused, deliberately and against the letter of "preserve native types". "Store JSON null" and "clear this field" are both readable from it, Pad already has an explicit clear vocabulary (clear_parent, clear_assigned_user), and giving null a silent meaning inside a bug fix would be inventing semantics. If a clear-by-null is wanted it should be ruled. Gates: gofmt clean, go vet clean, go test ./... all packages ok. Claude-Session: https://claude.ai/code/session_011Q4b1iHtJtSyMs7BA2ySxo	2026-09-03 00:32:50 +00:00
xarmian	b451fb50de	test(server): bind the coercion to its call sites, and enforce copy/preflight agreement (BUG-2850) ... CONVE-19: wiring is a claim. The previous commit threaded CoerceFields through eight validate sites; a test at the items package vouches for the function, not for any of those bindings. - Three HTTP-door tests (create, update, fields_patch) assert the stored NATIVE TYPE, not that the request returned 201 — a test that only checked the status passes on an implementation that stores the string, which is the shape the reporter described. - A text field holding "42" must stay a string in every one of them. Fixing this bug by coercing anything that parses would retype real data. - An un-coercible value must still be REFUSED with the validator's existing message, so coercion is not quietly widening what the server accepts. - TestCopyAndPreflightCoerceIdentically makes the cross-package invariant real. The preflight validates in internal/server and the copy in internal/store; both files carry a comment saying they must match, and a comment protects nobody. The assertion is agreement FIRST — whatever they do, they must do the same thing — and only then that both accept and the copy stores a number. Controls, each run against the mutated tree: - CoerceFields reduced to the identity function (the unfixed build) fails the two door tests and the items typing test. - Dropping the call at CREATE alone fails only the create test; dropping it at FIELDS_PATCH alone fails only that one. The bindings are individually covered, not covered in aggregate. - Coercing in the copy but not the preflight FAILS, and so does the reverse. Both drift directions are caught. BOUNDARY, stated rather than implied: four of the eight sites — move, bulk update, bulk move, and the migrated-schema paths they share — are wired identically but have no test that fails if that specific wiring is dropped. They are covered by the existing suites for their own behaviour, not for coercion. A follow-up should extend the door tests to them. Gates: gofmt clean, go vet clean, go test ./... 29 packages ok. Claude-Session: https://claude.ai/code/session_011Q4b1iHtJtSyMs7BA2ySxo	2026-09-02 23:38:26 +00:00
xarmian	ae793e6fa6	fix(server,store,items): coerce field values to their declared types server-side (BUG-2850) ... The write doors disagreed about what `key=value` means. The CLI has coerced by schema type since BUG-1125, and local stdio MCP inherits that by shelling out to the binary — but the remote /mcp transport builds its field map in ingestFieldKVP with `dst[key] = val`, so every value arrives as a string. validateFieldType then correctly refuses a string for a declared number or json field, and the net effect was that an MCP agent on that transport could not write those fields AT ALL: every attempt a 400, not a mis-typed value. Measured before writing anything (repro table on BUG-2850's trail): CLI and stdio MCP store 42 and an array; the HTTP door 400s on both; an UNDECLARED key is stored as a string on every door. items.CoerceFields(fields, schema) converts strings to the declared type — number via ParseFloat (NaN/±Inf refused, because json.Marshal cannot encode them and the ignored downstream error would silently drop the whole payload), json/multi_select via Unmarshal, checkbox via ParseBool — and is applied immediately before every Validate* call. Three deliberate non-behaviours, each with a test: - A value that will not parse is left as the string for the validator, so the existing "must be a number" error still fires. Coercion invents no error path, and cannot turn a currently-PASSING write into a failure. - Non-string values pass through untouched; an int stays an int. - Text-typed fields holding "42" stay strings. Coercing anything that parses would retype real data while fixing the bug. Not folded into ValidateFields, though that would be the single call site: a function named Validate that mutates its input is a trap, and two callers re-marshal the map they pass. THE POPULATION IS 8 CALL SITES, and finding them took two sweeps. The first was scoped to internal/server and found 7; the copy path validates in internal/store (items_cross_workspace_copy.go), which only a repo-wide sweep sees. The preflight and the store-side copy now carry cross-references to each other: the preflight exists to PREDICT the copy, they live in different packages, and that is exactly how they would drift unnoticed. The undeclared-key half of BUG-2850 is untouched and marked as a decision point in CoerceFields — refuse/warn/keep is with Dave. A test pins today's keep behaviour so the ruling lands as a deliberate change. The CLI's parseFieldFlag deliberately STAYS: it is why two of four doors are correct today, and removing it alongside its replacement would put all four at risk of one mistake. Retiring it is a follow-up. Claude-Session: https://claude.ai/code/session_011Q4b1iHtJtSyMs7BA2ySxo	2026-09-02 23:30:26 +00:00
xarmian	e89c8c8ab6	fix(cli): two ways the preflight and its remedy disagreed with the migration (BUG-2810) ... Codex round 9, both confirmed against the code rather than reasoned about. **PAD_DATABASE_URL was treated as proof of a PostgreSQL deployment**, so the flow this unit prescribes broke on itself. cmd_server.go opens PostgreSQL only when PAD_DB_DRIVER=postgres; PAD_DATABASE_URL is ALSO migrate-to-pg's target, and its default. An operator who follows the preflight — refused, told to run `pad db repair-nul`, with the target URL still exported in their shell — got "This deployment is PostgreSQL ... Nothing to scan or repair" and exit 0. The remedy the refusal names did nothing, which is the failure mode this unit has now produced three separate ways. PAD_DB_DRIVER alone decides. Verified by running the real command with the target exported. **The preflight refused on tables the migration does not copy.** ExportWorkspace / ImportWorkspace read six tables, and migrate-to-pg's own help says users, platform settings and auth data are not migrated — so a NUL in users.name blocked a copy that would never touch it, demanding the operator rewrite content unrelated to the migration they asked for. Refusal is now filtered to store.MigratedTables(). Those rows are still REPORTED: `pad db scan-nul` lists them, they are real, and going quiet about a broken row because this command does not care about it would be the information-discarding the preflight was already corrected for once. The table set is pinned by REFLECTION over models.WorkspaceExport's shape, not by a regex over ExportWorkspace's SQL — TASK-2825 already established that multi-line and Sprintf-composed SQL are invisible to any source-level instrument. It fails in both directions: a new export section with no entry (a miss, ending in a half-finished migration) and a spurious entry (an over-refusal). One residual, stated rather than hidden: the export also skips SOFT-DELETED collections and items, and this filter is per-table. A NUL in a soft-deleted item still blocks. Narrowing it needs a per-row deleted_at check at every candidate, which costs more than the remaining over-refusal — the operator's way out is the same single command either way.	2026-09-02 18:01:37 +00:00
xarmian	d86a499f56	fix(store): the SQLSTATE extractor indexed one string and sliced another (BUG-2810) ... Codex round 7. sqlStateOf searched strings.ToUpper(msg) for the marker and then sliced the ORIGINAL message at that offset. Correct only while every byte before the marker is ASCII: Unicode case mapping changes byte LENGTH for some runes, and PostgreSQL renders messages in lc_messages, so a non-English server is not a hypothetical. One string now serves both the search and the slice, which also makes the returned code uppercase without a second conversion. Mutation-verified rather than argued: against a message carrying U+0131 (two bytes, uppercasing to a one-byte "I") the old code returns "TE 22" where the code is "22P05". That garbage happens to classify as unavailable — the safe direction — but only by luck; a different offset lands on a spurious "22" prefix and turns a check that never completed into a verdict about the value. The regression leg uses a localised message shape for that reason, and the failure it produces is the one above.	2026-09-02 17:35:58 +00:00
xarmian	6d4c3b4b75	fix(store): an operational SQLSTATE is not a verdict about the value (BUG-2810) ... Codex round 6, and it is the round-5 fail-open one level deeper. That round split "the server answered" from "the server did not", and I implemented the first half as "does the error carry a SQLSTATE at all" — which is wrong, because 57014 (query cancelled), 57P01 (terminated by administrator), the 08 class (connection exception) and the 53 class (out of resources) all carry SQLSTATEs while saying nothing whatever about the value. Classified as verdicts, they let the preflight proceed with an UNVERIFIED suspect, which is the exact thing the three-way split was added to stop. The test is now INVERTED: only SQLSTATE class 22 — data exception, PostgreSQL's class for "this value is wrong" — counts as a verdict about the value. `SELECT $1::jsonb` produces 22P02 for malformed JSON and 22P05 / 22021 for the NUL cases. Everything else, code or no code, means the question was not answered, and the caller refuses rather than guessing. Erring toward "unavailable" is the safe direction: its cost is a refused migration an operator re-runs, against a half-finished one they have to unpick. The coverage is split deliberately, and both halves are needed. The operational codes are from PostgreSQL's error-code table, formatted the way pgx renders them, because provoking an administrator shutdown inside a unit test is not worth it. What is NOT assumed is the rendering, or the premise that class 22 is what a bad value yields: the real-server test now extracts the SQLSTATE from a genuine malformed-value rejection and asserts it is class 22 and a completed verdict, and the closed-pool test covers the no-code path. Neither half stands on its own. sqlStateOf's own edges are pinned too — a truncated "SQLSTATE 22" must not yield a partial code that then matches a class prefix, and the marker search being case-insensitive means the extraction has to be as well.	2026-09-02 17:20:31 +00:00
xarmian	0363c139a9	fix(store,cli): the oracle failed open, and it over-refuses one column (BUG-2810) ... Three findings from codex round 5, all real; the third corrected a claim I had made about the design. **The suspect path could leave data unrepaired and exit 0.** The CLI printed SuspectsFailed and then returned nil, checking only the violation bucket. A script sees success; an operator who trusts the status moves on. Both buckets now decide the exit code, and the decision is extracted into nulRepairExitError so it is testable without a database — the bug was in the decision, not in the repair, and a test that needs a fixture to reach it is a test nobody writes. **The destination oracle failed open.** Connection failures, timeouts and read-back errors were bucketed with "the destination answered, about something else" — reported and not refused on. So an UNVERIFIED suspect passed the preflight, which is the defect the suspect class was added to correct arriving by a different route. There are now three outcomes rather than two: the server answered with a NUL code (refuse), the server answered with another complaint about the value (report, because a NUL preflight that quietly grew into a general one would block migrations unrelated to this bug), and the server never answered (REFUSE). ErrDestinationCheckUnavailable carries the third, and TestDestinationOracleFailsClosedOnAnUnusableConnection pins it against a real closed pool — with an open-pool control first, since a classifier that answered "unavailable" for everything would satisfy the assertion and refuse every migration. **The oracle is not a perfect model of the migration, and I said it was.** Codex claimed workspaces.settings is normalised on import, so the cast over-refuses there. Measured rather than argued, by importing the same shadowed-duplicate value into three columns against a real server: workspaces.settings -> import SUCCEEDS, stored as {"a": "clean"} items.fields -> import FAILS, SQLSTATE 22P05 collections.schema -> import FAILS, SQLSTATE 22P05 CreateWorkspace runs models.NormalizeWorkspaceSettings, a map round-trip that drops the shadowed member. So the claim was right, and my own runtime demo earlier on this branch — which used workspaces.settings — was showing a spurious refusal. The cast STAYS. That row is a value Layer B refuses on every write today and exists only because it predates enforcement, so surviving the migration is an accident of one column's normaliser rather than a property worth preserving, and repair-nul clears it in one command. Deriving "would this column's writer normalise it" is a per-column enumeration, which is the shape this cluster keeps proving unmaintainable. What changed is the CLAIM. The file header no longer says the oracle is "exact in both directions" — it is exact about the VALUE and is not a model of the MIGRATION; the refusal no longer tells an operator PostgreSQL would reject the row, only that the value carries a NUL jsonb refuses; and the measurement and the over-refusal are written into CheckJSONBAcceptable's doc comment and docs/backup.md, which also now states that the check errs toward refusing. The disposition is flagged to the lead rather than settled here: skipping normalised columns is a scope call, not mine.	2026-09-02 17:05:13 +00:00
xarmian	57b7ca5f48	feat(store,cli): ask the destination about suspects instead of dropping them (BUG-2810) ... Day-54 lead ruling on PR #1233, and the ruling names the defect precisely: the scan's own SQL pre-filter already surfaces the shadowed-duplicate row as a candidate, and `ParameterRefused` then drops it. So the preflight was discarding information it was holding and going on to promise the migration would go through. I had recorded that as an accepted residual on the grounds that closing it would violate DOC-2823's one-layer rule — but that rule is about what the enforcement layers REFUSE. It says nothing about a preflight throwing away a candidate it had in hand. **The SUSPECT class.** A pre-filter hit the predicate does not refuse. Most are doubled-backslash literals — text that writes ABOUT the escape, which is the false positive this whole predicate family exists to avoid. One member is not: a NUL in a value shadowed by a LITERAL duplicate key, which a map-model decode drops and PostgreSQL refuses. Nothing here can tell them apart, so nothing here tries: `pad db scan-nul` lists them under their own heading, apart from the violations, with what resolves them. **The destination is the oracle.** `pad db migrate-to-pg` casts each suspect on the TARGET connection — `SELECT $1::jsonb`, side-effect-free, and the very cast an INSERT performs — and refuses on 22P05 / 22021. That is exact in both directions precisely because it is not a fourth opinion of ours. Measured against a real server: the literal is ACCEPTED, the shadowed duplicate is REFUSED with 22P05, and a non-JSON value fails for a reason that is reported rather than refused on, because a NUL preflight that quietly grew into a general one would block migrations unrelated to this bug. **The repair had to be measured, not assumed, and the answer changed the design.** `textguard.Repair` leaves the shadowed value completely untouched: its scanner is gated on DocumentDecodesNULAnyShape, a map-model question that answers false for exactly this shape, so it never runs. A preflight that refused the row and printed `pad db repair-nul` would have been printing a command that does nothing to it — a remedy nobody ran (PATTE-135). So the repair reaches the class through the token-level scanner, exported for this, which rewrites the shadowed escape and still leaves the literal byte-identical because it consumes escapes in order. Suspects get their own buckets in the repair report rather than being folded into Repaired, so the dry run's promise and the run's result stay the same number. **Nothing about what any layer REFUSES changed.** textguard.KnownGaps and its pin are untouched, and TestScanNULInheritsTheRecordedKnownGaps still asserts the scan does NOT detect the shape. TestSuspectsCollapseWhenBUG2812Lands fails when the token-walk makes that false, and names every file to delete — the suspect path is a second mechanism that exists only while the predicate is blind. **One defect this found that no test did.** Running the real command against a real Postgres, the refusal announced "0 stored value(s) carry a NUL; nothing was migrated" while listing one — the count used the violations only, and the tests asserted the message CONTAINED "nothing was migrated" without reading the number. Fixed, and the assertion now reads the count. The whole loop is now verified end to end: preflight refuses, `repair-nul` fixes, the migration completes. My own prose from earlier on this branch is corrected with it. ScanNUL's doc comment, the preflight's, and docs/backup.md all said this shape passes the preflight and fails mid-copy, which the same commit makes false.	2026-09-02 16:45:38 +00:00
xarmian	178b6b5010	fix(server,store): two more from codex rounds 3 and 4 (BUG-2810) ... **The import repair could silently change what gets imported.** It decodes into map[string]any, where a repeated object member keeps only the LAST value. The TYPED decode that runs next does not agree: encoding/json unmarshals members in order into the same struct field, so two `"workspace"` objects MERGE there and collapse here. A body with duplicate members would therefore import differently with --repair-nul than without, which is outside what a flag by that name may do. It now DECLINES such a body: returns it untouched, lets the gate judge it exactly as it would without the flag, and says why in the refusal — "the payload repeats the member X, and repairing it would change which value is imported". Detection is a token walk, because a decode is what loses the information: by the time there is a map the duplicate is gone. The detector's own test carries the false positive that matters — the same member name in SIBLING objects is not a duplicate, and a single shared set of names would decline every real export, since items all carry `id`, `title`, `slug`. Rewriting such a body faithfully wants a token-preserving pass, which is BUG-2812's token-walk and not a rider on this. A real export cannot contain duplicate members (json.Marshal does not emit them), so declining costs nothing an operator meets by accident. The tally now owns the repair — decodeJSONRepairingNUL takes it and calls Apply — so the count and the declined reason come back through one object instead of a return value a caller has to remember to record. That is the same mistake this branch already made once, when the JSON path dropped the count and the header reported 0 for an import that had rewritten a value. **A row the repair could not address was reported as a failure.** A NUL in a key column the list does not protect, on a row whose violation is elsewhere, makes the address unbindable: Layer A inspects every bound parameter, including a WHERE clause's, so the lookup is refused before SQLite is asked to find the row. It landed in Failed carrying "invalid text parameter: parameter 2" — the same information phrased as a fault in the repair rather than a property of the row. Now detected up front and reported as a skip with the reason, alongside the two skips that already existed. **One finding NOT fixed, deliberately, and recorded instead.** Round 3 raised that the scan misses a NUL in a value shadowed by a LITERAL duplicate key, so such a row passes the migrate-to-pg preflight and then fails during the copy — the exact failure the preflight replaces, surviving for one shape. That is textguard.KnownGaps: a blind spot every layer shares on purpose, which DOC-2823 forbids closing in one layer alone, because layers disagreeing about one value is the defect this cluster is made of. So it is named in ScanNUL's doc comment, in the preflight's, and in docs/backup.md for the operator, and TestScanNULInheritsTheRecordedKnownGaps pins the miss and FAILS when it stops being one — the notification that BUG-2812 has landed and those three prose sites need updating. The consequence is recorded on BUG-2812's trail. Round 2's single finding was refuted rather than fixed: it predicted TestRepairFlagReachesTheNestedAndObliqueForms would fail, on a mechanism that describes the raw-byte scanner this branch had already replaced. The test passes; the outer decode resolves the oblique spelling before the walk sees it.	2026-09-02 16:24:25 +00:00
xarmian	49bd342e4c	fix(store,server,cli): three defects from codex round 1 (BUG-2810) ... **The import flag could not repair the column it exists for.** `--repair-nul` scanned the RAW body for a live escape, which is right for a value the gate reads at the top level and wrong for the one that actually matters. An item's `fields` blob travels through an export as a STRING: a NUL escape in the stored blob marshals into the body with a DOUBLED backslash, which a raw scan must leave alone because at that layer it is literal text — while the gate refuses it anyway, since it decodes the body and re-parses that string as the document it is. So the repair now walks the DECODED body with the same classing bodyDecodesNUL uses, one verb changed: where the gate asks textguard whether a value decodes to a NUL, this asks textguard to repair it. Two walks of one shape in one package is a real risk, and the mitigation is that they are measured against the same corpus in both directions rather than reviewed for similarity — TestBodyRepairMirrorsTheGateOverTheCorpus drives every case through the body shape and asserts refused-becomes-accepted and accepted-stays-byte-identical. Two consequences worth stating. The walk also reaches the OBLIQUE spelling — the backslash written as its own escape, so the six characters never appear in the raw bytes at all — which the scanner could not, so the test that pinned that limit is replaced by one asserting the capability. And re-encoding is now possible, so it is bounded: UseNumber, so an integer wider than float64 is not silently re-emitted in scientific notation; SetEscapeHTML(false); and a body with nothing to repair is returned byte-identical rather than round-tripped. The mutation that removes UseNumber turns 9007199254740993 into ...992, and a test says so. The header is now X-Pad-Repaired-NUL-Values, because at the decoded layer an escape is not a thing that exists any more and one nested document may have carried several. **The scan could not run on the databases it exists for.** Several protected tables carry a NULLABLE workspace_id — activities, api_tokens, mcp_audit_log — and the scan selected it into a plain *string, which fails with "converting NULL to string is unsupported" and takes the scan, the repair and the migrate-to-pg preflight down with it. Every column is now scanned as sql.NullString: SQLite also permits NULL in a declared PRIMARY KEY that is neither INTEGER PRIMARY KEY nor NOT NULL, which no other engine does, and a NULL key cannot address a row for an UPDATE — such rows are reported and skipped with the reason rather than handed a WHERE that matches nothing. Verified against the unfixed code: the scan returned `scan activities.actor row: sql: Scan error ... converting NULL to string`. It needed a VIOLATING row in such a table, which is why every fixture that planted its rows in `items` missed it. **--force by accident.** The repair skipped the running-server check whenever --from was given — and the most natural --from an operator types is the path `pad db scan-nul` just printed, which IS the live database. The check is now on the resolved path (Abs + EvalSymlinks, so a symlinked data directory or a relative path still matches), and a --from naming an unrelated backup stays unguarded, which is correct: nothing is writing it. The ordering moved with it. `store.New` runs pending migrations, so the refusal now happens BEFORE the database is opened; opening first and refusing second made the guard arrive after the thing it guards against.	2026-09-02 15:15:11 +00:00
xarmian	63da2f4f5f	feat(store,server,cli): count and repair the legacy NUL population (BUG-2810) ... Layers A and B stop the value being written. Neither makes a row that already carries one go away, and BUG-2810's filing is what that costs: an affected workspace exports with a 200 and re-imports with a 400, so a self-hoster restoring their own backup is blocked with no path forward in the product, and `pad db migrate-to-pg` fails partway through the copy against PostgreSQL's jsonb parser rather than up front. This is DOC-2823's S3, on Dave's day-54 rulings: U+FFFD as the replacement, repair standalone only with a migrate-to-pg preflight that refuses and prints the command, `--repair-nul` on import shipping default-strict. ONE REPAIR, beside the one predicate. textguard.Repair lives next to ParameterRefused because four layers that agree about what is REFUSED and disagree about what a repair PRODUCES is this bug family arriving one step later. Its contract is a property over the same corpus, in both directions: every refused value becomes one all four layers accept, and every accepted value comes back IDENTICAL. The second half is the load-bearing one — a repair that tidies values nobody complained about rewrites `{"a":"x\\u0000y"}`, six literal characters after a doubled backslash, and corrupts it. The JSON arm is a string-literal SCANNER, not decode-walk-remarshal, which is what the recon write-up proposed before it was written. Re-marshalling changes four things nobody asked to change — object key order, insignificant whitespace, integers wider than float64, HTML-ish characters — and silently drops one of a document's LITERAL duplicate keys, which is a gap BUG-2812 owns and the last thing a repair should do. Scanning copies every byte it does not deliberately rewrite, so an untouched document is byte-identical without that having to be argued. A substring replace is not equivalent and the test that proves it took a mutation to find: a doubled-backslash literal ALONE never reaches the scanner, so the discriminating fixture is one document carrying a live escape AND a literal. THE COUNT IS COMPUTED IN GO. Measured on the read path in this worktree: a row planted with `bad<NUL>name` reads back into a Go string with all 8 bytes and the NUL intact, while `length(name)` in the same database answers 3. TASK-2824 found that C-truncation and concluded no DB-side REPAIR could be trusted; the same measurement on the read path says no DB-side COUNT can be either. SQL narrows — `instr(col, char(0))`, plus the escape prefix on JSON-classed columns, which is textguard's own pre-filter — and never decides. The decision stays ParameterRefused with isJSON from the shared 86-column list, i.e. Layer B's classing. Row addressing is read from the live schema rather than a hand-kept map: 39 tables carry protected columns, one (item_wiki_links) declares no primary key and is addressed by rowid, two have composite keys, and five have a single key that is not `id`. The repair checks RowsAffected because an address that stopped selecting its row would otherwise commit an UPDATE that touched nothing and report it as repaired — the one failure an operator cannot see in the output. `email_optouts(email)` is both a protected column and its own primary key. Repairing it changes the row's identity and can collide with an existing row, which in that table means somebody starts receiving mail again. It is reported and skipped, with the reason. The import flag is NOT an exemption from the gate. `--repair-nul` buys the body one repair attempt and then runs the same `bodyDecodesNUL` on the repaired bytes, which still decides — a decode path that skipped the check is the door BUG-2803 spent thirty rounds closing, on the endpoint carrying the largest attacker-controlled body in the product. Only the ESCAPE form is repaired: a raw NUL byte makes the document invalid JSON, and widening what parses is not this flag's job. Both doors are covered, JSON and tar.gz, because giving them different answers is how one of them keeps being forgotten. Postgres is settled with evidence rather than sent up as a ruling: it cannot hold either defect (22021, 22P05) and the four-way differential test already pins that, so the scan reports not-applicable WITH the reason rather than returning a zero a reader could mistake for a clean database. Spellings settled here, per the dispatch: `pad db scan-nul` and `pad db repair-nul` as siblings rather than `repair --nul`, matching `migrate-to-pg`'s hyphenated compound — a repair verb that errors when given no flag is a worse shape, and there is no second repair to share it with. scan-nul IS the dry run, so repair-nul grows no --dry-run. It refuses while the server is running unless --force, on the `pad db restore` precedent: the report is a claim about a database, and one somebody else is concurrently writing makes it a claim about a moment that has passed. docs/backup.md's section on this is rewritten. It still said the rule lives in the binary and not the database, which S2 made false, and it pointed at this item for a preflight and a repair that now exist. Its import examples also showed `pad workspace import < file`, which has never worked — the file is an argument. Closes BUG-2810.	2026-09-02 14:53:31 +00:00
xarmian	f54a0e41d4	docs(store,server): four comments and one log line that had stopped being true (BUG-2827) ... Codex round 6. No logic finding; it confirmed the refusal ordering, the split-budget claim and the first-tick scan as sound. Five statements in the branch's own prose were untrue of the code as it stands: - MaxOutboxPayloadBytes' comment still argued from 64 MiB ("two orders below both ceilings") after the constant became 128 MiB, which is 4x under the lowest ceiling, not two orders. - maxOutboxClaimBytes' comment counted a scan-into-string-then-copy transient that round 1 removed; the scan lands straight in []byte. - maxOutboxClaimRows' comment used the item BODY mean (~2.4 KB) as the payload mean; the measured payload mean is ~3.5 KB, so 5,000 rows is ~17 MiB, not ~12. - emitBulkItemEventTx's early-out said the numbers the caller sees still come from writeOutboxTx; when the early-out fires they come from the projection, and the error says so in Measured. - The drain's oversized-row log said "not claimed". OversizedPendingOutbox filters only dispatched_at, so during a rolling upgrade a binary older than the ceiling may be holding a claim on the row it names. The line now states what the query establishes: this instance will not claim it. The doc says why claimed_at is deliberately not a filter.	2026-09-02 12:33:08 +00:00
xarmian	0836808ca5	fix(store): drop a past-the-hop-bound event before judging its size, and correct three comments (BUG-2827) ... Codex round 5. No production defect found; one ordering edge and three comments that had stopped being true. THE ORDERING. writeOutboxTx has two refusals that disagree about the mutation. The hop bound drops the event and lets the mutation stand, because only the cascade it would extend is illegitimate. The size cap fails the mutation, because there the mutation and the event are the same fact. An event that trips BOTH was judged for size first, so it failed a mutation over a row that was never going to be written. The hop drop now comes first. Unreachable today - nothing propagates a hop - which is exactly why the ordering is worth pinning before something does. TestAnOversizedEventPastTheHopBoundIsDroppedNotRefused fails with the two checks swapped back (run before the crash that interrupted this round, and again on this tree). THREE COMMENTS. The drain-limit constant said whole batches are claimed past it; the byte budget and row cap can now split one. The claim candidates' doc said every sibling; it is as many as the budget still allows. OversizedPendingOutbox's doc named the write cap while its query uses the claim ceiling, and said it ran every tick when the caller throttles it to once per five minutes. Gates: gofmt clean, golangci-lint 0 issues, full SQLite suite exit 0, full Postgres suite exit 0.	2026-09-02 12:06:02 +00:00
xarmian	57caa7f92e	docs,test(store): correct five comments and strengthen the shrink fixture (BUG-2827) ... Codex round 4. Its one P1 does not hold, but the test it named as weak genuinely was, and five comments in this branch had drifted from the code they describe. THE P1, CHECKED RATHER THAN ARGUED. The claim measures size at candidate selection and never rechecks it, so a payload that GREW during a concurrent scrub could be claimed over the ceiling. The proposed growth path was Go's HTML escaping: json.Marshal writes < as its six-character unicode escape, where the source had one byte. Measured against Postgres 16: a one-key object whose value holds the four characters x<y>z&w, written with those characters LITERAL -> 16 bytes the same object written with < > and & as their six-character JSON unicode escapes instead -> 16 bytes Postgres parses the escapes and stores the characters, so the escaped and literal forms are the same size and the round trip cannot grow the row. On SQLite the payload is stored exactly as Go wrote it, so re-marshalling is idempotent. The rejection from round 3 stands, now on a measurement instead of an assertion about key removal. But the test defending it was weak, and codex was right about that: its fixture was one repeated ASCII letter, which cannot tell any of these encoder paths apart. It now carries <, >, & and non-ASCII, so it exercises the divergence rather than asserting past it. Mutation note worth keeping: a whitespace-padding mutant is caught on SQLite and NOT on Postgres, because jsonb discards insignificant whitespace — the mutant does not actually grow the stored row there. The faithful mutant adds a key, and that one dies on both. FIVE COMMENTS THAT SAID SOMETHING UNTRUE, all introduced by this branch: - OversizedOutboxPayloadError was documented as the write cap's error; three sites raise it, against two different limits. - "The two things Measured can name" listed three. - measuredStoredRow said "as the database stored it", but OctetLength measures what the driver hands back, which on Postgres is the ::text rendering rather than storage. - OversizedPendingOutbox described its threshold as the write cap while querying the claim ceiling. - ClaimPendingOutboxEvents still said batches are claimed whole, which the byte budget and row cap deliberately interrupt. Tests also now assert Measured at all three refusal sites — without it the field could be blank everywhere and every existing assertion still passes — and the claimability property test's refusal branch checks the row actually rolled back, so "refused" cannot be satisfied by a write that committed anyway. Gates: gofmt clean, golangci-lint 0 issues, full SQLite suite exit 0, full Postgres suite exit 0. Claude-Session: https://claude.ai/code/session_01XLtX4dbjBpApbAv3SuBcTm	2026-09-02 12:05:57 +00:00
xarmian	213142c4b5	fix(store,server): honest refusal figures and a throttled oversized scan (BUG-2827) ... Codex round 3. Two of three findings acted on, one rejected with an invariant test in place of the change it asked for. REFUSAL FIGURES SAID SOMETHING FALSE. The store refuses on two different measurements against two different limits — the member content before marshalling, against the write cap, and the row exactly as stored, against the claim ceiling — and both reported the number as "a %d-byte payload". For the first that is untrue: projectedBulkPayloadBytes is explicitly a lower bound, so the message named a size the payload did not have. A caller seeing two different numbers for one mutation had no way to reconcile them. OversizedOutboxPayloadError now carries what it measured, and both the error and the 413 say so. THE DIAGNOSTIC WAS THE MOST EXPENSIVE THING THE DRAIN DID, and it was most expensive when it found nothing. OversizedPendingOutbox has a non-sargable size predicate and no index to help it, so an empty result means evaluating octet_length over every pending row — on Postgres, detoasting and serializing each JSONB payload — and it ran every 5s tick. Now throttled to once every 5 minutes. Latency is the cheap thing to spend here: the rows it reports are permanently unclaimable and sit until the 7-day retention takes them, so a five-minute alarm delay changes no decision anyone makes about them. The first tick after a restart still scans, so an existing oversized row is reported promptly. REJECTED: that the claim needs to revalidate size, because a concurrent scrub could grow a payload between candidate selection and the claim UPDATE. It cannot. scrubOutboxRowTx is the only UPDATE of payload in the tree and it removes keys and re-marshals compactly, so a rewrite is strictly smaller — and shrinking is harmless, since a row judged claimable stays claimable. That is load-bearing for the claim needing no revalidation, so it is now stated at the function and pinned by TestScrubOnlyEverShrinksAPayload rather than left as an assumption for the next person adding a payload rewrite to break silently. The throttle test found its own gap on the way in. Written first against the helper, it stayed green when the call site was mutated to `if true` — a helper nothing calls is still correct in isolation. TestOutboxDrainTickConsultsTheThrottle covers the call site through the stamp the tick leaves behind. Also caught by the gate rather than by review: the field carrying the throttle clock landed on outboxDrainSettings as well as outboxDrainConfig, because the edit matched a line both structs have. Tests passed with both; lint named the dead one. Gates: gofmt clean, golangci-lint 0 issues, full SQLite suite exit 0, full Postgres suite exit 0. Mutants: growing the written payload kills TestScrubOnlyEverShrinksAPayload, removing the throttle call site kills TestOutboxDrainTickConsultsTheThrottle. One mutant discarded as unfaithful — corrupting the payload BEFORE the compare-and-swap is neutralised by the retry, which re-reads and redoes the work correctly, so it tests the retry rather than the invariant. Claude-Session: https://claude.ai/code/session_01XLtX4dbjBpApbAv3SuBcTm	2026-09-02 01:41:47 +00:00
xarmian	46a551aa4b	fix(store): refuse an outbox row on its STORED size, not its Go size (BUG-2827) ... Codex round 2. One material defect, and the measurement that settled it invalidates an argument the previous commit leaned on. I had claimed the Postgres JSONB text expansion was bounded near 1.4x — whitespace after colons and commas — which is why a 2x claim ceiling was said to guarantee that anything writable is claimable. That is wrong. Postgres reparses JSON numbers as `numeric` and prints them positionally, so the expansion has no ceiling at all. Measured against Postgres 16: {"a":1,"b":2} 13 bytes -> 16 (whitespace only, ~1.2x) {"a":1e-100} 12 bytes -> 109 (~9x) {"a":1e-3000} 13 bytes -> 3009 (~231x, exponent free to grow) So no multiple of the write cap is a safe claim ceiling, and the Go-side cap does not bound the stored row at all. Reachable rather than theoretical: item payloads carry `fields` as a JSON *string*, whose contents are escaped text and immune, but a bulk delta is a map[string]any and a numeric field value from a request body arrives as a float64 that re-marshals in exponent form. The failure it produced was a row accepted by the write and then excluded from every claim for the rest of its retention window — written, undeliverable, visible only as an oversized-row log line. Fixed where the number is actually true: the INSERT now RETURNs octet_length of the stored payload and refuses against the claim ceiling, rolling the caller's transaction back exactly as the pre-marshal check does. "A row this binary wrote is a row this binary can read back" is now established by construction instead of inferred from an expansion argument that did not hold. MaxOutboxClaimableBytes keeps its 2x value but loses its false justification: its job is only to leave ordinary payloads room above the write cap so the two rules do not fight over rounding. Test gaps from the same round, all three closed: - The claim-ceiling invariant was pinned only by a Postgres round-trip, so a ceiling collapsed back to the write cap passed every default (SQLite) run. The constants test now asserts the relation directly and fails on either dialect. - TestBatchSiblingQueryIsBoundedInSQL drives claimableBatchSiblings directly: bounding the batch in the caller instead of in SQL passed every assertion on the claim's return value while keeping exactly the unbounded allocation the row cap was added to remove. - The scrub's byte budget changes peak memory and nothing else, so removing it left every outcome assertion green. A TEST-ONLY afterOutboxScrubBatch seam makes batch count observable, which is the one visible consequence of the budget working. Codex also confirmed the previous round's rejected finding: keyset paging covers every row present at the initial scan and additionally catches later commits sorting above the cursor, so it is a superset of the unbatched behaviour rather than a regression. Mutation matrix, run on BOTH dialects: dropping the stored-size refusal kills TestEverythingWrittenIsClaimable on Postgres only (correctly — it is a Postgres defect); dropping the sibling SQL LIMIT and collapsing the claim ceiling kill their tests on both; dropping the scrub byte break kills TestScrubSpendsItsByteBudgetNotJustItsRowLimit. Gates: gofmt clean, golangci-lint 0 issues, full SQLite suite exit 0, full Postgres suite exit 0. Claude-Session: https://claude.ai/code/session_01XLtX4dbjBpApbAv3SuBcTm	2026-09-02 00:53:29 +00:00