Original FPAT reconstruction

Purpose: Reconstruct the attached nine-card FPAT workflow before simplification and make every retained or removed mechanism traceable.

Intended reader: Maintainers evaluating whether FPAT Lite preserved the important governance.

Consult this when: Comparing FPAT Lite with the original diagrams or considering a governance extension.

Evidence boundary#

The observations below come from the supplied session-entry, decomposition, continuation-planning, execution-pipeline, implementation, board-automation, gate-enforcement, audit-sweep, and handoff diagrams plus the supplied FPAT framework report and visual HTML/CSS.

The diagrams define a concrete GitHub-centric operating model. The conclusion that some mechanisms are excessive for a solo developer is a design judgment, not an assertion that those mechanisms are incorrect.

System purpose#

Original FPAT—Flow-Pack Agent-Team—is a governed delivery system for coding agents:

read-only entry
→ scored planning
→ fixed issue decomposition
→ approval-gated GitHub writes
→ branch / PR / checks / merge
→ board synchronization
→ parent-close enforcement
→ scheduled invariant audit
→ resumable handoff
→ evidence-gated release

Its primary optimization is control and traceability across a GitHub issue tree, not minimal setup.

Actors#

Critic and research are workflow roles; the diagrams do not require that they be separate autonomous agents.

Workflow-by-workflow reconstruction#

1. Session entry — /fpat-prime#

Useful invariant: context and live state precede action.

2. Decomposition — phased issue tree#

Useful invariant: executable work is small and independently verifiable. Excessive default: every epic has exactly five children and every goal needs umbrella/foundation/parallel/release structure.

3. Continuation planning — V1 to V2#

Useful invariants: critique before commitment, research material uncertainty, and separate planning from mutation. Simplification opportunity: fixed scoring dimensions and thresholds are disproportionate for many small changes.

4. Execution pipeline — issue to five subtasks#

Useful invariant: present a complete mutation package before a remote write. Excessive default: exactly five tasks regardless of natural work shape.

5. Implementation — branch to PR to merge#

Useful invariants: one coherent delivery unit, real validation, intentional closure link, and bottom-up progress. Optional details: named third-party checks, mandatory labels/milestones, and fixed merge strategy.

6. Board automation — labels to fields#

Useful only when a team relies on GitHub Projects v2 as an operational board. It introduces token, GraphQL, field-schema, and maintenance overhead.

7. Gate enforcement — rollup gate#

Useful invariant: a parent cannot represent completion while descendants remain open. Optional mechanism: automatic reopen/comment workflow.

8. Audit sweep — blocked sweep#

Useful for a large persistent board. Disproportionate as a mandatory weekly workflow for a small repository.

9. Handoff — session checkpoint#

Useful invariant: continuity is explicit and evidence-backed. Simplification: one stable .fpat/handoff.md works across agents and avoids platform ownership.

10. Release layer from the report#

The supplied framework report adds a release condition: dogfood the whole system and close the umbrella only after evidence exists. This is consistent with the rollup and validation gates, although the nine cards emphasize the preceding mechanisms rather than a separate release card.

Decision points#

1. Are baseline assets missing or conflicting?
2. Which plan candidates survive critique and research?
3. Which score band receives each candidate?
4. Does decomposition need revision before approval?
5. Did local lint/build gates pass?
6. Did all PR checks pass?
7. Does a parent have open children?
8. Do board items violate phase, score, or blocked invariants?
9. Is an expected board field missing or renamed?
10. Is the session planning, applying, blocked, or ready?
11. Has the user approved each pending external mutation?
12. Does release evidence justify top-level closure?

Mutation inventory#

The audit sweep and prime workflow are deliberately read-only.

Validation gates#

• Baseline passes before any write.
• V2 plan is approved before GitHub planning writes.
• Task package is approved before sub-issues are created.
• Lint and build pass before commit.
• All PR checks pass before merge.
• All children close before a parent remains closed.
• Board invariants are audited and reported.
• Release requires end-to-end evidence.

Sources of truth and artifacts#

Dependencies between stages#

Foundation closes
→ parallel epics unlock
→ all parallel epics close
→ release epic unlocks
→ all release children close
→ release epic closes
→ umbrella can close

At the work-unit level:

approved plan
→ approved sub-issue
→ branch
→ local checks
→ PR
→ external checks
→ merge
→ child closes
→ parent progress rolls up

Simplification classification#

KEEP#

• Read-only baseline before action.
• Instruction and repository inspection before editing.
• Known facts separated from assumptions.
• Brainstorming that includes a simple option.
• Focused research of material uncertainty.
• Proportionate plan with scope, non-goals, acceptance criteria, risks, and validation.
• Small independently verifiable work units.
• Critique for scope creep and weak evidence.
• Explicit remote-mutation approval.
• Local validation and final diff review.
• Honest passed / failed / skipped / unavailable results.
• Resumable handoff with exact next action.

SIMPLIFY#

MAKE OPTIONAL#

• GitHub issues as task storage.
• Branch and pull-request templates.
• Conventional commits and squash merge.
• Project v2 boards.
• Label-to-field synchronization.
• Parent rollup enforcement.
• Scheduled blocked-item or invariant audits.
• External code-review and security services.
• CI that runs FPAT Lite self-validation.
• Formal decision records for durable architectural choices.

REMOVE FROM THE CORE#

• Mandatory umbrella/foundation/parallel/release hierarchy.
• Mandatory exactly-five decomposition.
• Fixed score bands and promotion thresholds.
• Required personal access tokens and dual-token architecture.
• Required Project fields, label taxonomy, or hardcoded workflow names.
• Automatic board writes, issue creation, closure, reopening, or comments.
• Mandatory weekly cron.
• Named third-party checks.
• Multi-agent roles created only for appearance.
• Dashboards, databases, services, and custom orchestration.

Resulting invariant#

FPAT Lite preserves the control loop:

context → choice → evidence-backed plan → scoped change → executed evidence → resume

It removes the assumption that this loop must be represented by a large GitHub issue tree and board automation.