sliced-dev

Slice Development

First Principles

First clarify forks, then confirm execution.

• Decision Fork: Requirements, product behavior, user authorization scope, terminology, upstream, acceptance criteria, or record semantics are not unique. The user's answer only confirms the criteria and does not authorize execution; implementation files, test locations, and verification commands are judged by the controller within the authorization boundary.
• Interrogation Choice: Two types of gates trigger — the task-decomposition layer asks about the overall decomposition after the slice list is produced, and the execution-slice layer asks about that slice before candidate-needs-confirmation / cross-module slice review; by default it is always "Recommended: Interrogation". Before asking, the currently identified fork subject must first be shown according to the "Interrogation Display Protocol", so the user knows what will be interrogated, but details must not be expanded in advance. The user must be required, if they wish to make a gate choice, to reply only 拷问 or 不拷问; only when it is exactly equal to one of these two passwords after removing leading and trailing whitespace is it valid.是 / 确认 / 继续 / 好的 Ordinary confirmation words such as are invalid, and the question must be asked again; it cannot be inferred from context. When the user asks a question, supplements facts, or points out a process problem, first answer / handle it, the gate state does not advance, and then the same gate is asked again.
• Interrogation Closure: After the user enters interrogation, the interrogation cannot automatically end just because one question has been answered. When the user's answer forms the unique conclusion for the current fork, immediately write it back to the corresponding D, but keep grilling, and continue handling other identified issues. When there are no more interrogation questions, a "interrogation closure candidate" must be sent, and the user must be told that they can reply 结束拷问 / 继续拷问, and can also directly raise other questions; only 结束拷问 will end the interrogation. If only options are consolidated but no conclusion is formed, after ending the interrogation, move to single-point fork confirmation. When the user replies 继续拷问, asks a question, supplements facts, or points out a process problem, first answer / handle it, keep grilling, and then ask the same closure gate again.
• Execution Confirmation: The slice has no open forks but hits high risk. Send an execution preview and ask "Confirm execution of slice N?". The user's confirmation authorizes the controller to dispatch the implementer subagent within the already stated user authorization boundary, and does not make the task brief's file / verification checklist a user responsibility; if it is interrupted after confirmation but before dispatch, the preview and confirmation must be repeated when resuming.
• Authorization Boundary and Execution Boundary: The user authorization boundary consists of confirmed product behavior, acceptance criteria, API / data contracts, non-goals, explicitly prohibited scope, newly added dependencies, and irreversible external operations; risk and the "needs confirmation" surface are independent execution gates.允许修改, task brief, adjacent tests, mocks, verification commands, and evidence carriers are the auditable execution boundary maintained by the controller. Before adjustment, first rerun the affected context precheck according to the proposed expanded scope; if it is still within the existing authorized goal and does not hit 禁止修改, and when the risk remains A/B, no new "needs confirmation" surface is hit, and no new execution confirmation is required, the controller may record the basis and then automatically update the execution boundary, without creating D and without re-asking the user. Confirm when the user authorizes a boundary change, the risk rises to C, a new "needs confirmation" surface is hit, a new execution confirmation is required, or there are multiple options that genuinely require product adjudication. When the actual diff has already crossed the old brief, first judge the acceptance gate as failed and confirm ownership; do not backfill the checklist to make this round pass; when dirty files are omitted before dispatch, do not add them in afterward 基线脏文件. For details see EXECUTION-RULES.md。
• Terminology conventions: unless explicitly written as 候选需确认片 , in this document 自动片 / 需确认片 all refer to slices of the formal 执行：自动 / 执行：需确认 , not the 候选 label.
• Fork review stage: before each slice is executed, it must first be independently proven that there is "no decision fork". During the review stage, issuing execution previews, requesting execution confirmation, and expanding implementation options are prohibited.
• Global constraints: the global requirement constraints that all slices of this task must inherit and must not violate, written into plan.md top-level ## 全局约束; execution and AI Review must read them.
• Zero known defects closure: when the user explicitly requests "zero known defects closure" or explicitly states that SHOULD defects must also be fixed, write the fixed token into the global constraints - 零已知缺陷收口：enabled. Once enabled, all execution-type slices must complete AI Review; all findings introduced or aggravated by this change (regardless of must_fix / should_fix) must be fixed,cannot_verify must be supplemented with evidence and cleared to zero; defects cannot be closed via risk acceptance, claim waiver, or follow-up. Existing observations that are not aggravated by this change are not automatically expanded into scope. When a fix exceeds the current 允许修改 , first rerun the affected context precheck according to the authorization boundary rules; when no new execution confirmation is required, update the execution boundary and continue; stop when 禁止修改is hit, the user authorization boundary is changed, the risk rises to C, or a new "needs confirmation" surface is hit, and do not mark the slice as done。
• Rule review conclusion binding: when the active catalog is truly empty,项目规则审查：not-applicable and skip rules-review; when the catalog is non-empty, regardless of whether execution-time selectedRuleIds is empty, write required. By default, after the final cumulative General full clean of the current TARGET and the applicable user acceptance are satisfied, create a fresh rules-review v8 run; the rule-review package does not carry execution-time selectedRuleIds / notApplicable / 规则获取at all, and the rule-reviewer independently classifies based on the final TARGET and the complete active catalog.dispatch.ruleSet.selectedRuleRefs is the final review scope,excludedRuleRefs is fixed as empty, shards / finalReview are the review results of the full run; for a non-empty catalog, if the final selectedRuleRefs is empty, still execute a real zero-item run. Except for the rule repair verification limited by the next item, each new TARGET uses a new run; when only the rule protocol or input artifacts are corrected for the same TARGET, only redo rules-review. sliced-dev submits the complete commit scope with --target-commit <headCommit> and keeps excludedFiles: [], without passing --rules-commit. Rule findings are only repaired forward, and historical preflight is not rewritten.
• Rule repair verification: Rule Repair Verification is sliced-dev 's one-hop rule re-verification of "unclosed issues from the preceding complete rules-review + direct repair delta"; it is not part of a rules-review run. This item is the semantic source of truth for its proof obligations, result derivation, and composite proof.
  • Can only be constructed when the immediately preceding full rules-review is caused by a finding / cannot_verify rework, the current TARGET is its direct child commit, BASE and rule identity are unchanged, the current cumulative General full clean and applicable user acceptance are satisfied; rule identity is fixed as the active catalog's index hash and the sealed rule file path / content hash.
  • The inputs include only the failure items of the preceding full, the preceding selected rules, the preceding globally-not-applicable rules, the complete repair delta, and currentTargetCommit the context expanded on demand from the corresponding Git tree / blob. The reviewer can only take the current task and these Git objects as factual inputs; session memory not written into artifacts is not evidence; whether to reuse the reviewer session is not part of protocol semantics.
  • The reviewer only proves three things: adjudicate the old finding item by item / cannot_verify; under the preceding selected rules, review the entire repair delta and its semantic impact and confirm the scope is bounded; determine whether any preceding globally-not-applicable rule has newly become applicable due to the delta.
  • applicabilityExpansion.verdict=none only means there is no review scope expansion, not that the complete applicability partition is bidirectionally unchanged; a preceding selected rule becoming inapplicable is a safe scope contraction. When expansion is found, the newly applicable rule is not reviewed within this re-verification.
  • Unmodified context must not be read from the working tree, index, or current HEAD. Shared helper / type changes must check all statically discoverable callers / consumers; when the static impact scope cannot be proven closed, write scope_unbounded。
  • It does not call or modify rules-review, does not create a run / finalReview, nor inherit the old passed / observation。
  • Result derivation priority is: applicability expansion detected / cannot_verify, non-rework functional changes,scope_unbounded or other cannot_verify → cannot_verify / fresh_full; otherwise any not_addressed or new finding → finding / repair; otherwise only applicabilityExpansion.verdict=none + bounded + 全部 addressed + 无新 finding → repaired / complete。
  • Only "preceding full + this round's repaired / complete repair verification" together constitute the rule proof for the current TARGET; repair verification itself is not the full rules-review of the current TARGET.
  • When derived as repair , the controller writes the issueDispositions in not_addressed and newFindings into the current audit / rework basis, and hands them to the implementer via the next round's task brief; after a new TARGET is formed, execute fresh full directly, without reusing this verification.
  • When construction fails or it is derived as fresh_full , the controller must explicitly re-request the existing fresh full, and must not silently downgrade; this path does not recursively inherit repair verification.
