Maintain authoritative project state across AI agent sessions

Project State Governor is a skill that maintains a project's durable, evidence-backed state so an agent entering a fresh conversation can quickly tell why the project exists, what's currently authoritative, what's active, blocked, deferred, or done, what failed and shouldn't be repeated, and what should happen next. It acts strictly as a state-and-documentation governor, not as product owner, coding agent, research executor, or release approver. Conversation history is treated as working context, never authoritative memory; AGENTS.md defines how agents operate, and one canonical project-state system - not necessarily one file - is the single source of truth that sits alongside Git's commit history.

Use it when resuming a substantial project after a conversation, agent, or branch change; when plans, status files, reviews, tests, and implementation evidence disagree with each other; when a completion claim needs verification before it becomes durable state; when an expensive negative result or recurring lesson needs to survive future sessions; or when fragmented project documentation needs bounded consolidation. It is not a substitute for implementation, domain research, product ownership, or release approval, and it cannot resolve undefined business intent or choose among legitimate owner decisions on its own - those get escalated as the smallest unresolved decision rather than decided autonomously.

It enforces a nine-level authority hierarchy when sources conflict: an explicit owner decision outranks approved requirements, which outrank formal contracts and schemas, which outrank traceable tests, verified implementation behavior, canonical state records, historical documentation, historical review reports, and finally historical AI conversation or suggestions - none of which may silently override a higher-authority source. Facts are classified into a fixed taxonomy (mission, success criterion, workstream, milestone, task, research hypothesis, decision, constraint, blocker, deferred item, question, lesson) and tagged CONFIRMED, INFERRED, or UNKNOWN by how well-supported they are; an INFERRED fact is never persisted as settled. Completion is hierarchical - a session, task, milestone, workstream, and mission each have their own definition of done, and a child's completion never implies the parent is done - and a completion claim only becomes durable state once the required evidence is actually verified, exactly like the skill's worked example: a branch claiming a feature is finished stays ACTIVE until its required integration test actually runs, with the missing evidence recorded rather than assumed away.

State lives in either a compact form (AGENTS.md plus PROJECT_STATE.md) or, once a project outgrows that, a scaled form (.project/MANIFEST.md, STATE.md, DECISIONS.md, CONSTRAINTS.md, NEGATIVE_EVIDENCE.md, and per-subsystem area files). Writes follow a RECALL -> PROPOSE -> VERIFY -> APPLY -> CONSOLIDATE lifecycle, with owner review required before redefining the mission, deleting documentation of uncertain value, running broad cleanup, or accepting release, security, or legal risk. It coordinates with, rather than duplicates, engineering and research governors: it consumes their verified findings as evidence instead of re-deriving defect classification or experiment results itself.

Teams running long-lived, multi-session AI-agent projects who need project memory that survives context resets and hand-offs between agents or branches, without letting an unverified completion claim, a stale status file, or a raw conversation transcript quietly become the truth the next session inherits.