@try-works/dsh-recursive-mode 0.4.8 → 0.5.0

package/lib/policy-globs.d.ts

@@ -1,3 +1,4 @@
+import { type PrerequisiteBlocker } from './lock.ts';
 /** The three verdicts a rule may carry. */
 export type Verdict = 'allow' | 'deny' | 'ask';
 /**
@@ -10,6 +11,18 @@ export interface Decision {
     kind: Verdict;
     reason?: string;
     rule?: string;
+    /**
+     * THE FACTS THE PREDICATE DECIDED FROM, when it read any. The lock-order rule resolves the
+     * artifact's prerequisites from disk, and the layer that turns this decision into a refusal
+     * needs those same facts to build the caller's recovery options. Carrying them is what makes
+     * "the guard already has them" true: a second `getPrerequisiteBlockers` call from the denial
+     * would re-read a run tree that is on disk and unlocked, and could answer differently.
+     *
+     * Absent for every rule that decides on its pattern alone, and absent when the predicate read
+     * nothing — so its presence means "this refusal was decided from these blockers", not "the
+     * policy mentions blockers".
+     */
+    blockers?: readonly PrerequisiteBlocker[];
 }
 /**
  * Extra facts a rule predicate may need. `args` is always the tool call's
@@ -21,6 +34,18 @@ export interface ToolPolicyContext {
     runDir?: string;
     runId?: string;
     worktreeRoot?: string;
+    /**
+     * The ACTIVE phase artifact of the run — the LOWEST-numbered phase artifact that is not
+     * LOCKED, falling back to the highest when every one of them is locked.
+     *
+     * ⚠ THIS IS NOT A SECOND SELECTOR. It is the answer `currentPhaseArtifact` in
+     * `enforcement.ts` produced for this call, carried here so a rule in THIS module can
+     * compare against it. `policy-globs.ts` cannot import that function (enforcement.ts
+     * imports this module, and the repo has already paid once for a value-level import
+     * cycle), so the value is passed in rather than recomputed. A caller that omits it
+     * gets NO phase-order verdict — the rule abstains rather than guessing a phase.
+     */
+    activePhaseArtifact?: string;
 }
 /**
  * What a rule predicate returns when the condition it guards DOES apply:
@@ -37,6 +62,12 @@ export interface ToolPolicyContext {
 export interface ToolPolicyPredicateMatch {
     verdict: Verdict;
     detail?: string;
+    /**
+     * The blockers the predicate READ, when it read any (see `Decision.blockers`). Optional and
+     * additive: a predicate that decided from something else returns none, and the engine's
+     * verdict is unchanged either way.
+     */
+    blockers?: readonly PrerequisiteBlocker[];
 }
 export type ToolPolicyPredicate = (id: string, args: Record<string, unknown>, ctx: ToolPolicyContext) => ToolPolicyPredicateMatch | null;
 export interface ToolPolicyRule {
@@ -152,6 +183,7 @@ export declare const LOCK_TOOL_NAMES: Set<string>;
  *
  *   `recursive_lock*`  -> the monotonic lock-order denial;
  *   the write-tool ids -> the locked-artifact write denial;
+ *   the write-tool ids -> the phase-order (write-ahead) denial;
  *   `*`                -> allow, so an ordinary tool is not turned into an `ask`.
  *
  * Every `deny` precedes the `allow`, which is what makes "deny wins over allow" a

package/lib/recursive_ask.tool.d.ts

@@ -58,6 +58,43 @@ export declare class AskValidationError extends Error {
 export declare function validateAskQuestion(question: AskQuestion): AskQuestion;
 /** Build the question for a gate, validated. */
 export declare function buildAskQuestion(gateId: AskGateId): AskQuestion;
+/**
+ * FU-7 — THE GATE-BLOCK REFUSAL PAYLOAD, BUILT IN ONE PLACE.
+ *
+ * A blocked lock is refused by TWO layers. The TOOL refuses when `lockArtifact` throws
+ * `Prerequisite blockers:`; the GUARD refuses pre-dispatch when the lock-order rule fires
+ * (`monotonic lock-order`), and under the strict default that is the layer the caller meets
+ * first. Both must hand the caller the SAME choice, so both build it HERE.
+ *
+ * ⚠ WHY NOT TWO LITERALS. `fix | reopen | abandon` is the human's way out of a blocked lock,
+ * and it existed in exactly one call site (`recursive_lock.tool.ts`). The guard's refusal moved
+ * to the default path, and a second hand-written copy of the options there would be a second
+ * answer to "what can a person do about this?": the day the options change, one of the two
+ * refusals keeps offering the old set and nothing fails. One builder, called from both.
+ *
+ * `blocked` is the refusal's OWN sentence — the guard's rule text or the tool's exception
+ * message — carried as data so the payload says what it is about without a reader having to
+ * match it against the text beside it.
+ */
+export interface GateBlockAsk extends AskQuestion {
+    gate: 'gate-block';
+    artifact: string;
+    blocked: string;
+}
+/** The payload, as the refusal carries it. Validated through `buildAskQuestion`. */
+export declare function buildGateBlockAsk(artifact: string, blocked: string): GateBlockAsk;
+/**
+ * FU-7 — THE OPTIONS AS TEXT, DERIVED FROM THE PAYLOAD rather than restated.
+ *
+ * WHY A RENDERER IS NEEDED AT ALL: the harness renders a `tools/pre-execute` denial as
+ * `Error: <reason>` and drops every other field of the decision (measured in
+ * `packages/core/tools`: `content: [{ type: 'text', text: 'Error: ' + denialReason }]`), so an
+ * ask that rode along as a SIBLING field would reach the model as nothing at all — which is
+ * exactly how a strict-by-default guard made the recovery path unreachable. The refusal
+ * therefore renders the payload into the text it hands back, and it renders THIS object, so
+ * the visible sentence and the structured payload cannot disagree.
+ */
+export declare function renderGateBlockAsk(ask: GateBlockAsk): string;
 /**
  * PHASE 0 — build the question for ANY accepted gate, including the run-start gate.
  *

package/lib/runtime.d.ts

@@ -743,7 +743,7 @@ export declare class RecursiveRuntime extends Service {
         code: string;
         message: string;
     }): boolean;
-    /** Phase C R7: resolve the enforcement config (strict|advisory, default advisory). */
+    /** Phase C R7: resolve the enforcement config (strict|advisory, default strict). */
     get enforcementConfig(): EnforcementConfig;
     setEnforcementConfig(config: unknown): EnforcementConfig;
 }

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@try-works/dsh-recursive-mode",
   "description": "recursive-mode workflow as a DeepSeek Harness bundle: RecursiveRuntime service + 13 recursive_* tools (recursive_status, recursive_init, recursive_lock, recursive_lint, recursive_closeout, recursive_scratch, recursive_worktree, recursive_phase, recursive_audit_team, recursive_review, recursive_delegate, recursive_ask, recursive_preview)",
-  "version": "0.4.8",
+  "version": "0.5.0",
   "type": "module",
   "main": "lib/index.js",
   "types": "lib/index.d.ts",

package/scripts/test-recursive-mode-smoke.ts

@@ -166,7 +166,17 @@ async function main() {
     const coercedAdvisory = coerceAskToDecision(askDecision, 'advisory')
     check('T6 ask->deny under strict', coercedStrict.kind === 'deny')
     check('T6 ask->allow+warn under advisory (never silent)', coercedAdvisory.kind === 'allow' && typeof (coercedAdvisory as { warn?: string }).warn === 'string')
-    check('R7 config default advisory', JSON.stringify(resolveEnforcementConfig(undefined)) === JSON.stringify(DEFAULT_ENFORCEMENT))
+    // ⚠ THE CHECK THAT USED TO BE HERE WAS VACUOUS: it compared the resolver's output with
+    // `DEFAULT_ENFORCEMENT`, and both sides move together, so a change of default could never
+    // fail it. Read the default and assert the VALUE, so a revert to advisory is caught.
+    const defaultConfig = resolveEnforcementConfig(undefined)
+    check('R7 config default strict (all three gates)',
+      defaultConfig.preStep === 'strict' && defaultConfig.toolGuards === 'strict' && defaultConfig.tamper === 'strict'
+      && JSON.stringify(defaultConfig) === JSON.stringify(DEFAULT_ENFORCEMENT))
+    // A PARTIAL section must fill the unstated gates with the same posture, not with advisory:
+    // the settings service merges ONE edited field into an entry's config.
+    const partial = resolveEnforcementConfig({ toolGuards: 'advisory' })
+    check('R7 partial config fills strict', partial.preStep === 'strict' && partial.tamper === 'strict' && partial.toolGuards === 'advisory')
     let configError = ''
     try { resolveEnforcementConfig({ bogus: 1 }) } catch (err) { configError = (err as Error).message }
     check('R7 unknown config key fails', configError.includes('unknown key'))

package/src/config.ts

@@ -17,7 +17,7 @@
  * silently coerced a bad value would be a second, weaker contract beside the real one.
  */
 import z from '@deepseek-ai/schemastery'
-import { DEFAULT_BUDGETS } from './enforcement.ts'
+import { DEFAULT_BUDGETS, DEFAULT_ENFORCEMENT_MODE } from './enforcement.ts'
 
 /** One enforcement mode, as the settings form presents it. */
 const enforcementMode = z.union([z.const('strict'), z.const('advisory')])
@@ -58,14 +58,21 @@ export const Config = z.object({
   repoRoot: z.string().description(
     'Control-plane root. Defaults to the process working directory when unset.',
   ),
+  /**
+   * ⚠ THE THREE MODE DEFAULTS READ `DEFAULT_ENFORCEMENT_MODE` FROM `enforcement.ts`, and
+   * that is deliberate: the schema default and the runtime default are the SAME value, and
+   * two literals here would be two defaults. A caller that omits the section gets
+   * `DEFAULT_ENFORCEMENT` from the runtime; a caller that supplies a partial section gets
+   * the resolver's fill. Both must be the enforcing posture — see the const for why.
+   */
   enforcement: z.object({
-    preStep: enforcementMode.default('advisory').description(
+    preStep: enforcementMode.default(DEFAULT_ENFORCEMENT_MODE).description(
       'Phase pre-step enforcement: strict refuses an out-of-order transition, advisory warns and proceeds.',
     ),
-    toolGuards: enforcementMode.default('advisory').description(
+    toolGuards: enforcementMode.default(DEFAULT_ENFORCEMENT_MODE).description(
       'Tool guard mode: strict DENIES an out-of-order tool call, advisory allows it and carries the warning.',
     ),
-    tamper: enforcementMode.default('advisory').description(
+    tamper: enforcementMode.default(DEFAULT_ENFORCEMENT_MODE).description(
       'Tamper detection: strict refuses an artifact whose LockHash no longer matches its body.',
     ),
     budgets: z.object({

package/src/enforcement.ts

@@ -3,7 +3,7 @@
  * (Phase C R3/R4/R7/R8, PROPOSAL 8.4/8.6/13.5).
  *
  * Layer 2 (tool guards) and Layer 8 (tamper) are the remaining enforcement
- * layers. Configurable strict|advisory per gate (default advisory).
+ * layers. Configurable strict|advisory per gate (default strict).
  */
 import { existsSync, readdirSync } from 'node:fs'
 import { join, isAbsolute, resolve, sep } from 'node:path'
@@ -15,6 +15,7 @@ import {
   type ToolPolicy, type ToolPolicyContext, type Decision as PolicyDecision,
 } from './policy-globs.ts'
 import { withPhaseBaseline, phaseNumberForArtifact, resolveFrom } from './phase-rules.ts'
+import { buildGateBlockAsk, type GateBlockAsk } from './recursive_ask.tool.ts'
 
 /**
  * The BUILT-IN default rule list (T16) is defined in `src/policy-globs.ts`,
@@ -75,6 +76,29 @@ const BUDGET_KEYS: ReadonlyArray<keyof BudgetConfig> = [
   'maxAuditRounds', 'maxRepairAttempts', 'maxDelegationDepth', 'maxChildrenPerPhase', 'maxResultBytes',
 ]
 
+/**
+ * THE DEFAULT POSTURE: STRICT, on all three gates — and this const is the ONE literal.
+ *
+ * The owner's rule is *only one phase may be active at a time, and the phases should be
+ * sequential and the active phase must be locked before proceeding to next phase*. In
+ * `advisory` that rule is only WARNED about, and a live run showed what that costs: the
+ * run ignored the lock chain for over an hour, wrote phase 8 before phase 1.5 and locked
+ * nothing (twelve DRAFT artifacts, one operations entry). Strict was previously unsafe as
+ * a default because it also refused the run's OWN artifacts — a false positive. That was
+ * fixed, and `tests/strict-run-tree.spec.ts` now walks all twelve phases asserting the
+ * active artifact stays writable while a later one is refused. Strict therefore refuses
+ * exactly the ordering violations it is meant to refuse, so the default is the enforcing
+ * posture rather than a warning nobody has to act on.
+ *
+ * ⚠ WHY IT IS A NAMED CONST AND NOT THREE LITERALS. A default restated per site is this
+ * project's recurring failure: the same value exists in the Config schema, in
+ * `DEFAULT_ENFORCEMENT`, in an omitted config section, and in the parameter defaults of
+ * the helpers below, and moving only some of them leaves a caller that "still gets
+ * advisory". Every one of those sites now reads THIS const, so a revert is a one-line
+ * change and nothing can drift from it.
+ */
+export const DEFAULT_ENFORCEMENT_MODE: EnforcementMode = 'strict'
+
 /**
  * Validate the enforcement config shape (unknown keys fail at plugin load).
  *
@@ -89,7 +113,17 @@ export function resolveEnforcementConfig(config: unknown): EnforcementConfig {
   if (unknown.length > 0) {
     throw new Error('EnforcementConfig has unknown key(s) ' + unknown.join(', ') + ' - config is { preStep, toolGuards, tamper, budgets }')
   }
-  const mode = (value: unknown): EnforcementMode => (value === 'strict' ? 'strict' : 'advisory')
+  // ⚠ AN ABSENT MODE RESOLVES TO THE DEFAULT MODE, not to the permissive branch. This is
+  // the twin-default trap in its most consequential form: a caller that supplies a PARTIAL
+  // section — `enforcement: { toolGuards: 'advisory' }` from a settings patch, or just the
+  // budgets — leaves the other gates unstated, and filling those with `advisory` would
+  // hand back a config that is looser than the plugin's own default with nothing saying so.
+  // An UNRECOGNIZED value resolves the same way and thus fails CLOSED. The Config schema in
+  // src/config.ts still rejects a typo loudly at the settings boundary; this resolver is
+  // the lenient one, and a lenient resolver must bend towards the safe posture: a typo that
+  // blocks is a visible stop, a typo that permits is the hour-long out-of-order run again.
+  const mode = (value: unknown): EnforcementMode =>
+    value === 'strict' ? 'strict' : value === 'advisory' ? 'advisory' : DEFAULT_ENFORCEMENT_MODE
 
   const rawBudgets = (raw.budgets ?? {}) as Record<string, unknown>
   if (typeof raw.budgets !== 'undefined' && (raw.budgets === null || typeof raw.budgets !== 'object')) {
@@ -117,10 +151,16 @@ export function resolveEnforcementConfig(config: unknown): EnforcementConfig {
   }
 }
 
+/**
+ * The runtime default: what a caller gets when it supplies no `enforcement` section at all
+ * (a profile mounting this plugin with no config, e.g. `preset/recursive.patch.yml`). It is
+ * `DEFAULT_ENFORCEMENT_MODE` per gate, so this object and the resolver cannot disagree —
+ * see that const for WHY the default is strict.
+ */
 export const DEFAULT_ENFORCEMENT: EnforcementConfig = {
-  preStep: 'advisory',
-  toolGuards: 'advisory',
-  tamper: 'advisory',
+  preStep: DEFAULT_ENFORCEMENT_MODE,
+  toolGuards: DEFAULT_ENFORCEMENT_MODE,
+  tamper: DEFAULT_ENFORCEMENT_MODE,
   budgets: DEFAULT_BUDGETS,
 }
 
@@ -129,8 +169,14 @@ export const DEFAULT_ENFORCEMENT: EnforcementConfig = {
  * every allow/deny/ask the guard hands back). `'none'` means no guard predicate
  * fired; `'transition'` marks a decision whose only dissenting gate was the
  * advisory transition gate (see consultTransitionGate).
+ *
+ * `'phase-order'` is the WRITE half of the ordering rule the owner states as *only
+ * one phase may be active at a time, and the phases should be sequential and the
+ * active phase must be locked before proceeding to next phase*: `'lock-order'` refuses
+ * locking ahead, `'phase-order'` refuses WRITING ahead. Two labels rather than one,
+ * because the guard log has to tell the owner which of the two the agent attempted.
  */
-export type GuardRule = 'lock-order' | 'tdd-evidence' | 'locked-write' | 'transition' | 'none'
+export type GuardRule = 'lock-order' | 'phase-order' | 'tdd-evidence' | 'locked-write' | 'transition' | 'none'
 
 /** T15: the transition gate's verdict as attached to a decision (advisory only). */
 export interface GuardTransition {
@@ -147,10 +193,16 @@ export interface GuardTransition {
  * optional — `coerceAskToDecision` is asserted with `toEqual({ kind: ... })`
  * (an EXACT match) in tests/enforcement.spec.ts, so the coercion path may never
  * grow extra keys. `evaluateToolGuard` itself always sets `rule`.
+ *
+ * ⚠ FU-7: `ask` IS OPTIONAL AND ADDITIVE TOO, for the same reason and one more. A refusal that a
+ * PERSON has to resolve carries the gate-block decision alongside its sentence (see `verdictFor`),
+ * and the payload is built by `buildGateBlockAsk` — the SAME builder the lock tool uses, so the two
+ * refusals cannot offer different options. It is absent on every decision that is not a lock-order
+ * refusal decided from real blockers, which is why every reader must treat it as optional.
  */
 export type ToolGuardDecision =
   | { kind: 'allow'; warn?: string; rule?: GuardRule; transition?: GuardTransition }
-  | { kind: 'deny'; reason: string; rule?: GuardRule; transition?: GuardTransition }
+  | { kind: 'deny'; reason: string; rule?: GuardRule; transition?: GuardTransition; ask?: GateBlockAsk }
   | { kind: 'ask'; reason?: string; rule?: GuardRule; transition?: GuardTransition }
 
 export interface ToolExecLike {
@@ -179,9 +231,12 @@ export interface ToolExecLike {
  * `recursive:policy` later — can read the effective rules instead of inferring
  * them from a code path.
  */
-export function resolveToolPolicyForGuard(worktreeRoot: string, runId: string): ToolPolicy {
+export function resolveToolPolicyForGuard(worktreeRoot: string, runId: string, activePhaseArtifact?: string): ToolPolicy {
   const loaded = loadToolPolicyFile(worktreeRoot)
-  return withPhaseBaseline(loaded.policy, currentPhaseArtifact(worktreeRoot, runId))
+  // A caller that already asked `currentPhaseArtifact` for this call passes the answer in,
+  // so one guard call reads the run tree's lock statuses ONCE rather than twice. The
+  // no-cache discipline is unchanged: an omitted argument still reads the filesystem here.
+  return withPhaseBaseline(loaded.policy, activePhaseArtifact ?? currentPhaseArtifact(worktreeRoot, runId))
 }
 
 /**
@@ -240,11 +295,23 @@ export function currentPhaseArtifact(worktreeRoot: string, runId: string): strin
   return inForce !== '' ? inForce : best
 }
 
+/**
+ * `mode` is the gate's configured posture. Its parameter default FOLLOWS the config
+ * default by REFERENCE (`DEFAULT_ENFORCEMENT.toolGuards`) rather than repeating the
+ * literal: a bare call is "the caller had no mode to hand", and the answer to that must
+ * be the same posture the config would have produced. Two literals are two defaults, and
+ * a helper left on the old `advisory` literal while the config moved to `strict` is
+ * exactly the twin-default hole this change closes — a caller that forgot the argument
+ * would silently get the permissive branch, which no config could then undo. Every
+ * production call site passes the mode explicitly (`index.ts` `runToolGuard`,
+ * `runtime.ts` `guardTool`, the preview tool); this default serves bare callers, and a
+ * bare caller must not be the one place enforcement quietly turns itself off.
+ */
 export function evaluateToolGuard(
   exec: ToolExecLike,
   worktreeRoot: string,
   activeRunId: string,
-  mode: EnforcementMode = 'advisory',
+  mode: EnforcementMode = DEFAULT_ENFORCEMENT.toolGuards,
 ): ToolGuardDecision {
   const name = exec.name
   const args = (exec.arguments ?? {}) as Record<string, unknown>
@@ -258,10 +325,16 @@ export function evaluateToolGuard(
   // T16: the verdict comes from the ordered policy, not from branches here. The
   // policy file is re-read per call on purpose: a policy a human just edited
   // must take effect on the next tool call, not after a restart.
-  const policy = resolveToolPolicyForGuard(worktreeRoot, runId)
-  const context: ToolPolicyContext = { args, runDir, runId, worktreeRoot }
+  //
+  // The ACTIVE phase is resolved ONCE, by the ONE selector, and is used twice: it
+  // selects the phase baseline (narrowing rules) and it is carried into the context so
+  // the phase-order rule can refuse a WRITE that is ahead of the active phase. Both
+  // halves of the ordering rule therefore read the same answer for the same call.
+  const activePhaseArtifact = currentPhaseArtifact(worktreeRoot, runId)
+  const policy = resolveToolPolicyForGuard(worktreeRoot, runId, activePhaseArtifact)
+  const context: ToolPolicyContext = { args, runDir, runId, worktreeRoot, activePhaseArtifact }
   const decision = evaluateToolPolicy(policy, name, args, context)
-  return advisory(verdictFor(mode, decision), transition)
+  return advisory(verdictFor(mode, decision, String(args.artifact ?? '')), transition)
 }
 
 /**
@@ -269,12 +342,35 @@ export function evaluateToolGuard(
  * `advisory` asks (the pre-T16 wording, unchanged), `allow` stays an allow. The
  * decision's `rule` is the label of the rule that decided it, so a policy
  * verdict is traceable to an auditable line in the policy file.
+ *
+ * ⚠ FU-7 — THE ORDERING REFUSAL CARRIES THE HUMAN'S CHOICE. `fix | reopen | abandon` is how a
+ * person unblocks a lock, and before this the ask was attached ONLY by `recursive_lock`'s own
+ * catch — the branch that runs when the guard ABSTAINS. Under the strict default the guard
+ * refuses a lock ahead of its prerequisites BEFORE dispatch, so that branch never ran on the
+ * default path and the caller got a bare sentence: the recovery options existed in the code and
+ * were unreachable in the product, which is worse than the advisory posture they replaced (an
+ * advisory `ask` at least surfaced the reason).
+ *
+ * THE TRIGGER IS THE BLOCKERS, NOT THE LABEL. `PolicyDecision.blockers` is present exactly when a
+ * predicate read prerequisite blockers from disk and they were non-empty, so gating on it means
+ * "this refusal was decided from an ordering violation" — including a policy FILE whose
+ * `recursive_lock*` deny carries no label (the file-authored rule is given the same condition by
+ * `attachPolicyPredicate`, and its `rule` would otherwise read `none`). Nothing is recomputed
+ * here: the blockers arrive from the rule that already resolved them.
+ *
+ * IT IS ATTACHED TO THE REFUSAL ONLY. Under `advisory` the same verdict becomes an `ask` that the
+ * live path coerces to an allow-with-warning, and the tool then refuses with its OWN payload when
+ * `lockArtifact` throws — so an ask attached here would be a claim about a refusal that this layer
+ * did not make. One refusal, one ask.
  */
-function verdictFor(mode: EnforcementMode, decision: PolicyDecision): ToolGuardDecision {
+function verdictFor(mode: EnforcementMode, decision: PolicyDecision, artifact: string): ToolGuardDecision {
   const rule = (decision.rule ?? 'none') as GuardRule
   if (decision.kind === 'allow') return { kind: 'allow', rule }
   const reason = decision.reason ?? 'tool policy denied this call'
-  return mode === 'strict' ? { kind: 'deny', reason, rule } : { kind: 'ask', reason, rule }
+  if (mode !== 'strict') return { kind: 'ask', reason, rule }
+  const blocked = decision.blockers
+  if (blocked === undefined || blocked.length === 0) return { kind: 'deny', reason, rule }
+  return { kind: 'deny', reason, rule, ask: buildGateBlockAsk(artifact, reason) }
 }
 
 /**
@@ -322,10 +418,17 @@ function advisory(decision: ToolGuardDecision, transition: GateCheckResult | und
   if (transition.passed) return { ...decision, transition }
   // The verdict stays `allow`; the gate only names itself as the dissenting
   // voice, so an advisory pass is never silent.
+  //
+  // ⚠ FU-7 (the log fix) — "REPORT-ONLY", NOT "advisory". This sentence travels into the guard's
+  // log line and into the decision a caller reads, and `advisory` there named the GATE's posture
+  // — not the configured mode — while the line around it said `tool guard (advisory)`. Under the
+  // strict default a reader was told enforcement was off while every gate was strict. What is
+  // actually true of this gate in BOTH modes is that it reports and never changes the verdict, so
+  // that is what it now says. The warn-on-allow semantics are untouched.
   return {
     ...decision,
     rule: 'transition',
-    warn: 'transition gate (advisory) failed: ' + transition.failures.join('; '),
+    warn: 'transition gate (report-only) failed: ' + transition.failures.join('; '),
     transition,
   }
 }
@@ -335,8 +438,23 @@ function advisory(decision: ToolGuardDecision, transition: GateCheckResult | und
  * allow. Under `strict` it coerces to `deny`; under `advisory` it stays `allow`
  * but flags a `warn` so the caller never lets it through unlogged. Non-ask
  * decisions pass through unchanged.
+ *
+ * ⚠ THE `mode` DEFAULT IS DELIBERATE, and it is NOT a neutral fallback — there is no
+ * neutral branch here. The domain is two postures, one of which ALLOWS the call, so
+ * "unspecified" has to be resolved rather than left open, and this codebase's rule for an
+ * undecidable path is to fail CLOSED (`index.ts`: *"we could not decide" is not
+ * permission*). It therefore FOLLOWS the config default by REFERENCE
+ * (`DEFAULT_ENFORCEMENT.toolGuards`), for the same reason as `evaluateToolGuard`'s: an
+ * `advisory` literal here would be a second, hidden copy of the old default inside the
+ * very module this change moves, and a future caller that omitted the argument would
+ * re-open the permissive path with no config able to close it. The production call site
+ * (`index.ts` `runToolGuard`) always passes the configured mode, so this changes no live
+ * behaviour — it removes the last place where "we were not told" meant "allow".
  */
-export function coerceAskToDecision(decision: ToolGuardDecision, mode: EnforcementMode = 'advisory'): ToolGuardDecision {
+export function coerceAskToDecision(
+  decision: ToolGuardDecision,
+  mode: EnforcementMode = DEFAULT_ENFORCEMENT.toolGuards,
+): ToolGuardDecision {
   if (decision.kind !== 'ask') return decision
   if (mode === 'strict') {
     return { kind: 'deny', reason: decision.reason ?? 'ask under strict enforcement denies' }

package/src/guard-log.ts

@@ -22,11 +22,17 @@
 import { appendFileSync, existsSync, mkdirSync, readFileSync, writeFileSync } from 'node:fs'
 import { dirname, join } from 'node:path'
 import type { GuardRule } from './enforcement.ts'
+import type { GateBlockAsk } from './recursive_ask.tool.ts'
 
 /**
  * One logged guard decision (the JSONL record shape the board/tests read).
  * `rule` is always set (the guard's own machine-readable reason for the
  * verdict); `transition` is present whenever the transition gate was consulted.
+ *
+ * FU-7: a REFUSAL that a person has to resolve also carries `ask` — the gate-block decision, in the
+ * same shape `recursive_lock` attaches to its own refusal. It is recorded because the log is where
+ * "why was this lock refused?" is answered, and the options are the other half of that answer; a
+ * caller (or a board) reading the trace can act on the refusal without parsing the sentence.
  */
 export interface GuardDecisionRecord {
   at: string
@@ -36,6 +42,7 @@ export interface GuardDecisionRecord {
   rule: GuardRule
   reason?: string
   transition?: { passed: boolean; failures: string[] }
+  ask?: GateBlockAsk
 }
 
 /** One logged observed-write tamper (a LOCKED artifact whose hash no longer matches). */

package/src/index.ts

@@ -22,6 +22,7 @@ import { createRecursiveAuditTeamTool } from './recursive_audit_team.tool.ts'
 import { createRecursiveReviewTool } from './recursive_review.tool.ts'
 import { createRecursiveDelegateTool } from './recursive_delegate.tool.ts'
 import { createRecursiveAskTool } from './recursive_ask.tool.ts'
+import { renderGateBlockAsk } from './recursive_ask.tool.ts'
 import { createRecursivePreviewTool } from './recursive_preview.tool.ts'
 import type { SubagentsRuntimeLike } from './delegation.ts'
 import { registerRecursiveCommand } from './commands.ts'
@@ -187,6 +188,9 @@ function runToolGuard(
       record.reason = final.reason
     }
     if (final.transition) record.transition = final.transition
+    // FU-7: a refusal a person has to resolve carries its options into the trace too, so the
+    // question "why was this lock refused?" and the answer to it are read from one record.
+    if (final.kind === 'deny' && final.ask) record.ask = final.ask
     appendGuardDecision(root, record)
   }
   return final
@@ -512,10 +516,29 @@ export function apply(ctx: Context, config?: RecursiveModeConfig) {
           return { kind: 'deny', reason: 'the tool guard produced no decision' }
         }
         // The guard's own object, returned VERBATIM — the pinned contract.
-        if (final.kind === 'deny') return final
+        //
+        // ⚠ EXCEPT THAT A DENIAL'S `ask` MUST BE CARRIED IN THE TEXT, and this is the one place the
+        // plugin can do it. Measured in the harness (`packages/core/tools`): a `tools/pre-execute`
+        // deny becomes `content: [{ type: 'text', text: 'Error: ' + reason }]` and EVERY other field
+        // of the decision is dropped, so the gate-block payload added for FU-7 would have reached the
+        // model as nothing at all — which is precisely the defect: a strict-by-default guard refusing
+        // a lock with a bare sentence, while `fix | reopen | abandon` was how the run got unblocked.
+        // The sentence is rendered FROM the payload (`renderGateBlockAsk`), so what the caller reads
+        // and what the decision carries cannot drift; the plain reason stays first and intact, so a
+        // caller that ignores the ask still gets the rule name and the blocking artifact.
+        if (final.kind === 'deny') {
+          return final.ask === undefined
+            ? final
+            : { ...final, reason: final.reason + ' ' + renderGateBlockAsk(final.ask) }
+        }
         if (final.kind === 'allow' && final.warn) {
-          // Package-tagged host logging; never a silent pass under approval=never.
-          console.warn('[recursive] tool guard (advisory): ' + final.warn + ' — allowing')
+          // ⚠ IT NAMES THE MODE IT ACTUALLY RAN UNDER. This line used to begin `tool guard (advisory)`
+          // unconditionally, while the warning it carries comes from the transition gate's REPORT-ONLY
+          // consult — which attaches a warning to an ALLOW in BOTH modes. Under the strict default the
+          // line therefore told a reader that enforcement was off while every gate was strict: text
+          // asserting a state that was not so. The mode is read from the same config the guard ran
+          // under, so the prefix moves with the setting; the warn semantics are unchanged.
+          console.warn('[recursive] tool guard (' + recursive.enforcementConfig.toolGuards + ') allowed this call: ' + final.warn)
         }
         return typeof next === 'function' ? next() : { kind: 'allow' }
       }))