# State of the Project Brief Template v2

## Purpose

Create one state snapshot that tells Paul and an agent with no prior context where the project cursor is, what is true, what is blocked, and what moves next. This is not a chronological chat summary, forensic audit, or substitute for canonical project sources.

The document has two layers:

1. **Operator brief:** a decision surface that can be scanned in about ninety seconds. Target 900–1,200 words.
2. **Evidence appendix:** the source, verification, conflict, and arithmetic detail required to trust the operator brief. No fixed length.

## Source and authority rules

1. Read the complete source set named by the user. Do not expand beyond it unless the user authorizes local project inspection or a higher instruction explicitly requires source-of-truth verification.
2. Read authority indexes, `README.md`, `AGENTS.md`, `CLAUDE.md`, governance files, and live system state before deciding what is canonical.
3. Recency is not authority. A new report, chat recap, or prior SOTP is secondary synthesis unless corroborated by canonical evidence.
4. If equal-authority sources conflict, report the conflict. Do not silently choose.
5. Separate current project state from historical work. What happened matters only when it changes the current cursor.
6. Never claim an external system is live from documentation alone. Directly verify it or label it `Documented`, `Stale pending check`, or `Unknown`.

## Required metadata

Begin the file with this frontmatter. Replace every bracketed field. Do not leave placeholders in a final brief.

```yaml
---
sotp_schema: "2"
project_id: "[stable-lowercase-project-slug]"
project_name: "[human-readable project name]"
agent: "[ChatGPT|Claude Code|Claude Desktop|Codex|Hermes|other]"
agent_code: "[chatgpt|cc|cd|cdx|hermes|other]"
created_at: "[ISO-8601 UTC timestamp]"
as_of: "[ISO-8601 timestamp or bounded date]"
status: "[complete|in-progress|ready|blocked|deferred|superseded|mixed]"
source_scope: "[thread only|documents only|thread and documents|authorized project inspection]"
supersedes: "[canonical relative path or none]"
---
```

## State vocabulary

Use only these project states:

- `Complete`: stated Done Means conditions are verified.
- `In progress`: execution is active and the next step is available.
- `Ready`: prerequisites are met and execution can begin.
- `Blocked`: a named boundary prevents progress.
- `Deferred`: intentionally postponed by a recorded decision.
- `Superseded`: replaced by a newer authority or implementation.
- `Unknown`: the available evidence cannot establish the state.

Use only these evidence states:

- `Verified live`: checked against the active external or production system.
- `Verified locally`: checked against current local files, tests, or runtime.
- `Documented`: asserted by a source but not independently checked in this run.
- `Stale pending check`: previously verified, but freshness matters and was not rechecked.
- `Inferred`: conclusion supported by named evidence but not directly observed.
- `Unknown`: insufficient evidence.

## Required document structure

Open with one coverage line in this exact form:

`Coverage: [source scope]. Spine: [primary authority]. Freshness: [as-of boundary]. Gaps: [none or concise material limitation].`

### Narrative overview

Write four to seven sentences. State:

- the project’s current condition
- the most consequential verified change since the prior state
- the largest blocker or risk
- the single recommended move
- whether Paul or an agent owns that move

Do not retell the work session. Do not repeat this overview at the end.

### Current cursor

Use one row per material component.

| Component | State | Done Means | What remains | Blocker type | Next action | Owner | Evidence |
|---|---|---|---|---|---|---|---|

Blocker type must be one of: `none`, `Paul decision`, `Paul artifact`, `agent execution`, `external permission`, `credential`, `production approval`, `missing evidence`, or `technical defect`.

### Paul decision queue

Include only decisions that cannot responsibly be made by an agent. For each item state:

- the exact decision
- one recommendation
- consequence of accepting it
- consequence of leaving it unresolved
- which components it blocks

Skip this section when there is no genuine Paul-owned decision.

### Agent execution queue

List the ordered, dependency-aware work an authorized agent can execute now. Each item requires:

- action
- owner or eligible agent
- prerequisite
- observable definition of done
- evidence that should be produced

The first item is the single next action. Do not create a broad backlog or repeat completed work.

Skip this section when no agent-executable work remains.

### Material risks and conflicts

Include only issues capable of changing the plan, state, safety, cost, or completion claim. For each, identify the conflicting sources or evidence, the current handling rule, and the unblock path.

Skip this section when empty.

### Revenue and capability implications

Include only when the source contains genuine commercial evidence, reusable capability evidence, or a bounded validation path.

