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.

00_SCOPE.md is the highest-authority canonical file in Project Forge. It closes the frame of the entire system — nothing below it may redefine system scope, non-scope, target, or final output. Every other canonical file applies the frame this file establishes; none may override it.
Read order vs. precedence order: 00_SCOPE.md is read first in the canonical read order because it establishes the frame before any criteria, artifact grammar, or procedure is introduced. It also holds the highest position in the authority precedence chain. These are two different orderings that answer two different questions — read order is about comprehension, precedence is about conflict closure. In this file’s case, they agree: it comes first in both.Canonical read order:
00_SCOPE.md
01_RULES.md
03_ARTIFACTS.md
02_PROTOCOL.md

​
Purpose and authority

00_SCOPE.md defines the identity, scope, non-scope, target, and final output of Project Forge. It is the highest file on system frame. No lower file may redefine this file. It must be read first so that every classification rule, procedural step, and artifact definition that follows operates inside a frame that has already been closed.

​
System identity

Project Forge is a permanent preparation system for opening target projects in ChatGPT. Project Forge does not execute the target project. Project Forge prepares the target project. That distinction is load-bearing: the system’s job is to produce a clean, explicit opening package — not to become the project itself or to run it on behalf of the operator.

​
Scope

Project Forge may:
  • Define what project is being prepared
  • Define what the prepared project must receive to start correctly
  • Define the frame that the core protocol must obey
  • Externalize case state into controlled artifacts

​
Non-scope

Project Forge must not become:
  • The live target project
  • A case archive
  • A long-term mixed notebook
  • A memory substitute
  • A raw source dump
  • A domain-shaped framework pretending to be general
Each of these failure modes represents the same underlying error: allowing the preparation system to absorb the responsibilities of the thing it is preparing, or to accumulate state and shape that belongs outside the canonical core.

​
Target

The system targets projects that must start from explicit structure instead of reconstruction from chat. When a target project can rely only on what has been explicitly externalized — and cannot rely on hidden session memory, implied continuity, or conversational tone — Project Forge provides the preparation layer that makes that startup reliable.

​
Final output

The system produces:
  • A stable canonical core
  • External artifacts for target-project opening
  • External artifacts for case state transfer when required
The canonical core does not hold live case state. Case state lives in the external artifact surfaces. This separation is intentional: it keeps the core reusable, auditable, and domain-agnostic across different target projects.

​
Success conditions

Project Forge succeeds only if all four conditions are met:
  1. The system remains domain-agnostic
  2. The core remains free of live case state
  3. The target project can open from explicit materials
  4. Ambiguity is reduced without being hidden
The fourth condition is especially important. The system’s goal is not to paper over unknowns but to make them visible and classified so the target project can start with accurate situational awareness rather than false confidence.

​
Frame rule

This file closes the frame of the system. Nothing below this file may redefine system scope, non-scope, target, or final output. Lower files may reference what this file establishes, but reference is not permission to redefine. If a lower file appears to contradict this file on scope, non-scope, target, or final output, this file governs.
The general use perimeter follows directly from the frame: use Project Forge only to prepare, bound, validate, and externalize the opening package of a target project. Do not use Project Forge to run the target project itself.

Build docs developers (and LLMs) love

Get started for freeTalk to us