chore(harness): automate assignee, board status, and pre-push memory gate in Claude Code workflow

[trinhvandat]

Problem

When Claude Code (CC) is handed a GitHub issue link, it already automates the code side of the loop — creates a feature/<slug> branch, does the work, and opens a PR against develop. But the project-management side is entirely manual, and one safety gate is missing:

1. Assignee is never set. The issue stays unassigned on the GitHub Project board, so at a glance nobody can tell it's being worked on or by whom.
2. No guard against shipping without memory. CC can git push work to the cloud without having run save-memory first. When that happens, the session's durable context (decisions, HANDOFF.md) is lost, or lands in a disconnected follow-up commit instead of travelling with the work.
3. Board status is never advanced. Cards don't move to In Progress when work starts, nor to Ready for Testing when the PR opens — so the board doesn't reflect reality without a human dragging cards.

Proposed changes

1. Auto-set the assignee

• When CC begins working on an issue, assign it (to the acting developer) via gh issue edit <n> --add-assignee <login>.
• Ensure the assignment is reflected on the linked GitHub Project board item.

2. Pre-push "save-memory" gate (hook)

• Add a hook that fires before code is pushed to GitHub (Claude Code PreToolUse on git push, and/or a git pre-push hook as a backstop).
• The hook checks whether save-memory has run for the current session / whether .claude/memory/ changes are staged or committed.
• If memory was not saved, run save-memory first, then include the memory commit in the same push so memory ships together with the work — never as an orphaned afterthought.
• Reuse / extend the existing commit-tracking logic already added for the stop-hook nudge (see conventions/stop-hook-nudge-needs-commit-tracking.md) rather than inventing a second tracking mechanism.

3. Project board status automation

• On work start: move the issue's board card to In Progress.
• On PR opened successfully: move the card to Ready for Testing.
• Implement via gh project item-edit (GraphQL project v2) driven from the same automation that creates the branch / opens the PR.

Acceptance criteria

• Starting work on an issue → card is assigned + moves to In Progress with no manual step.
• git push is blocked (or auto-precedes) when memory hasn't been saved; the memory commit ships with the work.
• Opening the PR → card moves to Ready for Testing automatically.
• Behaviour is documented (CLAUDE.md / .claude/ skill) so it's reproducible across sessions.

Notes / prerequisites

• The local gh token currently lacks the project scope needed for board mutations. Grant it with:

  gh auth refresh -s project,read:project
  

• Confirm the Project (v2) number and the exact status column names (In Progress, Ready for Testing) before wiring the automation, since gh project item-edit needs the field + option IDs.

---

Filed by the supervisor as a Claude Code harness/workflow improvement.

[trinhvandat]

Board wiring reference (ground truth for the automation)

This issue is now on the Digital banking project board (project #3).

Confirmed identifiers the gh project item-edit / GraphQL automation will need:

• Project (v2) ID: PVT_kwDOCetovs4BbdwC (owner Aibles-Java, number 3)
• Status field ID: PVTSSF_lADOCetovs4BbdwCzhWOFe8
• Status option IDs (exact names — note the casing):
  • Todo → f75ad846
  • In progress → 47fc9ee4 ← lowercase "progress"
  • Ready For Testing → a0dc779d ← capital "F"
  • Done → 98236657

⚠️ Status column names are In progress and Ready For Testing, not "In Progress" / "Ready for Testing" as written in the issue body. Use the option IDs above rather than matching on name to avoid casing bugs.

Example to move a card to "In progress":

gh project item-edit --id <ITEM_ID> --project-id PVT_kwDOCetovs4BbdwC \
  --field-id PVTSSF_lADOCetovs4BbdwCzhWOFe8 --single-select-option-id 47fc9ee4

(The --project CLI token scope is required; read:project alone is insufficient for these mutations.)