Repository navigation
Closed
Labels
app/idPackage/app: id (pkgs/ or apps/ in this repo)Package/app: id (pkgs/ or apps/ in this repo)effort/lLarge: multi-day or open-ended; expect staged check-insLarge: multi-day or open-ended; expect staged check-inskind/featureNew feature or capability requestNew feature or capability requestmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedIntake review done: acceptance criteria, links, and normalized labels addedpriority/lowNice to have; do when convenientNice to have; do when convenientstatus:done
Description
Finding
The design specifies search by author and by kind, and multi-term AND over tag claims, but neither is built and no issue tracks the gap. The tag-search CLI verb is wired (id claim search NAME [VALUE]), so this is purely the library-side scope expansion.
Evidence
- Phase 5 record
doc/2026-10-12T14-33-36Z_phase_5_tags_documents/...md, P5.5 Open: "Search by author and by kind (design §9.4) is not built. The index has no author key." and "Multi-term AND (task 06, item 3) is not built." - Plan
doc/2026-10-11T11-08-42Z_design_remaining_work/plan-phases.md§10, P5.5: "Search over the tag index" — done (src/search.rs,tests/search.rs), but the design §9.4 / task 06 item 3 scope is broader than the delivered single-name search. pkgs/id/src/search.rs:searchtakes one name (ValueMatch::{Any, Bare, Exact}); no author key insrc/tag_index.rs(namedonly).
Why it matters
Plausible improvement over the delivered P5.5, already designed, so it should either be built or explicitly descoped with a note. Left untracked it will be silently dropped.
Suggested scope
Add an author key to the tag index and author/kind search terms, plus multi-term AND; or record a decision that single-name search is the intended scope and close this.
Acceptance criteria
- Library search supports searching by author and by kind, in addition to the existing name/value search, and the tag index carries the author key needed for it.
- Multi-term search combines terms with AND semantics.
- Tests cover author search, kind search, and multi-term AND in the search / tag-index test suites; existing single-name search behavior is unchanged and its tests still pass.
- OR, as an alternative closing path: a descope decision is recorded on this issue (single-name search is the intended scope) and the Phase 5 design record (P5.5) is updated to match.
Metadata
Metadata
Assignees
Labels
app/idPackage/app: id (pkgs/ or apps/ in this repo)Package/app: id (pkgs/ or apps/ in this repo)effort/lLarge: multi-day or open-ended; expect staged check-insLarge: multi-day or open-ended; expect staged check-inskind/featureNew feature or capability requestNew feature or capability requestmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedIntake review done: acceptance criteria, links, and normalized labels addedpriority/lowNice to have; do when convenientNice to have; do when convenientstatus:done
Activity
developing-today commentedon Oct 24, 2026
CODE-119
dezren39 commentedon Oct 26, 2026
Intake review
Related: Phase 5 record P5.5 and design §9.4 / task 06 item 3 (cited in the body); the delivered single-name tag search is
pkgs/id/src/search.rs+tests/search.rs. No sibling issue tracks author/kind search or multi-term AND — this is the tracking issue for that gap.Still live (verified 2026-10-26): no merged PR references or resolves this issue, and the body evidence stands —
searchstill takes one name and the tag index has no author key. Not solved; do not close.Notes / risks: This is designed-but-unbuilt scope, not a bug: the plausible outcomes are build it or explicitly descope it, and the appended acceptance criteria carry both closing paths so the item cannot sit undecided. Index changes (author key) touch the tag index format — whoever builds it should check index compatibility / rebuild behavior.
Suggested approach: Decide build-vs-descope first. If building: add the author key to the tag index, extend search terms (author, kind, multi-term AND), and test at the library level before wiring any CLI surface.
🤖 Agent note · intake enrichment
dezren39 commentedon Oct 28, 2026
🤖 Agent note · picked up
dezren39 commentedon Oct 28, 2026
🤖 Agent note · done
Triage verdict — gap confirmed at HEAD; routed to a scoped implementation packet
Verified fresh 2026-10-28, at current HEAD:
pkgs/id/src/search.rs:50—pub fn search(claims: &[Claim], name: &str, value: ValueMatch<'_>) -> Vec<Hit>takes exactly one name/value term;search_store(line 84) has the same single-term shape. No author term, no kind term, no multi-term composition.pkgs/id/src/tag_index.rs:36-38—TagIndexcarries only thealphaandomegaBTreeMaps; its accessors (subject,subject_name,subject_name_value,named,value,value_name,value_name_subject) are subject/name/value-shaped. There is no author key and no author accessor, even though eachEntryrecords the claim's author. The issue's evidence is accurate in every particular.Route: this is a real, designed, unbuilt gap — not a wontfix and not a descope candidate on the evidence (the design §9.4 scope was deliberate, and the gap is purely library-side since the
id claim searchCLI verb is already wired). Enqueued a scoped follow-up packet: queue task 2658 (small_fix, deduperepo-health:v1:fix:developing-today/code:issue:800) — add the author key to the tag index, author/kind terms plus multi-term AND insearch/search_store, tests for all three, existing single-name behavior unchanged. This issue stays open and is labelledqueue/queuedfor task 2658; it closes when that implementation lands.153 remaining items
dezren39 commentedon Oct 29, 2026
🤖 Agent note · parked
dezren39 commentedon Oct 29, 2026
🤖 Agent note · parked
nix flake check (clippy-lint), which failed on FlakeHub authentication infra ("FlakeHub registration required. Unable to authenticate to FlakeHub") — the same infra failure seen on PR id(world): wire manifest apply — module install + schedules over the wire (#807) #1820 this shift, now filed as ci: jobs fail with 'FlakeHub registration required' authentication error (clippy-lint observed on #1806, #1820) #2120. Re-run of failed jobs is refused while the workflow run still has a queued aggregate job.queue/2658-800-search-author-kind· infra: ci: jobs fail with 'FlakeHub registration required' authentication error (clippy-lint observed on #1806, #1820) #2120dezren39 commentedon Oct 29, 2026
agent-note:v1 · agent: repo-queue-worker-shift-b (lane B) · task 2658 · kind: small_fix · outcome: picked up (resume) — PR #1806 already implements this fix (branch queue/2658-800-search-author-kind); resuming from the awaiting_ci checkpoint: verifying CI state fresh and closing out, no parallel work
dezren39 commentedon Oct 29, 2026
agent-note:v1 · agent: repo-queue-worker-shift-b (lane B) · task 2658 · kind: small_fix · outcome: done — PR #1806 merged (merge sha 5a843a1). CI: all test jobs (test-unit, test-shard-0..3), cargo-check, doc and fmt checks SUCCESS; the only failure was clippy-lint on the FlakeHub registration/auth infra error tracked at #2120 (unrelated to this diff — search.rs, tag_index.rs, tests/search.rs only), and a rerun was refused while the aggregate run sat queued; merged under the standing unrelated-infra-failure rule with the change itself verified by the passing test/check jobs.