• Default SHOULD accepts: when "zero known defect closure" is not enabled, only when the current run is should_review_before_merge、mustFix=0、shouldFix>0、cannotVerify=0, and the current A*/real user decided D*/Evidence/related items/<runId>#<A-id>#<shouldSetHash>/non-placeholder confirmation records are fully bound, can the fourth verdict alone write passed; A* still retains the rules-review original failed。ready_for_merge still requires all three counts to be 0; zero known defect closure and other recommendations do not borrow this exception. The machine only validates structural binding, and does not judge whether the risk description is sufficient, whether the user understands, or whether the confirmation records are genuine.
• Plan consistency pre-check: after the slice list is produced and before the split interrogation gate, first check whether the entire plan is internally consistent; write only the top-level 计划一致性预检 status, branch into decisions.md, and put long matrices into audits.md, no new plan section is added.
• Context pre-check: before starting, first expose the context that needs to be understood, required reading context, project rule review, allowed / prohibited modifications, non-goals, and stop conditions; do not implement before finishing reading the context. Paths, change scope, and catalog can only produce candidate classifications; only after completing the required reading code for this slice and a focused search targeting rule trigger conditions can execution-time selectedRuleIds / notApplicablebe determined. Previously written classifications must be recalibrated, and candidates that cannot be clearly excluded with code evidence are classified as selected. The two field types only constrain the controller / implementer, not the final rules-review scope; they explicitly exist in any state and are accompanied by reason,selectedRuleIds each item contains only one ID,notApplicable multiple IDs may be separated by commas and share one reason,pending / blocked classification is allowed to not yet be closed. When writing ready , required fields must not still be placeholder content, and the two types must form a complete mutually exclusive partition of the actual catalog; only when the active catalog is empty write not-applicable, otherwise write required and selectedRuleIds may be empty; when rules-review is unavailable write blocked and stop. The controller must also read the selected rules and incorporate each executable obligation into the existing execution contract and resolve conflicts; until this is complete, do not write ready。允许修改 is an updatable execution checklist,禁止修改 is a hard boundary and may explicitly write 无. The full profile writes back to the current slice block, and the lightweight profile outputs a short version in the session.
• Rejection gate: after implementation, the hard gate and package-first AI Review must be run; each slice can be automatically repaired at most 4 times, counted only when files within the actual task scope are modified. A structurally valid negative review conclusion enters repair or blocking and cannot be washed away by reassignment; only when nothing is returned, it is out of scope, or the format cannot be attributed is the same input allowed at most one fresh reassignment, and if it still fails it is blocked. Regenerating the package or fixing protocol artifacts does not count toward the repair count. If it still fails after the count is exhausted, stop.
• Claims / Evidence / Status: for the full profile, each execution slice uses claims/<S-id>.json to record verifiable claims, evidence, and status; Claim is an execution constraint, not a post-hoc summary, and may only state stage facts supported by current evidence, and must not prematurely claim that downstream General, user acceptance, rules-review, or close-check has passed. The controller judges claim status based on evidence; scripts only validate JSON / field shape,close-check only trusts the final status of claims.
• Plan checkpoint: for the full profile, before the first execution-type slice first generates a task brief, first have the execution-ready plan.md、decisions.md、audits.md、claims/*.json pass validate, keep that slice's baseCommit absent and independently commit one pure dev-plans checkpoint P, then write P into baseCommit。task-brief only machine-validates that P is an ordinary single parent, contains only persistent plan files, the required sources of truth exist, and the current persistent plan has not drifted except for baseCommit self-binding; it does not judge whether the plan semantics are correct. The complete execution chain is P → C1 → K1 → C2 → K2 … → Cn → Kn → [F]: after each execution-type done slice's final review passes, create an ordinary single-parent, plan-only K; in K keep the next execution slice's baseCommit absent, and before the next slice's first dispatch write K into that field.split / skipped does not create K.
• Subagent isolation: the current runtime only provides context / role isolation, not workspace isolation. For the full profile's first round use spawn_agent(fork_turns: "none") to dispatch the implementer; for safe repair of the same slice, prefer followup_task Original implementer, only when the original agent is unavailable, the receiving gate confirms it is out of bounds / its output conflicts with the actual diff, or the user authorizes a substantive change to boundaries, task goals, or the Claims contract, does a fresh fallback occur. Extending the execution allowlist within an existing authorization does not by itself trigger a new creation. All agents share the current workspace; only one implementer is allowed to write business files at a time, and the controller and other writing agents must not modify business files before the implementer returns.
• Handoff file: the full profile's fixed dispatch each round first writes back the failed gate or the current A* / open G* repair basis, then follows the task-brief → task-report-template → subagent order; the latest brief overrides the implementer's old context, and subagent memory is not the source of truth.task-briefs/<S-id>.md is the narrow-context entry point and renders the current slice's claims;task-reports/<S-id>.json each round first resets to the default blocked, empty changes, and empty verification, then the implementer fills in the minimal structured handoff.task-briefs/**、task-reports/**、review-packages/** is a reconstructable temporary artifact, kept ignored, and does not enter P / K / F; when recovering from P, first confirm HEAD == P and write P's canonical commit ID into the first execution-type slice baseCommit, then regenerate according to the persistent source of truth; when recovering from K, first confirm HEAD == K, write that K before the next execution slice's first dispatch, then regenerate. Only when this round's report is conclusion: ready-for-review, and the P0/P1 claims have been written by the controller into a reviewable state, can the review-package be generated.
• Review package and TARGET：record-commit successfully write different new headCommit only then migrate TARGET, and immediately invalidate the old current General selector / three verdicts,用户验收：passed, rule verdict / runId;issues retain feedback,skipped and historical A* are retained. On failure or when TARGET is unchanged, do not clear the proof still bound to the same input; when an interruption causes "new range + old proof", the validator rejects it and record-commit first completes recovery. General Review still proceeds by the first cumulative full、finding-focused repair, and the final cumulative after repair full . When the user rejects a new TARGET, use user-acceptance-issues; for a rule finding's new TARGET, use the unique, one-time project-rule-review-issues（A*）, both directly enter the cumulative full and do not fabricate a General finding.
• Artifact role boundaries：plan.md is the source of truth for task state, boundaries, risks, and execution location;claims/<S-id>.json is the source of truth for claims / evidence / state; task brief, task report, review-package, rule-review-package, rule-repair task / verification, and whole-review-package are attention-focusing views or review artifacts, not sources of truth. Focusing views limit the implementer's / reviewer's default attention; when P0/P1 claims, boundaries, evidence, or verdicts cannot be determined from the view, you must focus back to the source: code, tests, diff, or source-of-truth state, and write the evidence back into plan / D/A / claims; package completeness must not substitute for factual judgment.
• User acceptance: after the final cumulative General full passes and the first three verdicts are written back, accept according to PLAN-FILE.md 's conditional field; automatic slices by default do not write this field and continue directly, while confirmation slices / C-type slices must stop. When the user rejects, write issues, reset AI Review and rework; after a new General clean, switch back to pending. Only after acceptance is satisfied does it enter the project rule review path, and only after the fourth verdict is completed is AI Review：passed。
• written for the whole-task review: Disabled by default. Run it only when the user explicitly requests overall acceptance / cross-slice review / release readiness, or when the controller / reviewer determines that single-slice AI Review cannot cover global constraints, cross-slice handoff, non-goal regressions, requirement closure, or residual risks, whole-review-package and add at the top of the plan 整任务审查：package-generated and ## 整任务审查结论; in the end only passed / blocked，blocked and package-generated both block close-check. The whole-task package merges the Review Ranges of each business area, allows exactly one legal K between adjacent ranges, and does not include plan files in changed files or the diff.
• Final close-out：slice-close-check only checks the claims, diff-check, task handoff, General Review, project rule review, and final state of one target execution-type slice, and allows other slices to be incomplete;close-check is the final hard gate for the complete plan. When there is no whole-task review, only if the complete close-check has passed before the final K is created does Kn also serve as F; when there is a whole-task review, first submit Kn, then review, complete close-check, and submit F. If after Kn there are still split、skipped, decisions, or other durable plan changes, also create a separate F; when all slices are split / skipped , still create F after the complete close-check .
• Slice commit: business slices are still committed first and reviewed afterward. The first round of pre-commit-check requires HEAD == baseCommit, and the repair round requires HEAD == previousHeadCommit; it also requires that all task-owned staged / unstaged / untracked paths after excluding the current plan artifacts and recorded baseline dirty files,taskReport.changedFiles exactly matches the staged set, and that there is no unstaged residue, rename escape, allowlist overrun, forbidden path hit, or overlap with baseline dirty files. The controller only stages the report file and creates an ordinary single-parent business commit,record-commit then verifies the parent commit and the commit diff file set; a no-code round does not create an empty business commit, and HEAD remains unchanged. After the final review passes, write back the slice, move the current pointer, run slice-close-check, scoped stage the persistent plan source of truth and run plan-commit-check、git diff --cached --check, then create K. K / F are only allowed to include the current plan's plan.md、decisions.md、audits.md、claims/*.json and genuinely changed dev-plans/.gitignore; the commit message complies with the commit message conventions applicable to the current repository, and sliced-dev does not prescribe type, scope, subject, or body. For commit boundaries see EXECUTION-RULES.md。

When a decision fork is found, issuing an execution confirmation is prohibited; an execution confirmation cannot replace requirement clarification. When the user answers "continue / keep / confirm", interpret it only according to the question just asked, and do not treat it across stages as a fork conclusion or execution authorization; if what was just asked is an interrogation choice, such ordinary confirmation words are invalid and the fixed passphrase must be asked again; if what was just asked is interrogation closure, only 结束拷问 will close it, and继续拷问 or direct questions all keep it in the interrogation state.

Tier

• Lightweight: can be completed within the current context, all are "automatic" slices, and does not require cross-context recovery, subagent context isolation, an independent review-package, per-claim evidence closure, or close-check (such as a single file / copy / local style / clear small bug) -> first output a short-form context precheck in the session, then directly do it + verify after modification; B-class must run AI Review; no slicing, no recording, no gate state machine, no automatic commit. When judged as C, hitting a "needs confirmation" surface, or exceeding bounds for the second time on the same task, stop and switch to the full tier. For details see EXECUTION-RULES.md "Lightweight Tier Execution".
• Full: when any control requirement is hit, follow the full process: the user explicitly initiates /sliced-dev、resume an existing run dev-plans、contains any "needs confirmation" / Class C / high-risk contract slice, is expected to span contexts, requires a subagent context-isolation implementation, requires an independent review-package, requires a per-claim evidence closed loop or close-check. Merely being "medium-to-large / cross-module" is not a sufficient condition; only when it leads to the above control requirements does it enter the full tier.

Interrogation layering

Interrogation is divided into two layers that do not replace each other and each manage their own deliverables:

• Task decomposition layer: addresses "how the task is understood and how the whole is split". Before the checklist takes shapebefore, the requirement / scope / terminology / upstream-caliber divergences follow the interrogation choice of the "Divergence Handling Protocol"; after the checklist takes shapeafter, the overall decomposition structure follows the "Decomposition Interrogation Gate".
• Execution slice layer: addresses "how a selected slice is specifically done, and whether there are divergences". The interrogation entry point for candidate slices needing confirmation / cross-module slices is the "Pre-slice Interrogation Gate";候选需确认 is only a risk prediction at the slicing stage, not equivalent to the final 执行：需确认. Low-risk candidate automatic slices may skip this gate, but if the review finds a divergence for the first time, the interrogation choice for that slice must first be补asked. After the interrogation gate for that slice has been asked, a divergence found at the review stage goes directly to divergence confirmation, without re-asking the interrogation.

Divergence Handling Protocol

When a decision divergence is found at the task-level gate, slicing, or pre-slice divergence review, they share the same skeleton of verify, write back, and rerun, rather than each stage writing its own set of question formulations:

1. First verify, converging into one minimal divergence; do not ask the user about things that can be resolved via code, files, git status, or upstream materials.
2. Write into decisions.md of D*, recording only "status / association / evidence / recommendation / question"; the "question" here is a divergence conclusion that may need to be asked later, not something to immediately throw at the user; long evidence uses A* to write into audits.md。
3. Whether to first ask the interrogation choice is determined by the layer it is in:
   • Task decomposition layer(task-level gate / slicing): first output a choice preview according to the "Interrogation Display Protocol", then stop and ask "Enter interrogation? Please reply: interrogate / do not interrogate.".
   • Execution slice layer(pre-slice divergence review): if the interrogation gate for that slice has already been asked, do not re-ask the interrogation and go directly to step 5; if a low-risk candidate automatic slice skips the gate and then finds a divergence for the first time, first补ask the interrogation choice for that slice.
4. When the user replies 拷问 , choose tools to compact the divergence according to the "Interrogation Execution Method"; after entering interrogation it must pass the closing gate, and only 结束拷问 will end the interrogation,继续拷问 or directly asking a question keeps the interrogation state. After each specific divergence forms a unique conclusion, immediately enter step 6 to write back, but do not end the interrogation; if at the end of interrogation only options have been compacted and no conclusion has been formed, enter step 5.
5. When the user replies 不拷问, is in the execution slice layer where the interrogation is not re-asked, or after ending the interrogation no unique conclusion has yet been formed, only then ask one divergence conclusion according to the specific question format of the "Interrogation Display Protocol".
6. After writing back the conclusion, change the D status to decided and synchronize the related slice association items; still in grilling then continue to the next identified issue; when there are no more issues, output "interrogation closure candidate"; otherwise, return to the stage that triggered this branch and rerun the gate (branches discovered during the slicing stage return to the task-level branch gate). Until the branches are cleared to zero, do not slice, do not assess risk, and do not issue an execution notice.

Interrogation Display Protocol

Every user-visible interrogation output must first mark the interrogation target with a separate quotation line:

• Task-level branches before the checklist is formed:> 拷问对象：任务口径
• Breakdown interrogation:> 拷问对象：整体拆分方案
• Slice interrogation:> 拷问对象：切片 <S-id>「<切片标题>」

The interrogation choice preview, each round's specific question, and the interrogation closure candidate must all repeatedly display the current target; the user must not have to guess which entry point they are at based on the question content, conversation order, or 当前切片 pointer. This line only identifies the target the user is reviewing, and does not display D numbers, gate status, or interrogation progress.

Before the interrogation choice, display only the currently identified branch subject, without expanding the evidence, options, or impact details of each question:

> 拷问对象：<按当前入口填写>

### 可能需要确认的内容

- <分叉主体的一句话概括>

### 推荐选择

建议拷问。<一句推荐理由>。选择 `不拷问` 只跳过拷问式展开；无法自行查证的未决分叉仍会逐个直接确认。

### 请确认

是否进入拷问？请回复：拷问 / 不拷问。

The branch subject is distilled from the specific issues already verified in the current open D, plan consistency precheck, or slicing prescreen; write only the subject content the user needs to understand the interrogation target, do not display D numbers, status, category, evidence index, total number of questions, or interrogation progress, and do not write issues that have not yet been identified as known issues. When there is currently no clear branch, truthfully state "no clear branch is currently identified" and write in one sentence the specific target that the interrogation will continue to examine.

After entering interrogation or directly confirming a branch, display only one self-contained question per round, fixed as:

> 拷问对象：<沿用当前入口>

### 背景与分歧

<说明相关事实，以及为什么仍需确认。>

### 选择影响

<说明各个实际选择会改变什么。>

### 推荐方案

<给出推荐答案和理由。>

### 请确认

<只问一个具体问题。>

The user side does not display D numbers, status, category, evidence index, or interrogation progress; these are written only to dev-plans. Complete evidence remains in D/A; the question body carries only the minimum facts needed to understand and answer the current question.

Interrogation Execution Method

After the user chooses interrogation, prefer using the existing interrogation skill, and do not substitute ordinary Q&A:

1. When the user explicitly specifies grill-me、grill-with-docs or another review method, execute as specified by the user.
2. When unspecified but synchronous write-back to documents, plans, upstream basis, ADR, or semantic records is needed, prefer using grill-with-docs。
3. When unspecified and only design / requirements / behavior branches need to be compacted, prefer using grill-me。
4. Only when these two skills are not applicable or unavailable, use the ordinary interrogation follow-up within the current skill.

During interrogation execution:

• Each round asks only one specific question per the "Interrogation Display Protocol"; the user's answer is interpreted only as the answer to that question, and does not mean the interrogation has ended, other branches are cleared to zero, or execution is authorized.
• If there are still uncompacted issues, continue to the next round of interrogation.
• After entering interrogation, if the current entry point has a corresponding gate field, set 拆分拷问 / slice 门禁 as grilling。
• When the user's answer forms the sole conclusion for the current branch, immediately write it back to the corresponding D and synchronize the related slice association items, but keep grilling; if the answer produces sub-branches, continue handling the current question.
• When it is determined that there are no more questions, keep grilling, output the "interrogation closure candidate", list the compacted conclusions and remaining risks, then stop and ask: "End the interrogation? You may reply: end interrogation / continue interrogation; if there are other questions, you can also ask directly. Ending the interrogation only ends the interrogation method, and does not close unresolved branches."
• After the user replies 结束拷问 , close according to the current entry point: for breakdown interrogation write 拆分拷问：grilled and enter the first slicing process; for pre-slicing interrogation write that slice's 门禁：grilled and enter the pre-slicing fork review; if in fork handling there is still a D that has not formed a unique conclusion, transfer to single-point fork confirmation in the specific question format.结束拷问 Do not repeatedly confirm a D that has already been written back.
• After the user replies 继续拷问 , keep grilling, and continue grilling.
• When the user directly asks a question, supplements facts, or points out a process problem, first answer / handle it, keep grilling, then re-ask the closure gate.
• When the user replies with other content that has no clear meaning, do not update the gate status, do not enter fork review or execution confirmation, and only re-ask the closure gate.

Split grilling gate

After the slice list is produced and passes the plan consistency precheck, and before entering the first slice, first use > 拷问对象：整体拆分方案 to mark the current entry point, then according to the "Grilling Presentation Protocol" present the content in the overall split that may currently need confirmation and ask once (triggered in the full profile, not asked in the lightweight profile; the whole task asks only once): "Enter grilling? Please reply: grill / no grill."

• The object is thestructureof a finalized split plan: whether slice boundaries, inter-slice dependencies, and candidate labels are reasonable; do not re-ask calibration forks that were already handled before the list was finalized.
• This is a choice of review method, not a fork conclusion, and not execution authorization.
• When the user replies 拷问 , compact the split according to the "Grilling Execution Method"; after passing the 结束拷问 / 继续拷问 closure gate, write 拆分拷问 as grilled, write the conclusion back to the dev-plans slice list, then enter the first slice process.
• When the user replies 不拷问 , write 拆分拷问 as no-grill, then enter the first slice process; if that slice hits the "Pre-Slicing Grilling Gate", handle it according to that gate, and low-risk candidate automatic slices may be skipped.
• When the user reply is not 拷问 or 不拷问 , do not update the gate status and do not enter the next stage; if the user is asking a question, supplementing facts, or pointing out a process problem, first answer / handle it, then re-ask the same grilling choice.
• If the grilling before the list was finalized has already covered the overall structure, the agent may annotate the reason, but still requires the user to reply 不拷问 before skipping this gate.

Pre-Slicing Grilling Gate

After selecting candidate slices that need confirmation, cross-module slices, or user-requested slices, and before entering the pre-slicing fork review, first use > 拷问对象：切片 <S-id>「<切片标题>」 to mark the current entry point, then according to the "Grilling Presentation Protocol" present the content in that slice that may currently need confirmation and ask once: "Enter grilling? Please reply: grill / no grill." This is the execution of slice-layer grillingonly entry point, and occurs before the agent determines "no fork".

• This is a choice of review method, not a fork conclusion, and not execution authorization.
• When the user replies 拷问 , compact the boundaries first according to the "Grilling Execution Method"; after passing the 结束拷问 / 继续拷问 closure gate, write that slice's 门禁 as grilled, write back only stable conclusions that affect scope, risk, verification, or handoff, then enter the pre-slicing fork review.
• When the user replies 不拷问 , write that slice's 门禁 as no-grill, only then does the agent enter the pre-slicing fork review and output a no-fork / fork-found conclusion.
• After the gate is closed, do not directly treat 候选需确认 as 执行：需确认The formal execution mode only forks before slicing and writes back after the review has no open forks, the context precheck is complete, and the risk has been re-judged. If the re-judgment is A/B and no confirmation surface is hit, you may write 执行：自动; if the re-judgment is C or a confirmation surface is hit, write 执行：需确认。
• If the user's reply is not 拷问 or 不拷问 , do not update the gate status and do not enter fork review or execution confirmation; if the user is asking a question, supplementing facts, or pointing out a process problem, first answer / handle it, then ask the same grilling choice again.
• For a slice of this gate that has already been asked, when a fork is found during the review phase, directly enter fork confirmation (ask for the fork conclusion according to the "Fork Handling Protocol") and do not ask the grilling question again.
• Low-risk candidate automatic slices may skip this gate; if maintaining dev-plans, write that slice's 门禁 as not-applicable. Then directly output a brief fork review; if the review finds a fork for the first time, first ask the slice's grilling choice as a follow-up.

advance full grilling

When the user explicitly requests 提前全部拷问 / 全量提前拷问 , after the grilling is closed out and before executing the first slice, first pre-screen all executable slices in slice order, and grill in advance the slices that need grilling:

• This is the fork convergence mode before execution and does not add a plan field; while it is in progress, write 当前状态 's 下一步 as advance full grilling and its completion conditions, and use it to identify this mode when resuming, but decide the recovery action only based on each slice's 门禁 .
• Candidate automatic slices are pre-screened first; when there is no fork, the boundary is clear, and the verification criteria are clear, write 门禁：not-applicable, and do not enter real grilling.
• Candidate slices requiring confirmation are grilled in advance by default; when pre-screening a candidate automatic slice finds a fork, unclear risk, or unclear verification, first change it to 候选：候选需确认, then grill it in advance.
• For slices that need grilling, the user's advance full grilling request is equivalent to having chosen 拷问, and you no longer ask slice by slice about 拷问 / 不拷问; but each slice's grilling close-out must still wait for 结束拷问 / 继续拷问。
• Advance full grilling handles only one executable slice at a time; when entering a slice's grilling,当前切片 must point to that slice, and at most one executable slice in the same plan may be 门禁：grilling. When resuming, if there is a grilling slice, first resume that slice's grilling close-out; if there is no grilling, then process the next pending-grill slice in slice order.
• The advance phase only does pre-screening, grilling, stable-conclusion write-back, and necessary fork handling; it must not generate task-brief or claims, and must not enter context precheck or implementation.
• After the advance grilling is closed out, if there is no longer any open fork, the boundary is clear, and no high risk is hit, it is allowed to change 候选需确认 to 候选自动; when subsequently executing that slice, still write the formal 执行：自动 / 需确认。
• according to the context precheck and risk judgment. If advance grilling finds that a slice is too large or its boundary is unclear, splitting the slice is allowed; mark the parent slice as split and use 替代切片 to bind slices that exist and are descendants of the parent slice; newly added and affected slices re-enter the advance full grilling queue, and unaffected slices that have already been closed out are not rerun.
• For all executable slices, 门禁 are no longer pending-grill / grilling and there is no open D; by default, pause at the plan confirmation checkpoint: write 状态：paused、阶段：executing、当前切片：<按计划顺序选择的首个未终态、依赖已满足的可执行切片；不得沿用最后一个 grilling 指针>、下一步：提前全量拷问已完成；等待用户审查 / 提交计划，或明确继续执行 <S*>（<S*> 为正常执行顺序中的首个可执行片）, the user side explicitly states that "the advance full interrogation has been completed"; report the confirmed stable conclusions, residual risks, and suggested next slice, without showing intermediate gate statuses, candidate labels, D identifiers, question counts, or per-slice interrogation progress; if there is still a subject requiring user adjudication, keep or create an open D, and do not enter this completion checkpoint. Only when the user explicitly requests continued execution should you return to the normal execution flow of the current slice; if the user, when triggering the advance full interrogation, has already explicitly requested continued execution after completion, you may report the summary and then continue. During subsequent execution, if code facts or upstream changes cause a new fork, still handle it according to the "Fork Handling Protocol".

Complete flow

1. Opening audit
   • Read existing dev-plans/、git status --short -uall, the current slice code, and upstream.
   • For complete-file continuation, prefer using roster to view the slice overview,show current to load the plan header and current slice block, rather than reading the entire plan.md; the 下一步记录（未校验） in the output is only a locator hint, not proof of a valid action; continuation actions are determined by the current stage, current slice, gates, and open D; D/A in related items are still read from the main text according to the rules (commands see SCRIPTS.md）。
   • At the same time, scan decisions.md for Ds that are still open ; if slices have been produced but an open D is not attached to any slice 关联项, first fix the record or return to the task-level fork gate; do not directly continue the current slice.
   • Identify 计划一致性预检、拆分拷问 and the 门禁 status of each slice; when the plan consistency precheck has not passed , you cannot enter split interrogation or execution.
   • 当前切片 can only point to an executable slice; if it points to a split parent item,done / skipped terminal state,待定 , or a nonexistent ID, first fix the record before continuing.
   • Report the file tier and whether to maintain dev-plans。
2. task-level fork gate
   • Determine whether the task-level 任务内容, impact scope, exclusion scope, upstream, and acceptance are sufficient to enter slicing.
   • Also determine whether there are unconfirmed points that would change the user authorization boundary, acceptance criteria, or risk label.
   • First investigate what can be solved by searching, reading code, or checking file / git status; do not throw investigable questions to the user.
   • If task-level forks remain, invoke the "Fork Handling Protocol"; do not enter slicing before task-level forks are cleared.
3. Slicing
   • Only refine already confirmed goals; do not use slicing to fill in requirement criteria.
   • Each slice is end-to-end and independently verifiable; record 任务内容, acceptance, dependencies, candidate labels, and execution control fields.
   • For stable cross-slice input / output, only write the current slice optional #### 切片交接; do not establish a top-level interface registry. Ordinary 依赖：S* does not mandatorily trigger a handoff subsection.
   • Split by business result, not by code shape; do not write slices as "extract helper / add fallback / new common utils / normalize".
   • If during slicing you find upstream ambiguity, conflict, omission, or the user authorization boundary / acceptance criteria / risk label is not unique, invoke the "Fork Handling Protocol" and return to the task-level fork gate.
   • If before execution or during execution you find that a single piece is too large, causing the user authorization boundary, acceptance criteria, or risks to be unclear, stop first and suggest splitting it smaller; when these contents change, re-enter the fork gate. When only adjusting implementation files, adjacent tests, or verification commands, update the execution boundary according to the authorization boundary rules.
   • After splitting the parent piece, write 状态：split and structured 替代切片 references; when a stable decision makes clear that this piece will no longer be executed, write 状态：skipped and a 跳过依据pointing to the decided D. Both terminal states must first close out this piece's gate, and free-text notes may not be used to replace structural references.
   • During the slicing phase, only candidate labels are given; formal 自动 / 需确认 conclusions must be determined after the pre-slicing fork review passes.
   • Candidate labels:
     • Candidate automatic: expected low risk, can subsequently be automatically done + automatically verified.
     • Candidate needs confirmation: expected to possibly hit a confirmation-required surface, and must subsequently first pass the pre-slicing interrogation gate and fork review; it is not the final execution mode.
4. Plan consistency pre-check
   • Execute after the slice list is produced and before the split interrogation gate; check whether the overall goals / non-goals, global constraints, terminology, legacy behavior coverage, inter-slice dependencies, slice handoff, candidate risks, verification criteria, D/A associations, and dependency graph are mutually consistent.
   • When there are no issues, write 计划一致性预检：passed; when a conflict is found that requires the user to decide, write blocked（D*） and handle it according to the "Fork Handling Protocol"; for long evidence or matrices, write A*。
   • The pre-check is a gate action, not a plan section; it is forbidden to write the inspection flow, Q&A process, or complete matrix into plan.md。
5. Split interrogation gate
   • 计划一致性预检：passed After that and before entering the first slice, ask once about the overall split plan (full level; once for the entire task), see "Split Interrogation Gate" for details.
   • If the interrogation has already covered the overall structure before the list takes shape, the reason may be annotated, but the user is still required to reply 不拷问 before skipping.
   • When the user requests all interrogations in advance, after the split interrogation is closed out, first enter "Advance Full Interrogation", and after completion default to stopping at the plan confirmation checkpoint; only after the user explicitly says to continue execution do you enter first-slice execution.
6. Pre-slicing fork review
   • After selecting the current slice, first stop at the "Fork Review Phase"; slices marked as needing confirmation / cross-module slices must first pass the "Pre-Slicing Interrogation Gate".
   • Even if the current slice 关联项 is empty, it must still be re-judged according to the current code and upstream.
   • For the output form, review items, and return flow after a fork is found, see EXECUTION-RULES.md。
   • After the review finds no fork, enter the context pre-check.
7. Context pre-check and Claims
   • Only update the current slice #### 上下文预检, execution control fields, and claims/<S-id>.json, without changing business code.
   • Write down risks A/B/C, must-read context, project rule review, allowed modifications, forbidden modifications, non-goals, and stop conditions, and verify 全局约束 with the current slice 切片交接。
   • First form candidates from the path, change scope, and catalog; after reading must-read and completing a focused search targeting rule trigger conditions, recalibrate the execution-time classification, and categorize as selected any candidate that cannot be clearly excluded with code evidence. Only then can you update 上下文预检：ready；需理解、必读上下文、允许修改、非目标、停止条件 must not still be 待执行前补充、TBD、TODO、待补充、未填写 and other placeholder content;项目规则审查 Explicit status and complete mutually exclusive classification must be written according to the active catalog cardinality: only an empty catalog is not-applicable, a non-empty catalog is required and selectedRuleIds may be empty, when rules-review is unavailable it is blocked. According to 规则获取 read the selected rules, map executable obligations to existing 允许修改 / 禁止修改, verification, claims, stop conditions or gate records and resolve conflicts before writing ready; do not copy the rule text. When context is insufficient, obligations have not yet been consumed, or conflicts are unresolved, write pending / blocked and stop; when the current execution checklist is insufficient, first decide according to the authorization boundary rules whether to auto-update or stop for confirmation.
   • Before generating the task brief, create or refine claims/<S-id>.json; claims must cover at least the key items among behavior, boundaries, verification and residual risk.
   • If the current slice is the first execution-type slice in the planned order, first let the execution-ready plan pass validate, keep that slice baseCommit absent, only stage the persistent plan source of truth and create checkpoint P; then write P into that slice's baseCommit. If the plan materially changes before the first slice's first dispatch, resubmit P and take the latest P as authoritative. Subsequent execution-type slices keep baseCommit absent until before first dispatch, then verify that the current HEAD is the previous execution slice's headCommit direct, ordinary single-parent, plan-only child commit K, and write that K; plan updates for the current slice produced before first dispatch remain uncommitted, are persisted by the current slice's final K, and no extra plan commit is inserted.
   • Category C slices must stop and wait for human confirmation after outputting the proposal; the proposal is merged into the execution preview, and proposal confirmation and execution confirmation are the same pause.
8. Execution and gates
   • Automatic slice: prepare claims → first slice commits P and records baseCommit, subsequent slices record K before first dispatch → task-brief → implementer → acceptance / hard gates → update claims → business commit / record-commit → General first full / necessary repair / final cumulative full → write the General A* selector and the first three verdicts → when automatic and per-slice acceptance is not enabled, continue directly → for a non-empty active catalog, execute the project rule review (default fresh full; only for direct rule repair TARGET attempt internal repair verification), skip only for a truly empty catalog → write the fourth verdict → AI Review：passed → write back done and move the pointer → slice-close-check → plan-commit-check / staged diff check → K → report → next slice.
   • Slices requiring confirmation: after completing the first three verdicts via the same implementation and General flow, write 用户验收：pending and stop; only after the user passes or explicitly marks skipped may you enter the project rule review path, write the fourth verdict,AI Review：passed, then close out via the same slice-close-check and K commit flow. If the user rejects and the authorization scope / acceptance criteria are not changed, write issues and rework; a new TARGET enters cumulative full directly via user-acceptance-issues , and after clean, write again pending. After the execution preview, if the authorization boundary or the confirmation-required surface changes, you must re-preview and re-confirm.
   • For implementer rework, first write back the current failed gate, General Review A* / open G*,用户验收：issues（<原因>） or project rule review A* / rulesReviewReport, then refresh the task brief, reset the task report, and prioritize followup_task the original implementer. After a rule finding produces a new TARGET, use project-rule-review-issues（A*） Directly execute the new cumulative General full; then prioritize trying the sliced-dev internal repair verification. When the impact scope cannot be reliably constructed or delimited, explicitly request a fresh full. Rules protocols / input artifact corrections for the same TARGET only redo rules-review.
   • AI Review：passed Must satisfy the "AI Review Conclusion" of PLAN-FILE.mdthe complete four verdicts,Status / Severity combinations, and completion-state constraints defined. When any blocking item exists,项目规则审查 is still blocked, not all claims are verified / waived, the user acceptance for confirmation-required / Class C slices has not reached that section's completion-state constraints, the automatic repair count is exhausted while gate failures remain, the risk is elevated to C, it hits 禁止修改, the execution checklist expansion would change the user authorization boundary, a newly hit "confirmation required" surface appears, or a new execution confirmation is needed, the slice cannot be marked done, and work must stop and be reported.
9. Closing
   • After each execution-type slice is written back to a terminal state, first run slice-close-check, then perform K allowlist scoped stage, run plan-commit-check and git diff --cached --check , and commit K;split / skipped does not create K.
   • Before the final closing of an ordinary task, run the complete close-check; it rechecks the terminal states of the top and slice interrogations,split / skipped the structured closure basis, the diff-check gate evidence of done slices, the claims JSON shape, the task brief / task report / review-package, the commit binding of required rule reviews, and the enabled whole-task review package; it does not accept only hand-written terminal-state fields.
   • For tasks requiring whole-task review, the controller generates whole-review-package for cross-slice review, and updates 整任务审查 first to package-generated; after the review passes, write 整任务审查：passed and the fixed five-verdict table; when blocked, write 整任务审查：blocked, write the Evidence as the review-package section or file path, and write the blocking explanation in the body.
   • Cross-slice rule reviews are not stuffed into a single-slice rule-reviewer; when needed, convert to whole-task review or an independent rules-review.
   • When there is no whole-task review, the last execution slice may concurrently serve as F only if the complete close-check has passed before commit; otherwise, after the complete close-check , create another F. When there is whole-task review, it is fixed as Kn → whole-review → complete close-check → F. Any new durable plan change after Kn also creates another F; a full split / skipped plan without K also creates F after the complete close-check .
   • Validation commands, failure / skip explanations, completion reports, and dev-plans commit boundaries are described in EXECUTION-RULES.md。

Fork Quick Reference

Hitting any one item = a decision fork exists; handle it according to the "Fork Handling Protocol" and do not send an execution preview:

• The old implementation has observable behavior, and the new plan does not clarify whether it is included.
• The observable behavior of the old implementation has not been traced to the call chain, asynchronous waiting, failure propagation, or side-effect boundaries.
• A word may refer to different business concepts, entry points, hosts, pages, or capabilities.
• There are multiple reasonable options for the request, type, state, route, entry point, or public export that would change external semantics; differences only in internal file locations are judged by the controller.
• The same sentence's failure semantics may correspond to different observable results (such as local reject, blocking entry initialization, silent degradation).
• Upstream documents, plans, global constraints conflict with the current code.
• The user-authorized scope of impact / exclusions cannot be clarified down to product behavior, contracts, non-goals, or hard boundaries; the list of implementation files is maintained by the controller.
• The acceptance criteria are not unique, or verification requires changing already-confirmed acceptance criteria / risk labels; merely adding directly related tests or verification commands does not constitute a fork.
• dev-plans 's record status affects cross-session audit semantics.

Record

When a full-file control requirement is hit, maintain the cataloged dev-plans/; otherwise only use the session Task list. Default structure of the full file:

dev-plans/
  .gitignore
  YYYY-MM-DD-<slug>/
    plan.md
    decisions.md
    audits.md
    claims/          # 每片结构化 Claim / Evidence / Status 真源，提交入库
      S1.json
    task-briefs/      # 生成文件，gitignore
    task-reports/     # implementer 结构化交付报告，默认 S*.json，gitignore
    review-packages/  # 生成文件，gitignore

For a new full file, preferentially use node <sliced-dev-skill-dir>/scripts/dev-plan.mjs init ...; after structural or status modifications and before slice submission, run validate。

Records fall into only three categories: state machine process, evidence, and fork conclusions. State machine process records only the current state, plan consistency pre-check status, gate status, slice status, and next steps; evidence records code facts, call chains, matrices, and command results; fork conclusions record only stable criteria that will constrain subsequent execution. It is forbidden to write "what the user replied, when validate was run, when interrogation was entered / ended, what actions the agent took" as fork conclusions or audit conclusions; these are process and can only be carried by status fields, gate fields, verification summaries, or session replies. Criterion: if deleting a conclusion does not change subsequent boundaries, scope, risk, or verification method, do not write it as a conclusion.

Rule file routing

Current action	Required reading
Create / resume full-file dev-plan	PLAN-FILE.md
Create / modify slice block, current state, verification summary	PLAN-FILE.md
Create / modify whole-task review conclusion	PLAN-FILE.md
Create / modify claims/S*.json	PLAN-FILE.md、SCRIPTS.md
Create / modify / confirm D*	DECISIONS-FILE.md
Create / modify / reference A*	AUDITS-FILE.md
Create plan directory or check structure	SCRIPTS.md
On resume, load the current slice / view slice overview (show / roster）	SCRIPTS.md
Execute slice, context pre-check, claims preparation, task brief / task report, hard gate, review-package, AI Review, commit, verification	EXECUTION-RULES.md
Dispatch implementer subagent or receive implementation results	IMPLEMENTER-SUBAGENT.md
Dispatch reviewer subagent or write back AI Review conclusions	REVIEWER-SUBAGENT.md

When upstream basis judgments, suggestions, or modifications are involved, project rules and the corresponding upstream materials must first be read, then handled according to the hierarchical constraints of those materials.

Supplementary rules

Pre-slice fork review summary items, context pre-check, lightweight execution, risk boundaries, hard gate, review-package, AI Review, limited fix loop, upstream linkage, execution preview and completion report details, verification commands see EXECUTION-RULES.md。