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.

The smoke test is a small, honest check of the system. It does not certify the full protocol or measure elegance. It answers one question with the highest practical signal: can Project Forge produce a clean target-project opening package from explicit files, without depending on the preparation chat as hidden state? Everything else the system does is secondary to that question. If the answer is no, the opening package is not ready — regardless of how confident the AI sounded during preparation.

What the Test Really Checks

The smoke test is not a test of whether an AI sounds smart or responds fluently. It is a test of whether the system can:
  • start from the correct files and nothing else
  • respect canonical startup order
  • keep authority clean and bounded
  • build the minimum opening package without inventing missing state
  • produce a package that lets a target project start without relying on the preparation chat
The most common failure mode in systems like this is not incorrect answers — it is hidden continuity. The AI appears to operate from the preparation context when it is actually reconstructing from session memory, prior chat momentum, or loosely implied knowledge. The smoke test is designed to expose exactly that failure.

Why This Matters More Than Functional Correctness

A system can produce a structurally correct-looking package and still fail this test. If the package only makes sense because the AI happened to remember what was discussed earlier, the target project cannot start from that package in a clean context. The output looks useful, but it is carrying implicit dependencies that will not survive a real re-entry. The smoke test forces explicitness: the package must stand on its own.

Prerequisite: Use a Clean Environment

Run the smoke test in the cleanest environment you can. Prefer a new chat, a new or clearly isolated project, and only the files named for the test. If the platform can reference previous chats or saved memory, assume contamination is possible unless you have deliberately isolated the run.

The Test Files

Provide only the following files for the smoke test. Do not add extra files “just in case” — a noisy input pack makes the test harder to trust.
AI_START.md
00_SCOPE.md
01_RULES.md
03_ARTIFACTS.md
02_PROTOCOL.md
artifact_templates/ENTRY_POINT.md
artifact_templates/TARGET_PROJECT_BRIEF_ARTIFACT.template.md
artifact_templates/INITIAL_SSOT_ARTIFACT.template.md
smoke_test/CASE_01_MINIMAL_OPENING.md

How to Run It

1
Start a fresh session
2
Do not begin from an already contaminated or over-contextualized chat. If the session has prior context the AI can pull from, the test will not be clean.
3
Provide only the test pack
4
Give the AI only the nine files listed above. Nothing extra. If the AI needs material that is not in the pack, that gap should surface during the run — it should not be silently filled from memory.
5
Give a short instruction
6
Keep the instruction minimal. Something like the following is enough:
7
Read AI_START.md, use the canonicals, use the smoke test case.
8
Do not explain the whole system in your own words unless the AI clearly starts from the wrong place. If the AI needs a long spoken briefing to begin correctly, the test has already lost some of its value.
9
Watch the first move
10
The first move is the highest-signal part of the test. The AI should route through AI_START.md, rebuild the canonicals in read order, avoid claiming hidden continuity, understand that ENTRY_POINT.md is the package startup surface, and understand that the brief and initial SSOT carry project-specific opening content.
11
The AI should not: start from source material; act as if artifacts already exist when only templates exist; treat templates as authority; emit handoff by default; invent basis that is not present.
12
Ask it to build the minimum opening package
13
For this smoke test, the minimum acceptable target-project package is:
14
  • ENTRY_POINT.md
  • TARGET_PROJECT_BRIEF_ARTIFACT
  • INITIAL_SSOT_ARTIFACT
  • 15
    Nothing else should be required unless the run materially changes shape.
    16
    Judge the outcome honestly
    17
    At the end, ask one question: if I open the target project from the generated package, can it begin without depending on the preparation chat as hidden state? If the answer is no, the test did not pass.

    Case 01: Minimal Opening

    Case 01 is the first and most fundamental smoke test case. It is small enough to stay readable and real enough to expose startup mistakes. The case is: prepare a target project that turns rough workshop maintenance notes into a reusable recurring checklist.

    Why This Is a Good Smoke Test Case

    This case is useful because it requires target closure, output closure, one entry point, one target-project brief, and one initial SSOT — and nothing more. It does not require web search, measurable readiness, handoff in the first run, or source transfer. It is real enough to matter but small enough that system mistakes cannot hide inside complexity.

    The Raw Material Available

    The operator provides these notes as the starting source material:
    - check tire pressure before every weekend session
    - inspect the front suspension for visible play
    - clean dust from the chassis after use
    - replace damaged body clips
    - note any steering play
    - charge batteries the night before
    - do not leave packs fully charged for several days
    - keep one short field for unusual problems found during inspection
    

    What the Target Project Must Produce

    The target project should produce:
    • one clean recurring checklist
    • one short inspection order
    • one short section for unusual issues found during inspection

    Constraints

    The output should be simple, direct, free of domain theory, limited to what the notes support, and easy to reuse every week.

    Minimum Expected Opening Package

    ENTRY_POINT.md
    TARGET_PROJECT_BRIEF_ARTIFACT
    INITIAL_SSOT_ARTIFACT
    
    No handoff is needed unless the run is interrupted or becomes materially incomplete.

    What a Good Result Looks Like

    A good minimum result for the smoke test gives you all of the following:

    Usable Entry Point

    One complete ENTRY_POINT.md that defines package read order, surface interpretation, startup inference limits, and startup stop conditions.

    Usable Target-Project Brief

    One TARGET_PROJECT_BRIEF_ARTIFACT with objective, scope in, scope out, required outputs, and project-specific constraints filled from the available source material.

    Usable Initial SSOT

    One INITIAL_SSOT_ARTIFACT that freezes the initial official basis — what is actually present, not reconstructed from chat.

    Explicit Gaps Marked

    Any missing material is explicitly marked as missing. The package does not silently fill gaps with invention.
    The result does not need to be elegant. It needs to be clean, sufficient, and trustworthy. No silent reliance on preparation-chat continuity.

    Failure Signals

    Treat the test as failed if the AI does any of the following:
    • Pulls from previous chats or memory that was not provided in the test pack
    • Behaves as if missing artifacts already exist
    • Skips ENTRY_POINT.md or reduces it to noise
    • Treats source material as official basis by default without validation
    • Emits a HANDOFF_ARTIFACT without real need
    • Leaves the target project still dependent on the preparation chat as hidden state

    If It Fails

    Do not spend many turns arguing inside a contaminated session. Use the smallest reset that restores explicitness:
    1
    Stop the move
    2
    Halt the current turn before the AI continues building from a flawed basis.
    3
    Restate the real file set
    4
    Make explicit what files were provided and confirm there are no others.
    5
    Restate what does not exist yet
    6
    Name the artifacts that have not been produced yet. Do not allow the AI to treat absent artifacts as present.
    7
    Restart cleanly if trust in the session is gone
    8
    If the session has accumulated enough contaminated context that correcting forward feels more uncertain than starting over, restart in a clean session.
    Once trust in current context hygiene collapses, a clean restart is often cheaper than repair.

    Build docs developers (and LLMs) love