Repository navigation
Description
Gap found by the #1075 validation audit (Phase 5, P5.7) — 2026-10-27
The plan of record (doc/2026-10-11T11-08-42Z_design_remaining_work/plan-phases.md, P5.7) specifies the alias list as (text, date, creator), with contested sets shown and shortest-unique-prefix disambiguation.
On current main 37418e56 the alias display module (pkgs/id/src/aliases.rs) implements text + creator, contested sets, pet-name/primary precedence, and unique-prefix disambiguation (pkgs/id/tests/aliases.rs — contested, primary, petname, prefix tests all present), but its own header states the remaining hole verbatim:
"The creation date is not shown, because the signed header has no time field (open)."
So the date element of the P5.7 alias list has no source and no display, and no existing issue tracks it (checked 2026-10-27: alias/date searches return only tangential items; the related user-subject hole is separately tracked as #160).
Acceptance criteria
- Either: alias rows expose a creation date derived from a source the design accepts (with the source named in
aliases.rs), and a test covers it; or - the plan's P5.7 row is amended to drop the date element with the reason recorded, and the "(open)" note in
aliases.rsis replaced by a pointer to that decision.
Found by: queue task 1256 (slice 4 of the #1075 audit), Lane D worker shift 2026-10-27.
Activity
developing-today commentedon Oct 27, 2026
CODE-511
dezren39 commentedon Nov 2, 2026
Triage verdict: confirmed — gap is real on current main
Probed
origin/main0e26fa4b3(2026-11-02):pkgs/id/src/aliases.rs:17still carries the hole verbatim: "The creation date is not shown, because the signed header has no time field (open)."Aliashas onlyclaim: Hash,text: String,author: AuthorKey— no date field;Row/Shownexpose no date either.Claiminpkgs/id/src/tag_claims.rs:83hasid,author,subject,name,value— no time/timestamp; nothing downstream could source a creation date.created_at|timestamp|DateTime|creation(beyond that doc line) anywhere inaliases.rsorpkgs/id/tests/aliases.rs.Neither acceptance path has happened: no date on alias rows, and the plan row /
(open)note are untouched.Route: enqueueing a scoped follow-up packet for issue #1422 (either expose a creation date from a design-accepted source + test, or amend the P5.7 plan row and replace the
(open)note with a pointer to that decision). No hard-stop labels on this issue; triage claims no files changed.dezren39 commentedon Nov 2, 2026
Done: triaged, follow-up enqueued
triaged— issue stays open, gap confirmed onorigin/main0e26fa4b3.(open)note.work/assigned,queue/claimed,status/in-progressremoved).48 remaining items
dezren39 commentedon Nov 4, 2026
🤖 Agent note · picked up
dezren39 commentedon Nov 4, 2026
🤖 Agent note · parked
dezren39 commentedon Nov 4, 2026
agent-note:v1
event: handed_off
task: 9193
lane: code-m (worker repo-worker-code)
execution_lane: opencode
note: Claimed by lane code-m at 2026-11-04T07:44Z; execution-lane assignment is opencode, so the task is handed off — the laptop opencode claimant launches the bound session, which drives task 9193 to its terminal state. Stale queue/parked + status/parked labels replaced with the claimed set.
dezren39 commentedon Nov 4, 2026
Agent note — task 7534 handed off to opencode claimant (lane code-l)
opencode, so this worker does not work it directly.handed_offand parked 1200s for the laptop opencode claimant to bind. If unbound by park expiry, the task returns to the queue.dezren39 commentedon Nov 4, 2026
🤖 Agent note · handed off