Investigate missed intake/decision capture for out-of-lifecycle source edits

[Kyarha]

Context

jig's design principle #1 is "hooks = deterministic enforcement, skills = judgment." That split holds for secret-scan, the review-evidence gate, etc., but not for the core "work goes through a slice" discipline when editing source files.

The gap

There's no PreToolUse-style guardrail that fires when an agent edits a tracked source file without an IN_PROGRESS slice claiming it. spec-workflow is a skill the agent has to choose to invoke, so slice-compliance for a source edit is left entirely to the agent's judgment.

In practice, an agent with any bias toward "just fix the small thing" edits the file directly and skips the lifecycle — and the only thing catching it is the human noticing after the fact. This recurs.

The cost isn't proportional to the diff: a 1–2 line CSS change can encode a load-bearing, recurring design decision (a banner position, an alignment) — exactly what the slice + lightweight-decisions.md capture exists to make durable. Skipping the slice means the decision doesn't land where a future session reads it, so the same thing gets re-argued sessions later.

Suggestion (defer to you on whether/how)

Would jig consider an optional, opt-in guardrail hook that, on Edit/Write to configured source globs, checks jig state (workflow.py / .jig) for an IN_PROGRESS slice and, when there's none, warns (or configurably blocks) with a pointer to start a slice / run the intake?

• Strictness (warn vs block) and globs would be per-project config.
• Makes "no source edits outside a slice" mechanical, consistent with the hooks-are-deterministic principle, instead of relying on the agent remembering.

Related: for a new external reference (e.g. a new design/mockup version), the documented entry point is /jig:reframe → spec, but nothing routes the agent there automatically either — a guardrail could nudge that intake too.

Reported from real usage (a card-games project on jig 2.7.0) where an agent repeatedly hand-edited CSS outside slices.

[ramboz]

Thanks for filing this. This is a real failure mode, especially when a visually small change encodes a decision future sessions must preserve.

I do not think “source edit without an IN_PROGRESS slice” is the right invariant, though. Not every change belongs to a slice:

• defects may use the bug-fix lifecycle;
• trivial bugs intentionally use TDD + fix with no durable record;
• trivial non-bug changes may also proceed without a spec;
• only non-trivial behavior/design work should require a spec slice.

That means a source glob can detect an edit, but cannot determine whether skipping a slice was wrong. A blocking gate would reject valid work, while a repeated warning would likely become noise.

Jig 2.7.0 already has decision capture specifically for visual/CSS choices made outside a spec. The first step should be to understand why that path did not catch or preserve this decision. If it failed to fire, this is a useful targeted bug/eval case for decision capture. If it fired but was ignored, another warning may not solve the underlying problem.

The narrow follow-up I would consider is a one-shot, non-blocking intake reminder, not a slice gate:

This edit has no active lifecycle record. If it is trivial, proceed. Otherwise classify it as bug-fix, spec-workflow, or reframe, and capture any settled out-of-spec decision.

No configurable globs, warn/block modes, or general project-policy schema initially. Projects that deliberately require slices for particular paths can add that stronger rule to their scaffolded hooks; that is project policy rather than a universal jig invariant.

Keeping this open as an investigation into missed intake/decision capture rather than implementing the proposed guardrail as written. The next useful input is one failing session/transcript or hook log so we can establish whether the existing capture path failed to fire or fired without changing behavior.