Skip to content

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

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

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

@ysyneu ysyneu 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 who Long 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 (run audit-2026-06-26)

  • sess_8fKpUejeyKfHt2hx5XNSsc (steps 14–46): 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.
  • sess_UtK6eDMFY4TVZCSAj64gKF (steps 10–58): same pattern, 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.

Surfaced by /audit-ai-sre-sessions.

…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.
Sign up for free to 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