clock-out: the toolkit declines an invocation the consuming journal is required to make

[dieterbaier]

clock-out/SKILL.md and a consuming private journal state opposite rules about who runs the project layer at the end of a day. Until 4 September 2026 that was harmless. It is no longer.

The two rules

This toolkit, clock-out/SKILL.md, section Session lead:

Invoked outside such a project — "clock out" said with no project in context — the private journal's own clock-out skill leads, this skill is not involved, and the private journal must be maintainable with nothing but its own skills.

The consuming private journal, leading mode: for every monitored project, look on its default branch for skills/clock-out/SKILL.md, and when it is present, read and execute it as the authoritative project-specific workflow.

One says do not involve me. The other says find me and run me. Both were written to prevent the same failure — the two layers re-entering each other — and they chose opposite directions to do it.

Why it stopped being harmless

On 2 and 3 September the contradiction was noted and had no consequence: the monitored projects with a local skill had no activity on those days, so the step that was skipped would have produced nothing anyway.

On 4 September this repository had a full working day:

• four commits integrated from clock-in/clock-out: the sweep sees one branch, and "from the repository, not from memory" leaves no trace #89 via issue_89: Sweep the whole repository, and record what a session read #90,
• a2e8fde at 15:18 closing Record an ADR: skills are cut by capability, not by role #86 with ADR-008, R-007, the technical-debt entry and the Q&A update,
• two issues closed.

No project-level clock-out ran. The private journal's entry for this repository was reconstructed from commit messages and the GitHub API.

That reconstruction works, and it is not the same thing as a handover. It recovers what changed and guesses why. Intent, the reason an option was rejected, the thing that was tried and abandoned — none of that is in a commit list. The private journal already records this failure mode for a repository that has no clock-out skill; here the skill exists and declines.

What this is not

It is not the session-lead rule being wrong. Preventing the two layers from calling each other in a loop is correct and must stay. The question is only whether "invoked from outside a project" is one case or two:

Caller	Today	Arguably
A person, with no project in context	this skill is not involved	unchanged — correct
The private layer's leading clock-out, for this repository	this skill is not involved	a delegated invocation, which is exactly what the delegated mode is for

The second row is not a person saying "clock out" from somewhere else. It is a lead that has already resolved the day, knows which repository it is asking about, and will not be re-entered because a delegated invocation sweeps nothing.

Options

1. Split the outside case. A delegated invocation naming this repository is accepted and runs the project layer only; a bare invocation from outside stays out. Smallest change, preserves both intents.
2. Turn pull into push. The private layer stops fetching the project skill and instead requires a handover record that the project produced when it last worked. Moves the obligation to the project and needs a place to put the record.
3. Make the status quo explicit. Keep the refusal and remove the opposite requirement from the private layer, so it reconstructs from evidence by design rather than by accident — and says so in the entry.

Option 3 is honest but loses the intent of every project that has a local skill. Option 1 looks smallest from here; the decision belongs to this repository.

Acceptance criteria

1. clock-in/SKILL.md and clock-out/SKILL.md give one unambiguous answer for a delegated invocation that names the repository it is asking about.
2. The answer cannot re-enter the loop the session-lead rule exists to prevent, and that is stated rather than assumed.
3. Whichever option is chosen, a consuming private journal can implement it without reading this repository's private counterpart.
4. When the project layer is deliberately not run, the reconstruction and its limits are what gets recorded — not silence.
5. features/skill-wiring.feature still passes, and gains a scenario if the resolution introduces a new delegation edge.

Related

• Model execution independence as a declared property of gate skills #87 — independence as a declared execution property. Adjacent, not the same: that one asks who may verify, this one asks which layer runs the lifecycle step at all.
• ADR-008 places the agent persona on the runtime side of the boundary. This question is about layers, not personas, and is not decided by it.