Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[refactor] spectra-archive-post-ic --linked-issue membership semantics (escape-hatch reliability) (follow-up from #170) #172

Description

@kiki830621

Problem

The #170 fix added an escape hatch: when detect_candidates returns an empty set, --linked-issue <N> is accepted authoritatively (membership validation skipped). But the 6-AI verify of PR #171 surfaced that the escape hatch's reliability hinges on "candidate set is empty", which is fragile in two ways:

  1. Spurious candidate defeats the override (codex, verify P2): any non-empty candidate set — even a single spurious one from context-blind prose matching (e.g. a cross-reference see issue #164, or 可能 issue #46) — flips the path from escape-hatch to membership-validation, so a legitimate --linked-issue 555 gets rejected because 555 ∉ {spurious}. The word-boundary fix (PR fix: spectra-archive-post-ic linked-issue escape hatch + prose detection (#170) #171) removes substring matches (reissue/tissue) but NOT legitimate-English cross-references.
  2. Timing-dependent emptiness (DA-3, codex): detect_candidates fallback 3 is git log -- <archive_dir>. From the repo cwd against a committed archive, F3 finds the archive's own commit #N, so the set is non-empty. The escape hatch only fires because, in production, spectra-archive posts the IC before committing the moved archive (F3 sees an untracked path → empty). Fixture 13 can only reproduce the empty case via /tmp-cwd isolation.

Root tension: --linked-issue's membership validation conflates two distinct use cases:

  • exit-75 disambiguation re-invoke — agent must pick one of the detected candidates (validation is correct here, catches agent errors).
  • user/agent authoritative override — caller knows the issue number; detection is irrelevant (validation is wrong here, rejects legitimate input).

The script can't currently tell them apart — both arrive via --linked-issue.

Also surfaced (DA-1, verify MEDIUM)

On the escape-hatch path, --linked-issue <wrong-but-existing-N> silently posts the ## Implementation Complete supersession anchor to an unrelated live issue. ^[1-9][0-9]*$ (PR #171) rejects 0/nonexistent-by-format, and a nonexistent number fails at gh issue comment, but a valid-but-wrong number mis-posts silently. Riskiest where no human reads the outcome.

Proposed directions (待 diagnose)

  1. Separate the two intents — e.g. a --force-linked-issue <N> (authoritative, bypasses membership + detection entirely) vs the existing --linked-issue <N> (exit-75 disambiguation, validated against the candidate set). The agent picks the right one per context.
  2. Existence checkpoint — on the authoritative path, gh issue view <N> before posting (catches nonexistent; does not catch wrong-but-existing — inherent to an explicit override).
  3. Reconsider the membership contract — does fixture 09's "reject override not in single-candidate set" still make sense, or should an explicitly-passed --linked-issue always win?

Out of scope


Source: surfaced during /idd-verify #170 --pr 171 (6-AI ensemble — codex + devil's advocate). Full report: #171 (comment). Sister concern from #170.


Current Status

Phase: closed
Last updated: 2026-07-06 by /idd-verify (via /idd-all batch drain)

Key Decisions

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions