Disable bare global-id handles on all wi mutators — require KEY-N project ref

Sub-tickets

Questions

Activity

• wi-cli-venus created · 7w ago
• wi-cli-venus commented · 7w ago
  Elazar directive (2026-06-26 15:10): the legacy path that allows MODIFYING an item by bare sequential/global id (instead of the project ref) must be DISABLED. Hard requirement, supersedes BWI-19 part2's conditional guard. Scope: ALL wi CHANGE commands must REJECT a bare-integer handle and require the KEY-N ref (e.g. VENUS-57). Affected: status, close, cancel, assign, block, rename, set-parent, event, ask, and DELETE. READ commands (show/events/tree) keep accepting bare id or ref — read-only, no risk. Impl: in cli-scripts/wi, the mutator path's require_ref currently accepts /^[0-9]+$/. Add a mutator-only check that rejects pure-integer handles with a clear error, e.g.: 'wi: bare ids are disabled for changes — use the project ref (e.g. VENUS-57). Find it with: wi ls <project>.' Keep KEY-N (^[A-Za-z][A-Za-z0-9]{1,9}-[0-9]+$) as the only accepted change handle. Recommend ALSO enforcing server-side in wi-http-server.mjs (defense-in-depth: reject bare-int on the mutating endpoints) so the HTTP API can't be hit with a bare id either — but CLI-level is the must-have per the directive. Consequence: this makes the wrong-project close impossible without any per-agent config → BWI-20 (BWI_PROJECT rollout) becomes unnecessary for safety; PM will cancel it once this lands. BWI-19 part1 echo stays. Keep the existing cross-project 409 guard (harmless, now mostly redundant).
• wi-cli-venus commented · 7w ago
  SCOPE EXPANDED (Elazar 15:14, 'why show 57 no go, confuses llms'): bare global id must be rejected EVERYWHERE, reads included — KEY-N is the only accepted handle for ALL item-handle commands (show/events/tree + all mutators). Reads now reject bare-int at the CLI too. Plus: parent-VALUE (set-parent target, add --parent) also locked to KEY-N (same ambiguity). Plus: stop surfacing the raw global id in human/LLM-facing output (drop 'id =' from show, id column from ls/mine/tree); keep in --json only if tooling needs it. Exceptions: (1) internal server resolveId stays permissive for read/parent resolution (CLI-level reject suffices, avoids breaking HTTP/internal callers); (2) BWI_ALLOW_SQLITE offline path stays on require_id (emergency-only, refused-by-default, KEY-N unresolvable offline) — note in error text.
• wi-cli-venus blocked · 7w ago
  Blocked on BWI-22: 159 non-deleted items lack KEY-N refs; require_ref KEY-N-only would make them unreadable/unmutable. Code reviewed+approved by PM; push held until BWI-22 backfill verifies 0 #-refs across all projects.
• wi-cli-venus statusChanged · 7w ago
  BWI-22 gate verified 0 #-refs — unblocked, cleared for push/deploy
• wi-cli-venus commented · 7w ago
  BWI-21 deploy verify: KEY-N mutator path live on PID 1737198
• wi-cli-venus completed · 7w ago
  Shipped + prod-verified (venus wi-http PID 1737198, commit 144f6c5). KEY-N is now the only handle the CLI accepts (reads + all changes + parent-values); bare global id rejected, raw id suppressed from human/LLM output. Server hard-rejects bare-int on all mutating endpoints (400); server reads stay bare-int-tolerant for internal callers (decision b); offline BWI_ALLOW_SQLITE path unchanged. Verified: CHECK1 curl bare-int mutator→400, CHECK2 KEY-N mutator end-to-end ok, CHECK3 wi show 35→400, KEY-N read ok+id suppressed. Prereq backfill BWI-22 done (652 items, 0 #-refs).