← Golden Thread The Core tier

10 Core rules, re-asserted for every response

A rule in a file Claude read an hour ago is a rule Claude may have stopped following: whatever is on screen crowds it out. So Golden Thread puts its Core rules in front of Claude with every single prompt, and the five that must never break are checked: a reply or command that breaks one is blocked before it lands.

One turn

What happens every time you press Enter

Edit a rule file and the very next turn uses the new text. If the vault cannot be reached, the hook says so loudly instead of going quiet.

Word for word

Exactly what Claude sees with every prompt

This block arrives with every prompt you send, before Claude reads a word of it. It is the real output of gt's rule hook, run against the rule files that ship with gt.

Current date and time: 2026-10-10 15:08 CDT

CORE RULES (always on, every turn, every project — see core-rules):
1. Write vault content only through the write queue (gt_write_queue.py), then apply it with gt_broker.py drain; never edit a vault file directly, and never write one another live session has claimed.
2. Name the vault on every mutating tool run — --vault or --dry-run — never let the target be inferred.
3. Never put a secret's value into the session — not to inspect it, not to redact it, not to check it.
4. Run the tests before you commit code, and say which ran — never commit code whose tests you have not seen pass.
5. Begin every response with the current wall-clock timestamp.
6. `global-memory/` contains only facts needed in EVERY project.
7. Do not auto-load the full memory index.
8. Parallelise any work that can be parallelised, in every project — independent units run concurrently within one machine-wide budget shared by every session, and serial execution must be justified, not assumed.
   (parallel_max: at most 13)
9. A secret's value rests only in the secrets store (sops + age on a dedicated host) or a mode-600 file the store wrote — never in source, a vault file, a repo, a log, or a session; if you find one anywhere else, file it, rotate it, and move it.
10. Label every derived figure you present as fact with its verification state — `unverified`, `self-verified`, or `independently verified`.
Open any rule

The ten rules

checked a hook blocks the break, and the message below is the one it really prints. reminder re-asserted every response; judgement no hook can check.

1Vault writes go through the queueWrite vault content only through the write queue, then apply it with the broker; never edit a vault file directly, and never write one another live session has claimed.checked

Two sessions writing the same note at once is how memory gets corrupted. The queue lets the broker hold a write another session has claimed, remove duplicates, and send design and global-memory changes to you for review.

What Claude sees if it tries a direct edit (shortened) 
BLOCKED by Core rule core_concurrent_session_claim (queue first).

  Projects/my-app/research.md
  is vault content, and vault content is written only through the write queue (Edit was refused).

The broker holds a write another live session has claimed, removes duplicates, and sends
conflicts and every design.md / global-memory write to the owner for review.
2Name the vault every timeName the vault on every command that changes it, with --vault or --dry-run; never let the target be inferred.checked

A rehearsal meant for a scratch copy once migrated the live vault's 42 decisions files, because the tool quietly defaulted to the real vault. Now a writing command that does not say which vault never runs.

The real message (shortened) 
BLOCKED by Core rule core_explicit_vault_target.

  gt_adr.py migrate writes to a vault, and this command does not say which one.
  It would resolve the vault from ~/.claude/vault-config.json -- your REAL
  vault -- whatever you meant.

Do this instead:
  1. Rehearsing on a copy?   add --vault <copy>
  2. Just want to see it?    add --dry-run
  3. Meant the live vault?   add --vault <path> -- say it, so the next reader can see you meant it.
3No secret in the sessionNever put a secret's value into the session: not to inspect it, not to redact it, not to check it.checked

Anything in the session can end up in a transcript, a log or a summary. The reply is scanned before you see it; a key, a token or a password in it sends the reply back.

The real message 
Core rule violated (core_no_secrets_in_transcript): the reply contains an API key.
Never paste a secret into the session, including to inspect or redact it -- read the
file directly, or report only its shape (length, prefix, which key it is). Re-send
without the value. If this is a false positive on a placeholder, use an obviously
non-real form such as <client-secret>.
4Tests seen to pass before a commitRun the tests before you commit code, and say which ran; never commit code whose tests you have not seen pass.checked

"The tests passed earlier" is not the same as passing on the code you are about to commit. A commit is let through only when a test receipt covers what is staged. A repo with no tests opts out visibly, for everyone.

The real message (shortened) 
BLOCKED by Core rule core_test_before_commit.

  1 code file(s) staged, and their tests have not been seen to pass.

Do this instead:
  1. Run them, then record it: gt_test_receipt.py record --repo . --ok
     (tests/run.sh and dev/release-check.sh record their own receipts.)
  2. This repo has no tests?   touch .gt-no-test-gate   -- exempt, visibly, for everyone.
  3. This one commit only:     GT_TEST_GATE=off git commit ...
5The real time on every replyBegin every response with the current wall-clock time, taken from the hook, never guessed.checked

It costs nothing and shows on every reply, so it works as a canary: the first rule to slip when attention drifts. When it fails, you know the others are at risk too.

The real message 
Core rule violated (core_timestamp_every_message): neither the final answer nor the
first text of this turn begins with the timestamp. Start the final answer with the value
injected by the UserPromptSubmit hook, e.g. '2026-08-16 15:32 CDT'; do not guess it.
6Global memory stays smallThe always-loaded memory holds only facts needed in every project.reminder

Whatever is loaded everywhere costs tokens everywhere and competes for attention everywhere. A fact that matters to one project lives in that project.

7Look things up; don't preloadDo not auto-load the full memory index.reminder

Opening a project indexes its notes without reading them all. Notes are read when a question needs them, so a large vault does not slow every session down.

8Parallel when it helpsRun independent work in parallel, within one budget shared by every session on the machine; serial work must be justified.reminder

Independent searches and checks run side by side instead of one after another, without several sessions together swamping the machine.

9Secrets live in the storeA secret's value rests only in the secrets store or a locked-down file it wrote; never in source, a vault file, a repo, a log or a session. One found anywhere else is filed, rotated and moved.reminder

Rule 3 stops a secret entering the session; this one says where secrets belong, and what to do when one turns up somewhere it should not be.

10Say how you knowLabel every figure presented as fact: unverified, self-verified or independently verified.reminder

A number that sounds certain and one that was checked look the same on the page. The label tells you which one you are reading before you act on it.

Your own rules

Each rule is one plain file

Rules live in your vault's core-rules/ folder as markdown. Change the text and the next response uses it. Add your own the same way; the tier is kept small on purpose, because every rule added dilutes the rest.

---
name: core_test_before_commit
enforcement: validated
imperative: "Run the tests before you commit code, and say which ran. Never commit
  code whose tests you have not seen pass."
---

From the real rule file. Getting started covers what gt never does without asking.