Run opportunity discovery source-first. Do not load the current offer menu before extracting buyer, payer, problem, evidence, and revenue or capacity mechanism. Judge delivery fit by capability, then compare with the portfolio for proof reuse, speed, credibility gaps, and duplication.

An opportunity survives only when it has:

- an identifiable buyer or beneficiary and payer when applicable
- a specific problem or desired outcome
- a plausible path to money, measurable capacity, or a qualified buyer event
- source evidence or one bounded uncertainty-resolving test
- legal and operational plausibility
- a capability-based delivery path or explicit credibility gap

Allow zero surviving opportunities. Internal tools, skills, and repair work remain `Evidence only` until buyer evidence supports a commercial classification. Do not force content as consolation.

Skip this section when it has no genuine content.

## Evidence appendix

### Delta since prior brief

State what changed, what remained unchanged, what prior claim was corrected, and what evidence caused the change. If no prior brief exists, say `Initial state snapshot`.

### Canonical source ledger

| Claim or decision | Authority | Evidence state | Source and precise pointer | Checked at |
|---|---|---|---|---|

Include every load-bearing claim from the operator brief. Use absolute local paths, stable URLs, page numbers, sections, or line references where available.

### Supersession and conflict ledger

Identify prior SOTPs, reports, plans, and summaries that this brief extends, supersedes, or conflicts with. A newer SOTP does not automatically supersede a higher-authority project source.

Skip this section when empty.

### Source coverage

Report:

- qualifying sources found
- sources read completely
- byte-identical duplicates excluded
- derivative or noncanonical artifacts excluded
- unreadable or inaccessible sources
- boundaries on live-system verification

All counts must reconcile arithmetically.

### Integrity gate

Before delivery, confirm:

- the coverage counts reconcile
- status counts and completion percentages reconcile
- the narrative overview agrees with the component table
- every `Complete` claim satisfies its Done Means condition
- every owner and deadline came from evidence or is explicitly assigned by the current user
- every live-state claim was directly checked
- every unresolved conflict is visible
- the single next action is executable and dependency-correct
- no section repeats the closing recommendation
- no placeholders remain

End the appendix with `Integrity: PASS` or `Integrity: FAIL — [exact unmet condition]`.

## Cross-agent publication protocol

Every completed SOTP must be published as a real UTF-8 Markdown file to the canonical master collection:

- Local macOS path: `/Users/paul/projects-{4,5,6}/[project_id]/`
  Resolution rule: search projects-4, projects-5, and projects-6 (in that order)
  for an existing [project_id] folder and save there. If [project_id] exists in
  none of them, stop and ask which root directory to use — never default to
  projects-4 automatically.
- Dropbox connector path: `/1-full-REFIT-db/_agent-references/state-of-the-project/briefs/[project_id]/`

Filename:

`sotp-[project_id]-[agent_code]_[MMDDYY].md`

If that filename exists, append `-2`, `-3`, and so on. Never overwrite a prior snapshot.

Publication order:

1. Create the user-facing SOTP in the current surface.
2. Publish a byte-identical real Markdown file to the canonical Dropbox folder using the local synced path or authenticated Dropbox connector.
3. Never place a symlink inside the canonical Dropbox collection. Connector-based agents cannot follow local symlinks. A project-local symlink may point to the canonical real file when the local project requires one.
4. Read back the canonical copy and compare exact content or SHA-256 when the surface supports it.
5. Report `Cross-agent sync: VERIFIED` only after readback. Otherwise report `Cross-agent sync: PENDING` with the exact destination and blocker.
6. Do not mirror the canonical Markdown into Google Drive or Airtable as a second source of truth. Airtable may index metadata and links. ChatGPT Library may retain the user-facing copy.

The SOTP is a state snapshot, not behavior authority. Live canonical project sources and directly verified system state outrank it. When a newer brief conflicts with a live source, report the conflict rather than silently adopting the brief.

## Final response

Report only:

- user-facing artifact path or link
- canonical Dropbox path
- cross-agent sync status
- integrity result
- the single next action and owner, only when work remains

## Wrong output

Wrong output includes: a chronological conversation summary; a long audit with no ninety-second decision surface; unsupported completion claims; repeated recommendations; mixed Paul, agent, and external blockers; unreconciled source counts; temporary project state copied into global policy; an opportunity section padded with current-offer variations; a symlink stored inside Dropbox; a second canonical copy in Drive or Airtable; a claimed sync without readback; or a brief that leaves the next agent unable to identify the exact cursor.