Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/xxyoudeadpunkxx/memory-assisted-shaping/llms.txt

Use this file to discover all available pages before exploring further.

A gate is a decision point that, if left unresolved, would make the final artifact wrong, unusable, or structurally misleading. Most decision points are not real gates. The protocol treats a point as a real gate only when it clears the gate test — and applies one of four explicit handling strategies to each gate it finds.

The gate test

Gate test: If unresolved, would the final artifact become wrong, unusable, or structurally misleading? If no, it is not a gate.
A decision point is a real gate only if it changes one or more of these seven axes:
  • Scope — what the artifact covers or does not cover.
  • Hard constraints — non-negotiable requirements that bound the solution space.
  • Runtime or host model — the environment in which the artifact must operate.
  • Persistence model — how state is stored, accessed, or mutated.
  • Lifecycle — how the system or artifact is initialized, maintained, or retired.
  • Source of truth — which system, file, or authority owns a given piece of data or behavior.
  • Success criteria — what the artifact must do to be considered correct and usable.
If a decision point does not touch any of these axes, classify and handle it without treating it as a gate.

What is NOT a gate

The following are not real gates by default. They become gates only when they materially alter one of the seven real axes listed above:
  • Naming
  • Formatting
  • Cosmetic structure
  • Minor implementation details
  • Reversible choices
Creating fake gates around these items is a protocol failure. It blocks shaping work, adds drag to the session, and forces the operator into decisions that do not affect the final artifact.

Gate handling strategies

Every real gate is classified before GPT acts on it. There are four handling strategies.

ASK

Use ASK when choosing between options would change operator intent, scope, authority, or non-reversible direction.
  • Ask a closed or bounded question — not an open-ended exploration.
  • Ask only if the answer changes the next move. If the answer would not change what GPT does next, do not ask.

PROPOSE

Use PROPOSE when one option is clearly cheaper, simpler, safer, and reversible compared to the alternatives.
  • State the proposed default explicitly.
  • State the operational reason for choosing it.
  • Continue without waiting for confirmation.
PROPOSE is the most common gate handling strategy. Prefer it over ASK for reversible defaults. Asking for operator input on a reversible decision that GPT can recover from later adds friction without adding safety.

DEFER

Use DEFER when the gate is real but not material to the current state. The gate exists and is tracked, but it does not need to be resolved to continue shaping.
  • Mark the gate explicitly as deferred.
  • Continue shaping until the gate becomes material.
  • Never treat a deferred gate as closed.
DEFER never means closed. A deferred gate must be revisited before SYNTHESIS. Treating a deferred gate as resolved during artifact production is a protocol failure.

STOP

Use STOP when continuing would make the artifact wrong, unusable, or structurally misleading and no default can safely substitute for operator input.
  • Stop.
  • Surface only the blocking gate — not every open question in the session.
  • Ask only what is required to unblock. Do not ask about non-blocking items at the same time.

Memory signals for gates

Gate signals keep the session continuity intact across long or branched shaping work.
  • ASK, DEFER, and STOP gates are normally signal-worthy. When Python persistence is available, append a gate signal when one of these strategies is applied.
  • PROPOSE gates generate a memory signal only when the proposed default affects later synthesis, source of truth, or persistence. A reversible cosmetic default does not warrant a signal.

Build docs developers (and LLMs) love