Project Forge operates through a fixed, ordered procedure defined inDocumentation 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.
02_PROTOCOL.md. Every preparation session follows the same ten steps, in the same sequence. The steps are not a checklist to skim — each one closes something that the next step depends on. Skipping a step is only acceptable when it would not change the target, authority, readiness state, or required outputs. In practice, skipping is rarely safe in the early steps. The standard flow is what keeps chat momentum from substituting for actual preparation work.
The Three System Layers
Before the flow makes sense, it helps to know what the system is built from. The canonical core consists of four files that govern everything:00_SCOPE.md defines system identity and scope; 01_RULES.md defines criteria, authority, stability, and residence; 03_ARTIFACTS.md defines artifact grammar and classes; 02_PROTOCOL.md defines the working procedure. No lower surface may redefine a higher one. The canonical core never holds live case state.
Support surfaces include AI_START.md for AI session routing, the operator guide for human operating rhythm, the artifact templates, and the web compiler. These help you operate the system but carry no authority of their own.
Operational artifact surfaces are the project-specific outputs: the entry point, target brief, initial SSOT, optional handoff, and optional source transfer artifact. These carry case state. They are the outputs of a preparation session, not part of the canonical core.
The Standard Flow
Close the intake object
The first move is to close what is actually being prepared. This means naming: what target project is being opened, what opening decision is being made right now, what materials are already present, what remains external or unavailable, and what runtime constraints apply to this session.This step is more demanding than it sounds. “I want to open a project about X” is not a closed intake object. A closed intake object is a specific, nameable project decision with a known output and a defined set of available inputs. If the real object cannot be closed here, the protocol stops. Everything downstream depends on this being settled.
Close the target
Once the intake object is closed, close the target in three dimensions:
- Objective — what the target project is for and what it must produce
- Scope in — what is explicitly included
- Scope out — what is explicitly excluded
NOT_READY. That is the correct and honest state. It is not a failure. It is the system working as designed.Target closure is also a safeguard: if what you believe the target to be changes materially during preparation, earlier work may need to be revisited. The flow does not assume the target is fixed — it forces you to close it explicitly so you know what you are committed to.Close the required outputs
With the target closed, close what the opening package must contain:
- Which project-opening artifacts are required
- Whether handoff evaluation is needed
- What the target project must receive to start correctly
NOT_READY. This step prevents the common failure of generating artifacts before knowing what the target project actually needs. Not every project requires a handoff artifact. Not every project needs a source transfer artifact. Closing outputs before compiling them keeps the package focused.Classify stability
For each meaningful unit of information present in the session — a source, a constraint, a stated objective, a design decision — classify it as either
PERSISTENT or VOLATILE.PERSISTENT material is stable enough to live in a durable artifact. VOLATILE material is session-specific, temporary, or not yet settled enough to be stored reliably.This classification must happen before residence is assigned. The order is intentional and strict: stability first, then residence. Reversing the order is one of the most common ways to let informal material become hidden project authority.Assign residence
Apply the allowed stability-to-residence mapping from
Forbidden combinations are rejected. When tension exists between valid options, the system chooses the most conservative valid residence. In normal use, most case-specific material belongs in
01_RULES.md. Each classified information unit is assigned to one of four residence classes:| Residence | Use |
|---|---|
CANONICAL | Stable, governing rules — never holds case-specific state |
EXTERNAL_ARTIFACT | Project-specific content in an authorized artifact file |
RUNTIME_OPERATOR_INPUT | Operator-provided context active only for this session |
DO_NOT_STORE | Temporary reasoning, unsafe fragments, or session-only residue |
EXTERNAL_ARTIFACT — that is a feature, not a limitation. If a forbidden combination is the only apparent path, the minimum state is BLOCKED.DO_NOT_STORE material must not be serialized, promoted, added to SSOT, included in handoff, or turned into stable project basis under any condition.Validate sources
Before any material can become official basis for the target project, it must be validated against five criteria from
01_RULES.md:- Authority — does this source have standing to govern the project?
- Direct relevance — does it bear on the specific target?
- Explicit role — has its role been stated, not assumed?
- Freshness — is it current enough for time-sensitive projects?
- Contradiction status — does it conflict with other validated sources?
SOURCE_OR_MATERIAL_TRANSFER_ARTIFACT — where it can travel to the target project for later evaluation — not in the INITIAL_SSOT_ARTIFACT.Test promotion eligibility when relevant
Promotion is the act of moving material from candidate status into stable, governing basis. It is intentionally conservative. A piece of information is promotable only if it satisfies all three tests from
01_RULES.md:stabilized— the material is not still in fluxnormative— it has governing intent, not just descriptive utilitynon_case_specific— it applies beyond a single case instance
Not everything needs to be known — what matters is that the current gate is satisfied. A missing source that is not required for the opening decision does not block readiness. A missing source that is required does.
Apply the readiness gate
With stability, residence, source validation, and promotion eligibility closed, apply the readiness gate. The system closes the current state as one of four values:
| State | Meaning |
|---|---|
READY | All required gate conditions for the current opening decision are satisfied |
NOT_READY | Material is missing or weak, but the frame and procedure remain coherent |
BLOCKED | A structural condition is missing, invalid, or unavailable — flow cannot continue safely |
CONFLICT | Two or more surfaces produce incompatible claims that cannot be closed at the current authority level |
READY does not mean everything is known. It means what is required for the current opening decision is sufficiently closed. NOT_READY is normal and healthy. BLOCKED requires a structural fix before proceeding. CONFLICT must not be smoothed over with good tone or momentum — it requires resolution at the authority level, not a best guess.Close the handoff branch
Evaluate whether a
HANDOFF_ARTIFACT is required for this case. The handoff branch has three outcomes, each governed by criteria in 01_RULES.md:HANDOFF_REQUIRED— emit the artifact according to the schema in03_ARTIFACTS.mdHANDOFF_NOT_REQUIRED— do not emit; continuity can be safely reconstructed from stable artifactsHANDOFF_FORBIDDEN— do not emit; output instead the forbidden reason, governing rule, required disposition, and minimum safe next move
Emit authorized outputs only
Output only what the canonicals authorize for the current case. The closing outputs vary by readiness state:
READY— emit readiness basis, authorized next move, artifacts to read, and artifacts to emitNOT_READY— emit missing items, weak items, whether each is blocking or non-blocking, and the minimum next moveBLOCKED— emit blocking cause, governing owner, and minimum unblock moveCONFLICT— emit conflicting sources, resolution rule applied, suspended point, minimum unblock move, and peer authority status
Stop Conditions
The standard flow includes explicit stop conditions — points where the system halts rather than proceeding on an uncertain or invalid basis.How Authority Flows
The four canonical files are arranged in a strict precedence hierarchy.00_SCOPE.md is the highest authority — it closes the system frame and no lower file may redefine it. 01_RULES.md is the highest authority on criteria. 02_PROTOCOL.md applies those criteria in procedure. 03_ARTIFACTS.md defines the artifact grammar the procedure emits.
Runtime operator input is permitted only within the fields already marked as overrideable in 01_RULES.md. A runtime instruction that attempts to touch an immutable field does not override it — it triggers a CONFLICT state and surfaces the governing rule. This is not inflexibility. It is what keeps the preparation room from becoming another place where chat momentum quietly becomes project authority.