Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/xxyoudeadpunkxx/gpt-pf-chat-gpt-project-forge/llms.txt

Use this file to discover all available pages before exploring further.

HANDOFF_ARTIFACT is the operational-continuity artifact. It exists to carry forward the operational state of a run when that state cannot be safely reconstructed from the canonical core and stable artifacts alone. It is intentionally temporary: valid only for the immediately following run, not normative, and never promotable to canonical or SSOT. The handoff artifact is a bridge between two specific runs — not a standing authority, not a record, and not a default surface.
Do not emit HANDOFF_ARTIFACT unless the criteria explicitly close HANDOFF_REQUIRED. Default handoff is an anti-pattern. It produces stale continuity, duplicates state that already lives in stable surfaces, and creates operational noise that makes reopening harder rather than easier.

​
Artifact Properties

PropertyValue
PurposeTransfer operational continuity across runs without redefining frame or SSOT
AuthorityLocal and temporary only; not normative
SurfaceOperational-continuity artifact
Write TriggerOnly when 02_PROTOCOL.md closes HANDOFF_REQUIRED
Read TriggerWhen reopening the immediately following run
Freshness RuleValid only for the immediately following run unless explicitly renewed
Promotion ConditionsNEVER promotable to canonical or SSOT

​
Schema Fields

​
current_state
list
required
A description of the operational state at the close of the current run. What has been established, what decisions are closed, where the work stands. This field should capture only what the next run genuinely needs to avoid reconstructing — not a full project summary, not a log of everything that happened.
​
recent_tests
list
required
Tests, checks, or validations completed in the current run that are directly relevant to the next run’s starting point. If no tests were run, record that explicitly. Do not invent tests or aggregate tests from prior runs — this field is current-run only.
​
open_points
list
required
Items that are unresolved at the close of the current run and must be addressed in the next run. Each open point should be specific enough that the next run can decide what to do with it. Vague open points are not useful — they just move ambiguity forward.
​
next_move
string
required
The specific action the next run should take first. A single, clear statement of what must happen at the start of the following session. This is not a plan for the whole project — it is the first move only.

​
The Three Handoff Criteria

02_PROTOCOL.md governs when handoff is required, forbidden, or not required. The decision must be closed explicitly before any handoff artifact is emitted.
1

HANDOFF_REQUIRED

Use this only when the next run would depend on state, tests, decisions, or materials that cannot be reconstructed reliably from the canonicals and already-stable artifacts alone. The test is strict: if the stable surfaces are sufficient, handoff is not required.
2

HANDOFF_FORBIDDEN

Use this when the material that would need to travel is DO_NOT_STORE, or when it would redefine frame, redefine SSOT, or redefine canonicals. Material that cannot safely persist in any surface must not enter a handoff artifact as a side channel.
3

HANDOFF_NOT_REQUIRED

Use this when the canonicals and stable artifacts are already sufficient to reopen the work without material operational loss. This is the most common outcome for well-structured openings.

​
What the Handoff May and May Not Do

The handoff may:
  • Describe current operational state at run close
  • Transfer recent test results relevant to the next run
  • Surface open points that must be addressed in the next run
  • Specify the first move for the next run
The handoff may not:
  • Redefine project frame or project objective
  • Redefine official basis
  • Override the project brief
  • Persist as standing authority beyond the immediately following run
  • Carry DO_NOT_STORE material
  • Act as a substitute SSOT or hidden canonical

​
Why Handoff Is Not Emitted by Default

Many systems produce handoff artifacts on every run because it feels like a safe, responsible practice. In Project Forge, this is explicitly an anti-pattern. Unnecessary handoff creates:
  • Stale continuity — a handoff from run N that is carried into run N+2 carries state that may no longer reflect the project’s actual position
  • Duplicated state — if the canonicals and stable artifacts already carry the information, the handoff is redundant noise
  • Operator confusion — when a handoff always exists, it becomes invisible; when it exists only when required, its presence is a meaningful signal
  • Side-channel governance — repeated handoff can accumulate implicit structure that the canonical core never authorized
The correct default is: no handoff unless HANDOFF_REQUIRED is closed. The presence of a handoff artifact is a signal that something genuinely could not be reconstructed from stable surfaces alone.

​
Template

Use this template to instantiate HANDOFF_ARTIFACT. Fill only the fields that represent genuine continuity the next run needs. If a field has nothing to report, say so explicitly rather than writing TBD — a clean record of nothing-to-report is more useful than ambiguity. 
# HANDOFF_ARTIFACT

## current_state
- TBD

## recent_tests
- TBD

## open_points
- TBD

## next_move
TBD
Handoff content is by definition run-specific and temporary. The current_state, recent_tests, open_points, and next_move fields capture a snapshot of one run’s close — not stable, normative, non-case-specific information. Promotion to canonical or SSOT requires material that is stabilized, normative, and non-case-specific. Handoff content satisfies none of those conditions. Allowing promotion from handoff would create a side channel through which transient run state could silently enter the canonical core — exactly the kind of contamination the system is designed to prevent.

Build docs developers (and LLMs) love

Get started for freeTalk to us