René's URL Explorer Experiment

Title: fix(skill): resolve person_id via `person infos`, not member-list pagination by ysyneu · Pull Request #66 · flashcatcloud/flashduty-cli · GitHub

Open Graph Title: fix(skill): resolve person_id via `person infos`, not member-list pagination by ysyneu · Pull Request #66 · flashcatcloud/flashduty-cli

X Title: fix(skill): resolve person_id via `person infos`, not member-list pagination by ysyneu · Pull Request #66 · flashcatcloud/flashduty-cli

Description: What Schedule/oncall output returns person_ids, not names. This points the agent at the existing batch resolver fduty person infos … (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_id ≠ member_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 == — 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 == ) 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.

Open Graph Description: 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 remo...

X Description: What Schedule/oncall output returns person_ids, not names. This points the agent at the existing batch resolver fduty person infos &lt;person_id&gt; … (POST /person/infos) for that lookup, ...

Opengraph URL: https://github.com/flashcatcloud/flashduty-cli/pull/66

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width