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.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.
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
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.How to Run It
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.
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.
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.
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.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.
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: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
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.
Failure Signals
If It Fails
Do not spend many turns arguing inside a contaminated session. Use the smallest reset that restores explicitness:Name the artifacts that have not been produced yet. Do not allow the AI to treat absent artifacts as present.
Once trust in current context hygiene collapses, a clean restart is often cheaper than repair.