Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/xxyoudeadpunkxx/signal-rail/llms.txt

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

Some things should be hard to change — not because they are preferences, but because removing them would make the project stop being itself. 02_protocol_freeze.txt holds those things. It is intentionally short, intentionally difficult to touch, and governed by a hard maximum of five entries. If it is long, something has gone wrong.

What it is

02_protocol_freeze.txt holds the identity constants of the project. Write here only the things you do not want to reopen easily because, if they fail, the project stops being itself. The file should stay short, strong, and difficult to touch. Freeze is not about what is good or working well right now. It is about what has proven stable over time and would fundamentally change the project’s nature if removed.

Freeze vs. Decision vs. Live Work

These three levels are often confused. Confusing them weakens 02_protocol_freeze.txt and corrupts the whole routing model.
LevelWhat it isWhere it lives
FreezeA constant that should be difficult to reopen — the project stops being itself without it02_protocol_freeze.txt
DecisionA choice that has already been taken and won against a real alternative04_decision_log.txt
Live workThe current state of the project — what is active, blocked, or in motion right now03_master_working.txt

What qualifies as freeze

Before writing an entry in 02_protocol_freeze.txt, ask all three questions. If any answer is unclear, do not freeze it yet.
  1. Would the project still be recognizable if you removed it? If yes — if removing it would not meaningfully change the identity — it does not belong here.
  2. Are you defending a foundation or only a good solution for today? A good solution for today is a decision. A foundation that would fail the project is a freeze candidate.
  3. Does it truly belong to the project’s identity? Principles that remain true even when the project changes shape, tools, or working style may belong here. Constraints that are only strong because of the current context do not.

Maximum 5 active entries

02_protocol_freeze.txt accepts a maximum of five active freeze entries (F-01 through F-05). This limit exists for two reasons: it prevents the file from becoming a total summary of the project, and it prevents it from being used as a prestigious place for everything that sounds important. If you need a sixth entry, one of the existing five is probably not a real freeze.

F-xx entry structure

Each freeze entry uses the following fields. Use only the slots that are truly useful — do not feel forced to fill all of them.
- id: F-xx
- principle:
- why it is frozen:
- links to:
- reopening trigger:
FieldPurpose
idStable identifier, F-01 through F-05. Never reused.
principleThe live sentence of the freeze — short and readable.
why it is frozenWhat breaks if you lose this principle.
links toPoints to a strong source, not to noise. Cross-file IDs stay references here; they do not become new local IDs.
reopening triggerThe narrow condition under which this freeze would be seriously reconsidered.

How to write a good freeze entry

  • Principle should be short and readable — one sentence is usually enough
  • why it is frozen should say what breaks if you lose it — not what is nice about it, but what fails
  • links to should point to a strong source; use external reference for material outside the canonical set
  • reopening trigger should be narrow and concrete — not “if we change our mind” but “if real cases show that X consistently fails under condition Y”
  • Local entries in 02 use only F-xx; if you reference D-xx, L-xx, or other external IDs, they remain references in links to and do not become new local IDs here

What does NOT go here

The following material does not qualify as freeze and should be routed elsewhere:
  • Preferences — taste and habit do not define project identity
  • Current work state03_master_working.txt
  • Live but contextual decisions04_decision_log.txt — a choice that could still be reopened is not a foundation
  • Strong but young ideas05_latent_ideas.txt — something that has not held over time has not earned freeze
  • Momentary detail, style, operational preference, or temporary solution — these depend too much on current context
  • Things working well right now but not yet proven over time — wait for validation before freezing

Typical errors

  • Freezing things too early — giving authority to material that is still too young. A principle earns freeze by holding over time, not by sounding important.
  • Freezing a good current solution instead of a tested principle — if you are freezing a solution that is working well in this phase, you are probably freezing a decision, not a constant.
  • Using it as a values manifesto — philosophical statements about what the project believes are not the same as identity constants that, if removed, would break the project.
  • Filling every slot for the feeling of completeness — five empty or forced entries is worse than two strong ones.

Build docs developers (and LLMs) love