Session Patterns: Fresh, Re-entry, and Smoke Test Runs

Project Forge operates in three distinct session shapes. Each shape has a specific purpose, a specific input set, and a specific execution rhythm. Using the right shape for the right situation is one of the most basic operator decisions in every preparation run. These patterns are not interchangeable, and mixing them — even partially — creates real operational problems.

Do not mix these three modes casually. Mixing them creates confusion about what is real state and what is only a test.

The Three Session Shapes

Before opening any session, decide which shape applies. The decision is straightforward:

Fresh case — you are opening a new target project from scratch; no prior artifacts exist for this case
Re-entry — the target project or preparation work already exists and you need continuity with what was built before
Smoke test — you are testing whether Project Forge itself behaves correctly, not running a consequential real case

Choosing the wrong shape does not just create minor inconvenience. A fresh-case session that pulls in old artifacts from a prior run treats assumed continuity as real state. A re-entry that starts without the actual existing artifacts behaves like a fresh case while pretending it is not. A smoke test that uses real case materials contaminates both the test and the material.

The Role of AI_START.md in All Three Patterns

AI_START.md appears in every pattern because it solves the same problem in every context: it routes the AI into the canonicals correctly and sets the hygiene rules that prevent the session from running on memory, momentum, or implicit continuity. It is not a fifth canonical. It does not introduce new rules. Think of it as the startup header for the AI — the first thing you hand it before anything else. In all three patterns:

Give AI_START.md first
Give the 4 canonicals next
Then give only the materials appropriate to the specific pattern

The Role of the Web Compiler

The web compiler is an operator-facing surface that supports artifact compilation in all three patterns. Use it to fill required artifact fields in a structured way, keep required versus optional surfaces visible, review imports before they affect the draft, and export a cleaner opening package. It is not authority — the canonicals govern — but it reduces entropy at the compilation step for any session shape.

Session Pattern Details

Pattern A: Fresh Opening
Pattern B: Re-entry with Continuity
Pattern C: Smoke Test

Use this pattern when you are opening a new target project from scratch. No prior artifacts exist for this case. The session builds the opening package from source materials and operator input.Typical inputs:

AI_START.md
The 4 canonicals (00_SCOPE.md, 01_RULES.md, 03_ARTIFACTS.md, 02_PROTOCOL.md)
Explicit source materials you want to expose (only what you intend to expose)
Possibly the operator guide

What this pattern does not use:

Existing artifacts from prior runs (there are none)
HANDOFF_ARTIFACT (nothing to hand off from)
Smoke test materials

Set Up the Session

Open a new, clean chat or project. Provide AI_START.md and the 4 canonicals. Do not carry in notes, prior chats, or unclassified materials.

Close the Target

Work with the AI to close objective, scope in, and scope out. If any of those three cannot be closed, the honest state is NOT_READY — do not proceed to artifact creation. Use the web compiler if you want a guided surface for filling the target sections.

Close the Output Set

Determine what the target project must receive. Decide whether a target brief is needed, whether an initial SSOT is needed, and whether any other artifact classes are required.

Instantiate the Opening Artifacts

Build the target brief and initial SSOT. Add a transfer artifact only if candidate material must travel without promotion. Do not emit handoff — there is no prior run state that requires it.

Check Readiness and Open

Apply documentary readiness. Verify all critical fields are present, no critical field is MISSING, and required artifacts are defined. If the gate is satisfied, open the target project with the opening package.

Use this pattern when a target project or preparation run already exists and you need continuity with that prior work. The session picks up from stable artifacts — it does not rebuild from scratch and it does not assume memory continuity.Typical inputs:

AI_START.md
The 4 canonicals
Existing stable artifacts (target brief, initial SSOT — only those that actually exist)
HANDOFF_ARTIFACT only if the next run depends on state, tests, or decisions that cannot be safely reconstructed from canonicals and stable artifacts alone

What this pattern does not use:

