felhom.eu/.claude/rules/unprompted-work.md

unconditional

unconditional
true

Unprompted work — rules for any session without a task file

Goal sessions, nightly sessions, "work the register" sessions. A session that starts from /goal or a standing brief inherits these rules exactly as it inherits the gates. They are the part of PROMPT-TEMPLATE.md that a task file used to carry and a goal does not. Same wording lives in felhom.eu, felhom-controller, felhom-agent and app-catalog-felhom.eu .claude/rules/, and in the workspace root's unversioned .claude/rules/; change all five or none.

1. What you may pick up on your own

• A register row you or another CC session filed, with owner CC, at P3 or a bounded P2, that needs no operator decision, touches no customer data by design, and introduces no mechanism nobody has measured. Smallest first.
• A defect you find while exercising the product, filed as a row before you fix it — unless it is small: a small finding is fixed in the session and never filed (the size rule, OPEN-ITEMS.md „How a row is filed").
• Hygiene: register compression, stale citations, rows with no owner, documents that contradict live source.

Not yours, ever, without a task file or an operator word: money; anything that changes risk to customer data; anything that changes a promise the product makes to a customer; anything that reverses a documented design decision (documentation/architecture/ — a design decision is not a defect, R-370); anything on DooPlex or ep0; baking or vouching a golden; promoting a catalog version; a new external dependency; a hub image build or hub deploy in a session the operator does not attend (operator ruling 2026-10-07, 09 §3 decision 162).

2. When you may decide instead of ask (operator grant, 2026-09-14)

You may take a decision yourself when all of these hold: the architecture folder and the register give a clear direction; your choice follows that direction; it is reversible without customer-data risk; and you can write it in the 09-update-architecture.md §3 shape — one answerable sentence, the options, what each costs, why this one. Then record it as a dated decision in CONTEXT.md and the owning architecture document, tagged decided by CC unattended — operator may reverse, and put it first in the morning note. A decision you cannot write in that shape is one you do not take.

3. The discipline a task file used to carry

1. Baselines first. Read each repo's main hash and version from live source before touching it.
2. Read the architecture document for the area, and name it in the report, before any claim.
3. Red-proof every correctness fix. A test never seen failing has not been shown to test anything.
4. Live-validate on a Tier-0 box through the endpoints the UI invokes. demo-hp is ssh hp. Throwaway apps only; the standing apps and bentopdf stay.
5. Evidence off the machine at the end of each phase, before any revert (R-320).
6. One release per repo per session, with a CHANGELOG entry (controller: with its MinAgent line) and REPORT overwritten. A controller release needs no golden (operator ruling 2026-10-15 11:26, 09 §3 decision 250; decision 7 stands): push the image only when it is ready for EVERY box (the household's update button offers the highest tag); raise the floor, MinAgent declared, only after it ran on Tester 1, demo-hp and demo-felhom through the normal update path and the box walk's checks are green on all three — not at night unless the night brief says so. Agent releases still stop for the operator's vouch. The golden is baked weekly and vouched by the operator; CC never vouches. No --no-verify. A version number is pushed once — felhom-controller/controller/build.sh now refuses a second push of a tag that exists, and a registry it cannot reach is a refusal too. This is a FACT about what the build does, not a new rule: a fix for something already pushed is the next patch version, and a box on a bad image is moved by the normal update path, never by re-tagging. Earned on 2026-10-15, when 0.315.0 was pushed three times from three different commits and a cache kept serving the first one (09-update-architecture.md §0).
7. An enumerated gap becomes a row in the same session — or, if it is small, is fixed in it (the size rule). Prose is not a record.
8. Hungarian text is searched with ASCII fragments, with a positive and a negative control.
9. Never leave a half-state. If time runs out, revert to clean and say what was reverted.
10. Teardown, three layers, stated — machine, host, hub — or "provisioned nothing".
11. Every helper prompt carries the brief's fences in full (operator ruling 2026-10-07). A helper session (a subagent, a fork, a workflow agent) gets the brief's fence list word for word — every protected machine, every „no", every delivery and Docker limit — not a summary and not „the usual fences". Earned on 2026-10-06 night: two helpers whose prompts carried only part of the fences ran docker volume prune on the bench and a Docker-using gate on DooPlex.

4. The morning note

One screen, plain language, in this order: decisions you took (§2) first; what you exercised; what broke and whether you fixed it; rows opened and closed with the register size before and after; what needs the operator, each with what happens if they do nothing. No file paths, no function names, no row numbers as the subject of a sentence.

5. Instruction files

Instruction files (CLAUDE.md, .claude/rules/*) are kept true by the session that finds them wrong (operator ruling 2026-10-06, 09 §3 decision 150). A session MAY, without asking: correct a stale fact (a command, a count, a version, a path, a description of what a gate does), add a fact it proved, and remove a reference to something that no longer exists. Each edit is named in the report (file, line, before, after, why). A session MAY NOT, without the operator's word: loosen a safety rule, a fence, a „never", a protected machine, a secret rule, or a review step; or remove a rule. When in doubt, it is a rule change, and it goes to the operator. If Claude Code's own permission check asks before such an edit, wait for the operator's click; if it refuses, record that and file the exact line.

6. The system poster stays true

A session that changes a fact listed in architecture/felhom-system-poster.facts.md (a machine, a role, a traffic path, a backup tier, a time, a retention, a key, a known gap) updates that file in the same commit. If the change is text only, it also edits the matching text in felhom-system-poster.html. If it needs a new drawing, it adds the line "System poster needs a refresh: " to STATUS.md's "waiting on the operator" list. The session report names which of the three it did.

Why the three-way split: the poster is a drawing made in Claude Design, and nothing in this repository renders it — unlike where-felhom-stands.html, which has render_stands.py. So the facts file is the source of truth and the drawing trails it. scripts/poster_facts_gate.py warns when the facts file has a newer commit than the poster; it never fails a push, because a refresh needs the operator and another tool, and a gate nobody can clear is a gate people learn to route around.