IntentGuard

FPAT Lite architecture

Operational governanceknowledgefpat

Purpose: Define components, responsibilities, sources of truth, and boundaries.

Intended reader: Maintainers and agents planning an adaptation.

Consult this when: Deciding where new guidance belongs or whether an extension is justified.

System in one view#

flowchart TD
    U["User request"] --> D["Agent discovery<br/>AGENTS.md or CLAUDE.md"]
    D --> S["Native fpat-lite skill"]
    S --> C["One shared command contract"]
    C --> R["Shared rules"]
    C --> T["Template, only if needed"]
    C --> W["Repository work"]
    W --> E["Executed evidence"]
    E --> H["Handoff, when needed"]

No server, database, daemon, model provider, or GitHub Project is part of the core.

Components#

ComponentResponsibilityConsumerLoad behavior
AGENTS.mdCodex discovery, common objective, routingCodex and humansStartup
CLAUDE.mdImport shared instructions and add Claude-specific routingClaude CodeStartup
.agents/skills/fpat-lite/Codex-native reusable workflow entryCodexMetadata first, body on use
.claude/skills/fpat-lite/Claude-native /fpat-lite entryClaude CodeMetadata first, body on use
commands/Six model-independent operating contractsAny agent or humanOne file per mode
rules/Stable safety and engineering invariantsAll modesCore subset before work
templates/Shapes for persistent artifactsHumans and agentsOnly when saving
knowledge-base/Rationale, research, troubleshootingMaintainers and agentsOn demand
scripts/Deterministic structure/content/package checksMaintainers and CIExplicit
extensions/Optional GitHub conveniencesTeams that choose themNever required

Sources of truth#

FPAT Lite uses several narrow sources rather than one giant master prompt:

QuestionSource of truth
What behavior is requested?Current user request
What repository rules apply?Active agent instruction chain
How should this mode run?commands/<mode>.md
What safety invariant applies?rules/
What is the current code state?Repository files and Git state
What was approved?Current conversation and saved plan
What actually passed?Current command output
How should a later session resume?.fpat/handoff.md, rechecked by prime

A plan or handoff is a checkpoint, not unquestionable truth. A new session must compare it with live repository and remote state.

Mutation boundary#

flowchart LR
    A["Inspect"] --> B["Plan"]
    B --> C["Local edit<br/>requested"]
    C --> D["Local validation"]
    D --> E{"Remote action<br/>needed?"}
    E -- "No" --> F["Report or handoff"]
    E -- "Yes" --> G["Exact approval"]
    G --> H["One scoped remote action"]

Planning never implies implementation. Local implementation never implies commit or push. Preparing a PR description never implies creating the PR.

Artifact model#

Use stable, overwrite-in-place working files:

.fpat/request.md
.fpat/brainstorm.md
.fpat/plan.md
.fpat/validation.md
.fpat/handoff.md

Git history, when available, preserves evolution. Stable names make discovery and resume predictable. Tiny tasks may need none of these files.

Extension test#

Add a new component only when all are true:

  1. It solves a repeated observed problem.
  2. A command, rule, or existing repository tool cannot solve it simply.
  3. Its consumer and source of truth are clear.
  4. It has a validation and removal path.
  5. Core operation remains possible without it.

Related in repository

Open in full graph →
LINKS_TOLINKS_TO — source: knowledge-base/README.mdCURRENTdocument: FPAT Lite architectureFPAT Lite knowledge basedocument: FPAT Lite knowledge base
Hover an edge for its provenance · click a node to open it2 nodes · 1 edges