fix(agent): preserve staged assign assignees

[JSONbored]

Motivation

• An assign action staged as auto_with_approval lost its target login because the approval-queue serialization omitted assignee, so accept-time replay reconstructed an assign with no assignee and the executor no-oped while still recording the action as completed.

Description

• Include assignee when serializing a PlannedAgentAction in actionParams() so staged assign actions persist the target login.
• Add assignee?: string to AgentPendingActionParams to match the persisted payload shape.
• Add regression unit tests that verify an assign action round-trips through actionParams() → DB params → pendingActionToPlanned() and preserves assignee.

Testing

• Ran focused unit tests for the modified paths: test/unit/agent-action-executor.test.ts (assign round-trip) and test/unit/agent-approval-queue.test.ts (params/replay coverage), and the targeted tests passed.
• Type checking (tsc --noEmit) completed successfully.
• A full npm run test:coverage run was started but did not complete in the available session time; focused unit runs were used as regression validation for this targeted fix.

---

Codex Task

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[loopover-orb]

Tip

🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

✅ Gittensory review result - approve/merge recommended

_{Review updated: 2026-07-05 07:25:55 UTC}

4 files · 1 AI reviewer · no blockers · readiness 93/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
The change fixes the stated staged-assign replay bug at the right layer: `actionParams()` now persists `assignee`, `AgentPendingActionParams` admits the persisted shape, and the replay tests cover `actionParams()` -> params -> `pendingActionToPlanned()` for assign. This is a narrow serialization parity fix with no visible schema or migration requirement because the params payload is already the generic pending-action parameter object. I do not see a blocker in the provided diff.

Nits — 3 non-blocking

• nit: `test/unit/agent-approval-queue.test.ts:1233` adds the positive replay case, but it would be useful to keep one nearby assertion for an assign action with empty params so the accepted-action no-op behavior stays explicit rather than accidental.
• At `test/unit/agent-approval-queue.test.ts:1233`, add a small negative/default-shape assertion for `{ actionClass: "assign", params: {} }` if the intended executor behavior is still to no-op when no assignee was staged.
• At `src/types.ts:1055`, the comment is helpful; keep the field colocated with the other replay-only payload fields as you did so future staged-action additions follow the same serialization contract.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (no linked issue context).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 56 registered-repo PR(s), 46 merged, 416 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 56 PR(s), 416 issue(s).
Gate result	✅ Passing	No configured blocker found.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository registration is not available in the local Gittensory cache.
• Public profile languages: not available
• Official Gittensor activity: 56 PR(s), 416 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Explain no-issue PR.
• No action.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.46%. Comparing base (abe34a7) to head (0b99c05).
⚠️ Report is 19 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3448   +/-   ##
=======================================
  Coverage   93.46%   93.46%           
=======================================
  Files         291      291           
  Lines       30790    30791    +1     
  Branches    11221    11222    +1     
=======================================
+ Hits        28779    28780    +1     
  Misses       1355     1355           
  Partials      656      656           

Files with missing lines	Coverage Δ
src/services/agent-action-executor.ts	96.80% <100.00%> (+0.01%)	⬆️

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[loopover-orb]

Gittensory approves — the gate is satisfied and CI is green.