Prior chat history as authority
Artifacts that do not actually exist
Smoke test materials

Set Up the Session

Open a new chat or bounded project. Provide AI_START.md and the 4 canonicals. Provide only the artifacts that actually exist from the prior run — do not assume an artifact is present unless you have the file.

Re-close the Object

Re-state the current object. Do not assume the prior session’s object is still current — verify that what you are working toward today is the same as what was being built before, or update it explicitly.

Verify What Still Counts as Current

Review the existing artifacts. Confirm which ones are still accurate. Reject stale state explicitly — do not let old artifact content silently become the current basis if circumstances have changed.

Decide on Handoff

Evaluate whether HANDOFF_ARTIFACT is required. Use it only if HANDOFF_REQUIRED applies — when state, tests, open points, or next moves cannot be reconstructed from stable artifacts alone. Do not use it by default.

Continue Preparation

Proceed from the verified current state. Build or update artifacts as needed. Apply the same readiness gate before opening or re-opening the target project.

Use this pattern when you are testing whether Project Forge itself behaves correctly — not running a real consequential case. Smoke tests expose whether the system can produce a clean target-project opening without leaning on hidden context.Typical inputs:

AI_START.md
The 4 canonicals
smoke_test/SMOKE_TEST.md
One simple case file (e.g., smoke_test/CASE_01_MINIMAL_OPENING.md)
Minimum opening package templates: artifact_templates/ENTRY_POINT.md, target brief template, initial SSOT template

What this pattern does not use:

Real project materials
HANDOFF_ARTIFACT (unless specifically testing handoff behavior)
Production source packs

Set Up a Clean Test Session

Open a completely new, isolated chat or project. Provide AI_START.md, the 4 canonicals, and smoke_test/SMOKE_TEST.md. Keep the session isolated from any real case work.

Load One Simple Case

Provide a single simple case file — CASE_01_MINIMAL_OPENING.md is the recommended starting point. Do not add real project materials or extra sources. The test should be small enough to be unambiguous.

Run the Opening Protocol

Let the AI work through the standard flow: close the object, close the target, close the output set, classify and assign, apply readiness. Observe whether it follows the protocol correctly or drifts.

Evaluate the Output

Check whether the target project can start from the generated package without rebuilding from chat. Can the operator distinguish required from optional artifacts? Does the opening package stand on its own?

Confirm System Operational

If the target project starts cleanly from the explicit package, the system is operational. If the test exposes drift, improvisation, or protocol bypass, address those issues before running a real consequential case.

Choosing Between Patterns

If you are unsure which pattern applies, use these quick checks:

Does any prior artifact exist for this case? If no → Pattern A. If yes → Pattern B.
Are you testing the system or preparing a real case? If testing → Pattern C.
Do you have a HANDOFF_ARTIFACT from the last run? Providing it in Pattern B is only appropriate if it meets HANDOFF_REQUIRED criteria — do not include it by default.

The patterns are mutually exclusive within a single session. If you find yourself starting Pattern A and then pulling in artifacts from a prior run, you have switched to Pattern B mid-session. Name the switch explicitly and verify that the prior artifacts are still accurate before treating them as current basis.

Get Started

Core Concepts

Artifacts

Operating Guides

Reference

Session Patterns: Fresh, Re-entry, and Smoke Test Runs

The Three Session Shapes

The Role of AI_START.md in All Three Patterns

The Role of the Web Compiler

Session Pattern Details

Choosing Between Patterns

Build docs developers (and LLMs) love

Get Started

Core Concepts

Artifacts

Operating Guides

Reference

Documentation Index

​The Three Session Shapes

​The Role of AI_START.md in All Three Patterns

​The Role of the Web Compiler

​Session Pattern Details

​Choosing Between Patterns

Build docs developers (and LLMs) love

The Three Session Shapes

The Role of AI_START.md in All Three Patterns

The Role of the Web Compiler

Session Pattern Details

Choosing Between Patterns