Support issue dependency #21
Labels
No labels
agent
blocked
agent
new
agent
review
agent
working
complexity
high
complexity
low
priority
high
priority
low
priority
medium
risk
high
risk
low
risk
medium
type
bug
type
chore
type
feature
type
security
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
tfks/fjx#21
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
We need the PM to understand issue dependencies so that it doesn't delegate work to an issue that is not yet ready. As a first cut, add
Depends: <id1> <id2> ...as fjx-managed metadata for agent-pm's ledger. Add support infjx pm sweepto ignore issues where dependent issues are still open.While here, add support for a
/depends <id1> <id2> ...owner command.Brief — Developer
Phase: simple. Run
fjx dev prompt simplefor the cycle protocol.Ledger for: agent-pm
Status: watching @ 2026-05-26T00:58:27.613Z
Briefs:
Activity
(none)
(PM manages this ledger; agent section unused)
Ledger for: agent-dev
Status: blocked @ 2026-05-25T21:54:14.698Z
Tasks
simplephase topropose.Notes
The PM routed this as
simple, but the issue body asks for three distinct pieces of new behavior, each with design surface:New fjx-managed metadata
Depends: <id1> <id2> ...in agent-pm's ledger. Open questions: where in the ledger structure does it live (top-level header field, dedicated section, free-form)? Is it edited only by fjx, or also writable by owner prose? How are removed/closed deps reflected — does fjx prune them, or is the list canonical until rewritten?fjx pm sweepmust filter out issues whose deps are still open. Open questions: does "open" mean Forgejo state=open, or "not yet closed by PM"? What about deps inagent/blocked? Cycle detection (A depends on B depends on A)? Cross-repo deps? Behavior when a referenced dep id doesn't exist./depends <id1> <id2> ...owner command. This adds a new entry to the command parser (src/pm/parse.ts) and the planner (src/pm/plan.ts), with its own activity key, label/brief side effects (or none), and ledger write. Belongs alongside the existing/spec-approved,/block,/notefamily.None of these is a typo-class change. The simple-phase brief explicitly says: "If during the work you discover the change isn't actually simple (touches more than the issue named, surfaces a design question, needs a new abstraction), stop and report it in the ledger rather than expanding scope — PM will re-route to
proposeorinvestigate."Recommendation: PM re-route to
proposeso a spec can pin down the three sub-decisions above before code lands.Blocker
There is no fjx-surface command to hand a phase-mismatched issue back to PM without a PR. Four-check evidence:
fjx dev done --help: "Mark an issue's work ready for review: transition the issue to agent/review, assign the issue to agent-pm for routing, and assign the linked PR to $FJX_OWNER." — assumes a PR exists.Verbatim error from
fjx dev done 21:rg -n "No open PR links" wiki/ src/returns no prior occurrence of this symptom in the wiki or issue ledgers I can see.Phase prompt re-read (
fjx dev prompt simple): "If during the work you discover the change isn't actually simple ... stop and report it in the ledger rather than expanding scope — PM will re-route toproposeorinvestigate." — names the report-and-stop path but doesn't specify the fjx command for it.Classification: fjx gap. Needs either (a)
fjx dev doneto support a--no-pr/ handback case where status=review without a PR, or (b) a newfjx dev handback(or equivalent) that flips assignee→agent-pm and appliesagent/reviewwithout requiring a PR.Smallest concrete unblock: PM manually reassigns this issue to agent-pm and refreshes the brief to
propose. Going forward, the gap above should be filed as its own issue.No commits, no branch, no PR. Worktree is clean.