Skip to content

feat(pipeline): order active stages by the WSJF judgement Facility already records - #176

Open
vicente-debug wants to merge 1 commit into
theam:mainfrom
vicente-debug:feat/109-order-backlog-by-wsjf
Open

feat(pipeline): order active stages by the WSJF judgement Facility already records#176
vicente-debug wants to merge 1 commit into
theam:mainfrom
vicente-debug:feat/109-order-backlog-by-wsjf

Conversation

@vicente-debug

Copy link
Copy Markdown

Closes #109.

What this does

The board no longer sorts active stages by gh_updated_at. It sorts them by the WSJF judgement Facility already records — and then threw away. The issue's own framing ("Facility forms an opinion about priority, and then throws it away") is the design: this PR adds no new opinion, it consumes the existing one.

  • assemblePipelineStories reads the ## Value section back out of the mirrored issue body (gh_issues.body_md) and scores it with the existing wsjfScore — the first caller either exported function has had outside its unit test.
  • Active stages sort scored stories first, highest score on top. Unscored stories sit below, in GitHub's own newest-created-first order. Shipped keeps recency: it is a log of what left the pipeline, not a queue, and "most recently shipped on top" is the honest order there.
  • The score and its components ride PipelineStorySchema and StoryDetailSchema, and the board renders a wsjf 3.75 chip whose tooltip is the breakdown (value 8 · time 5 · risk 2 · effort 4) — the position is inspectable, not merely asserted.
  • The serialisation the PO-task executor used to build inline moves into @facility/harness (wsjfValueSection) next to its new inverse (parseWsjfValueSection), so the round trip through the GitHub mirror is pinned by one pair of functions and one pair of tests.

Where the score lives — the first open question, answered

In the issue body on GitHub, where executeTaskCreation already writes it. That choice does the most work per line of code:

  • No second source of truth. #101's reasoning about assignees applies verbatim: a Facility-native priority field would have no writer, no sync path and no reconciliation story. The body block has all three today — written on task acceptance, mirrored on every webhook and sync, echoed back within seconds of an edit.
  • The human override falls out for free, with a record. Editing the JSON block on GitHub is an attributed, timestamped issue edit — it lands in the issue history and in Facility's mirror without any new machinery. That is "an override is a decision with a reason, in the record", minus a bespoke approvals flow.
  • Hand-opened issues can opt in by adding the same ## Value block the PO agent writes. Without one they are simply unscored, which is handled explicitly, not accidentally: always below scored stories, in stable creation order, with the chip's absence marking the boundary.

Malformed blocks (bad JSON, missing components, effort <= 0, a fence that actually belongs to the next section) parse to unscored, never to an error — the majority of issues are hand-written, and a parser that can be angered by prose would be a liability.

What good looks like, checked against the issue

  • "Priority survives an issue being touched." Nothing in the active-stage comparator reads gh_updated_at any more. Triggering an agent — the acknowledgement comment plus the Show the signed-in GitHub user, and assign them on the issue and the PR #70 self-assignment that made the board reorder in response to your own actions — now moves nothing.
  • "The judgement is inspectable." The chip and its breakdown, plus the block itself in the story body.
  • "Unscored stories are handled explicitly." Deliberately below scored ones, newest-created first; tested.
  • "Re-scoring is visible when it happens." A re-score is an issue edit: it shows up in the issue history, the timeline's issue_updated, and the mirror — not as a silent overnight rearrangement.

Deliberately left open

The issue's larger questions — PO re-scoring cadence, decay, whether a re-prioritisation must pass through Approvals, effort informed by measured run cost, the #110 dependency graph — are policy, and the issue itself says the design belongs to whoever implements it. This PR keeps the mechanism small enough that any of those answers can be built on top of it: they all reduce to "who is allowed to edit the ## Value block, and when", because after this change the block is finally load-bearing.

Tests

  • packages/harness: round-trip through wsjfValueSection/parseWsjfValueSection, plus the malformed-body taxonomy.
  • services/api: a pipeline test where a stale scored story outranks a freshly-commented scored one, unscored stories keep creation order despite activity bumps, and a malformed block lands unscored — end-to-end through assemblePipelineStoriesclassifyPipeline.
  • OpenAPI + SDK regenerated (pnpm --filter @facility/api openapi); full typecheck and the harness/api/web suites pass locally. The one local failure, ai-identity.test.ts's vendor-asset hash, fails identically on a pristine main under a Windows CRLF checkout and is what fix: several Windows-checkout issues found while running the platform's own checks locally #173 is about.

🤖 Generated with Claude Code

https://claude.ai/code/session_018XarNuJCzYsJupYqMDUvaG

…ready records

The Stories board sorted every stage by gh_updated_at, so any webhook — a
comment, a label, Facility's own acknowledgement — reordered the board, and
the WSJF scores the PO agent writes into the issue body were never read back.

Read the ## Value section out of the mirrored issue body at assembly time,
score it with the existing wsjfScore, and sort active stages by that
judgement: scored stories first, highest score on top, unscored stories
below in GitHub's own newest-created-first order. Shipped keeps recency —
it is a log, not a queue. The score and its components ride the pipeline
and story-detail responses, and the board renders them so the ordering is
inspectable.

The serialisation moves into @facility/harness next to the parser, so the
round trip through the GitHub mirror is pinned by one pair of functions.

Closes theam#109

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018XarNuJCzYsJupYqMDUvaG
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Order the backlog by priority, not by last activity

1 participant