Support issue dependency #21

Closed
opened 2026-05-22 15:17:55 +00:00 by erik · 3 comments
Owner

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 in fjx pm sweep to ignore issues where dependent issues are still open.

While here, add support for a /depends <id1> <id2> ... owner command.

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 in `fjx pm sweep` to ignore issues where dependent issues are still open. While here, add support for a `/depends <id1> <id2> ...` owner command.
erik self-assigned this 2026-05-22 15:17:55 +00:00
Member

Brief — Developer

Phase: simple. Run fjx dev prompt simple for the cycle protocol.

<!-- pm:brief:dev --> # Brief — Developer **Phase:** simple. Run `fjx dev prompt simple` for the cycle protocol.
Member

Ledger for: agent-pm

Status: watching @ 2026-05-26T00:58:27.613Z
Briefs:

  • dev @ 2026-05-25T18:57:50Z
  • qa: absent
  • build: absent

Activity

(none)


(PM manages this ledger; agent section unused)

<!-- agent-pm:ledger --> ## Ledger for: agent-pm Status: watching @ 2026-05-26T00:58:27.613Z Briefs: - [dev](#issuecomment-1963) @ 2026-05-25T18:57:50Z - qa: absent - build: absent ### Activity _(none)_ --- _(PM manages this ledger; agent section unused)_
Member

Ledger for: agent-dev

Status: blocked @ 2026-05-25T21:54:14.698Z


Tasks

  • PM re-route off simple phase to propose.

Notes

The PM routed this as simple, but the issue body asks for three distinct pieces of new behavior, each with design surface:

  1. 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?

  2. fjx pm sweep must 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 in agent/blocked? Cycle detection (A depends on B depends on A)? Cross-repo deps? Behavior when a referenced dep id doesn't exist.

  3. /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, /note family.

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 propose or investigate."

Recommendation: PM re-route to propose so 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:

  1. 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.

  2. Verbatim error from fjx dev done 21:

    No open PR links to issue #21 (looked for Closes #21 / Fixes / Resolves / Refs in open PR bodies). Open the PR with one of those keywords in the body before running fjx dev done.

    rg -n "No open PR links" wiki/ src/ returns no prior occurrence of this symptom in the wiki or issue ledgers I can see.

  3. 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 to propose or investigate." — names the report-and-stop path but doesn't specify the fjx command for it.

  4. Classification: fjx gap. Needs either (a) fjx dev done to support a --no-pr / handback case where status=review without a PR, or (b) a new fjx dev handback (or equivalent) that flips assignee→agent-pm and applies agent/review without 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.

<!-- agent-dev:ledger --> ## Ledger for: agent-dev Status: blocked @ 2026-05-25T21:54:14.698Z --- ### Tasks - [ ] PM re-route off `simple` phase to `propose`. ### Notes The PM routed this as `simple`, but the issue body asks for three distinct pieces of new behavior, each with design surface: 1. **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? 2. **`fjx pm sweep` must 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 in `agent/blocked`? Cycle detection (A depends on B depends on A)? Cross-repo deps? Behavior when a referenced dep id doesn't exist. 3. **`/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`, `/note` family. 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 `propose` or `investigate`."* Recommendation: PM re-route to `propose` so 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: 1. `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. 2. Verbatim error from `fjx dev done 21`: > No open PR links to issue #21 (looked for `Closes #21` / `Fixes` / `Resolves` / `Refs` in open PR bodies). Open the PR with one of those keywords in the body before running `fjx dev done`. `rg -n "No open PR links" wiki/ src/` returns no prior occurrence of this symptom in the wiki or issue ledgers I can see. 3. 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 to `propose` or `investigate`."* — names the report-and-stop path but doesn't specify the fjx command for it. 4. Classification: **fjx gap.** Needs either (a) `fjx dev done` to support a `--no-pr` / handback case where status=review without a PR, or (b) a new `fjx dev handback` (or equivalent) that flips assignee→agent-pm and applies `agent/review` without 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.
erik self-assigned this 2026-05-25 21:58:33 +00:00
erik referenced this issue from a commit 2026-05-26 01:07:38 +00:00
erik closed this issue 2026-05-26 01:07:38 +00:00
Sign in to join this conversation.
No description provided.