Keel v1.11.0 — The lock reads the skill first, and the gate stops fighting itself

What's new in 1.11.0

The CLAUDE.md lock now opens every session: step 1 is reading the FULL SKILL.md

Field-tested gap: on a fresh chat, an assistant that already had the lock in context would jump straight into the state files (the old step 1) and never load the skill body — so the session-start update check never ran, and you had to ask for a full re-read by hand.

• Step 1 — the skill, before anything else. Read the FULL SKILL.md (installed skill or embedded copy), starting with its session-start update check. Remembering the protocol from an earlier chat, or having the lock in context, does not count as having read it.
• After an update, catch up before working. When the check installs a newer Keel, the lock itself orders the post-update reconciliation BEFORE normal work continues — new files or directories, new project-card lines, the lock block itself, questions never asked in that project.
• Step 2 — then the state. PROGRESS.md, decisions.md, lessons-learned.md and the current phase's reference, plus the Keel baseline: comparison.

Lock freshness check — stamp-only, a one-line verification

CLAUDE.md is the one file every environment loads in every session, so the rules Keel keeps there must always be the current ones.

• The KEEL:BEGIN delimiter now carries a version stamp naming the Keel that last wrote the block: <!-- KEEL:BEGIN — v1.11.0 do not remove: … -->.
• SKILL.md's update check gains a companion step: every session inside a Keel project checks the stamp against the running version — equal → current, nothing else to read; different or missing (pre-1.11.0 blocks have no stamp; delimiters are matched by the KEEL:BEGIN prefix, never by exact text) → rewrite the block between the delimiters from the canonical copy in references/project-state.md, restamped with the running version, with the user's OK.
• The stamp alone decides — never a content comparison. The block itself states the same rule from its side, so an assistant that only has the lock in context knows the block may be outdated and where the canonical copy lives. The AGENTS.md mirror follows the same rule.

Confidential-data gate: field-tested false-positive hardening

Committing the gate's own script or the embedded skill tripped the gate — their files legitimately contain the very patterns it searches for — forcing a conscious bypass on the first real-world commit. Three measures:

• The hook now exempts the canonical trees .githooks/ and .claude/skills/; the assistant-side check still scans them like everything else.
• The synthetic-secret verification example — and SKILL.md's own by-content pattern list, dating from 1.9.0 — rewritten so no canonical skill file contains a matchable secret-shaped string, verified by running the gate's pattern over the whole tree: zero matches.
• New writing rule (SKILL.md "Confidential data never reaches Git", point 5, mirrored in the decisions template): docs, decision notes and lessons never embed a literal secret-shaped string — describe it or split it apart.

How to update

Replace your installed keel/ directory with this release's (see INSTALL.md, "Updating"). Projects that embed the skill get their .claude/skills/keel/ copy updated automatically by the session-start update check — the session then runs the post-update reconciliation and the stamp-only lock-freshness check, which bring the project and its CLAUDE.md block up to date.