Skip to content

fix(skill): resolve person_id via person infos, not member-list pagination - #66

Closed
ysyneu wants to merge 1 commit into
feat/ai-srefrom
audit-fix/2026-06-26-member-by-id
Closed

fix(skill): resolve person_id via person infos, not member-list pagination#66
ysyneu wants to merge 1 commit into
feat/ai-srefrom
audit-fix/2026-06-26-member-by-id

Conversation

@ysyneu

@ysyneuysyneu commented Jun 26, 2026

Copy link
Copy Markdown
Contributor

What

Schedule/oncall output returns person_ids, not names. This points the agent at the existing batch resolver fduty person infos <person_id> … (POST /person/infos) for that lookup, and removes the guidance that sent it down the wrong path.

  • schedule.md — replace the "join fduty member list on member_id" flow with a one-shot fduty person infos call; add a person_idmember_id warning.
  • member.md — cross-reference the person group from member (the agent looked under member, never found person infos); add a person_id resolution gotcha.
  • oncall.go — correct the oncall whoLong help, which falsely claimed "member list has no by-id lookup" and recommended dumping the roster (the command's table output already resolves names inline).

Root cause

The batch resolver already exists; this was a discoverability + namespace-confusion bug, not a missing endpoint. person_id (returned by schedule/oncall/incident/alert) is a different namespace from member_id (returned by member list). The schedule.md card and the oncall who help told agents to resolve names by paginating fduty member list and matching member_id == <person_id> — wrong join key, and a 20+ page full-roster scan that silently drops people on later pages.

Evidence

  • An agent paginated member list pages 1–22 matching member_id against schedule person_ids, tried a non-existent fduty member get --id, and missed a person who lived on page 21.
  • The same pattern recurred following the schedule.md card's select(.member_id == <person_id>) advice literally.

Verification

$ env -u GOROOT go build ./... # clean
$ env -u GOROOT go run ./internal/cmd/skilldoc check
skilldoc: cards OK
$ env -u GOROOT go test ./...
ok github.com/flashcatcloud/flashduty-cli/cmd/flashduty
ok github.com/flashcatcloud/flashduty-cli/internal/cli
ok github.com/flashcatcloud/flashduty-cli/internal/cmd/cligen
ok github.com/flashcatcloud/flashduty-cli/internal/cmd/skilldoc
ok github.com/flashcatcloud/flashduty-cli/internal/config
ok github.com/flashcatcloud/flashduty-cli/internal/output
ok github.com/flashcatcloud/flashduty-cli/internal/skilldoc
ok github.com/flashcatcloud/flashduty-cli/internal/timeutil
ok github.com/flashcatcloud/flashduty-cli/internal/update

Skill-card edits are outside the GENERATED: fences, so skilldoc check stays green without a regen.

…ination
Schedule/oncall output returns `person_id`s — a different id namespace from
`member_id`. The schedule.md card and the `oncall who` help told agents to
resolve names by joining `fduty member list` on `member_id`: wrong namespace,
and it forces a full-roster scan that silently drops people on later pages.
In prod this produced a confidently-incomplete on-call answer (a responder on
page 21 of 22 was missed).
The batch resolver already exists: `fduty person infos <person_id> ...`
(POST /person/infos) returns person_id + person_name in one call. Point the
cards and the oncall help at it, and warn that person_id != member_id.
- schedule.md: replace the member_id-join flow with `person infos`
- member.md: cross-reference `person infos`; add a person_id gotcha
- oncall.go: correct the `oncall who` Long help (table already enriches names;
use `person infos` for raw ids elsewhere)
Surfaced by /audit-ai-sre-sessions (run audit-2026-06-26):
sess_8fKpUejeyKfHt2hx5XNSsc, sess_UtK6eDMFY4TVZCSAj64gKF.
@ysyneu

Copy link
Copy Markdown
ContributorAuthor

Superseded by #75, which merged the patch-equivalent CLI changes into main and was released as v1.3.22. Closing this stale feat/ai-sre-targeted PR to avoid re-merging its older integration-branch base.

@ysyneuysyneu closed this Jul 2, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

@ysyneu