Refine staged handoff authorization and output paths; checkpoint project instructions and Node version

.nvmrc

@@ -0,0 +1 @@
+22

AGENTS.md

@@ -0,0 +1,38 @@
+- Before doing anything get general project context by reading README.md and plugins/staged-implementation/README.md
+
+- Always make a Plan before implementing. 
+
+  For example:
+
+  • Updated Plan
+    └ Created an implementation plan for WsLite integration and wiring in Bootstrapper.
+      □ Add WsLite module in brain-core
+      □ Implement broadcast binding (guarded)
+      □ Register WsLite in Bootstrapper
+      □ Set ui_state callback (g_ota_bs)
+      □ Remove stub and adjust flags
+      □ Sanity compile Bootstrapper target
+      □ Update docs on flags/endpoint
+
+- Always favor a clean implementation or fix over a quick fix or bandaid solution
+
+When asked for a commit message always provide a oneline commit message and separate sentences with `;`
+
+When asked to write a markdown file the specified path might contain a date followed by `-${name}` .. e.g. 28.12.2025-${name}.md .. replace ${name} with a suitable name for the document.
+
+You do not ever run any destructive commands unless you have explicitely been asked to do so.
+
+## Change Discipline
+
+- If the prompt is a question and verifying in-repo first would improve answer quality, do so.
+- Treat questions, observations, and suggestions as analysis-only; only implement changes when the user explicitly says to implement/apply a patch.
+- No freeform edits: use apply_patch with ≥3 context lines; keep diffs surgical; do not mix unrelated changes.
+- Use spaces (no tabs) for indentation; keep indentation consistent with surrounding code and avoid whitespace-only churn in diffs
+- Plan discipline: keep update_plan synced; exactly one step in_progress; revise when scope shifts.
+- Ambiguity rule: if any symbol/endpoint/data source is unclear, stop and ask — do not guess.
+- Preserve contracts: do not change public API schemas, event semantics, or observable behavior unless explicitly requested.
+- Minimal glue: add only imports/exports/helpers strictly required for the change; no opportunistic refactors.
+- Validate changes: build/typecheck affected targets and run quick verifications relevant to the edit.
+- No legacy/backward‑compat migrations or auto‑fallback heuristics unless explicitly requested.
+- Do not change route paths, auth checks, or CORS policy unless explicitly in scope.
+- Clean cutover only by default; never implement legacy/dual-format parsing or fallback behavior unless explicitly requested.

plugins/staged-implementation/skills/orchestrator/SKILL.md

@@ -29,8 +29,8 @@ Prefer a task packet containing:
 - commit policy: `authorized-for-accepted-chunks`, `ask-before-each-commit`, or `do-not-commit`
 - stopping conditions
 
-If any required path, contract, data source, validation target, or output location is unclear, stop and ask. Do not guess.
+Resolve required paths and output locations from explicit instructions and established repository/workflow conventions first. For saved prompts, use the identified companion plan/checklist location and a descriptive filename if no narrower convention exists; state the chosen path and do not overwrite unrelated artifacts. Ask when a required location cannot be established or conflicting instructions remain. Do not guess unresolved contracts, data sources or validation targets.
-If commit policy is missing or not one of the supported values, stop and ask. Do not silently choose a safer or more aggressive default.
+Resolve and normalize commit authorization under **Commit Rules** before implementation. A missing literal policy label does not require clarification when existing instructions already establish its meaning.
 
 ## Authority Boundaries
 
@@ -233,7 +233,11 @@ Commit behavior is controlled only by the explicit commit policy. Supported poli
 - `ask-before-each-commit`
 - `do-not-commit`
 
-If the commit policy is missing, stop and ask before starting implementation. Do not infer commit behavior from general intent.
+Resolve the policy from current user instructions, still-applicable earlier explicit authorization for this run, or an unambiguous project/workflow policy. Normalize clear ordinary language into a supported value and record it with its source in the handoff or current execution record. Later explicit instructions take precedence. Do not ask the user to repeat authorization or spell the exact label.
+
+For example, "commit each accepted chunk after validation" authorizes `authorized-for-accepted-chunks`; "ask me before every commit" means `ask-before-each-commit`; "do not commit" means `do-not-commit`. General permission to implement, a hypothetical workflow example, or permission for a single commit does not authorize committing all chunks.
+
+If authority remains missing, conflicting or ambiguous after checking those sources, stop and ask before starting implementation. Do not invent a default. A normalized commit policy does not override a user pause or authorize pushing, publishing or unrelated changes.
 
 For `authorized-for-accepted-chunks`:
 
@@ -270,14 +274,14 @@ Do not commit if:
 - unrelated dirty changes cannot be separated safely
 - the commit policy is `do-not-commit`
 - the commit policy is `ask-before-each-commit` and the user has not approved that specific commit
-- the commit policy is missing or unsupported
+- commit authority remains unresolved or cannot be normalized to a supported policy
 
 ## Stopping Conditions
 
 Stop and report clearly when:
 
-- commit policy is missing or unsupported
+- commit authority remains unresolved after checking current instructions and still-applicable authorization
-- a contract, symbol, endpoint, data source, or output path is ambiguous
+- a contract, symbol, endpoint or data source is ambiguous, or a required output location remains unresolved after checking instructions and established conventions
 - the plan/checklist/prompt map disagree and the correct contract cannot be inferred from written docs
 - the readiness audit has unresolved `blocked-by-contract-decision` items and the user has not authorized a ready-subset run
 - a `needs-small-freeze-before-prompt` decision affects the next implementation path

plugins/staged-implementation/skills/planner/SKILL.md

@@ -242,7 +242,7 @@ When the user asks the planner for a commit message, output a one-line commit me
 
 When asked to write, produce, or prepare an orchestrator prompt, treat it as an official durable handoff artifact, not casual chat output.
 
-Save official orchestration handoff prompts beside the plan/checklist/prompt map unless the user explicitly asks for chat-only output or gives another path. If no output path is clear, ask for the output path before presenting chat-only. Re-read the saved file before finishing.
+Save official orchestration handoff prompts at the user's specified path, or follow the established repository/workflow output location and naming convention. Otherwise, save beside the identified plan/checklist/prompt map with a descriptive filename. State the chosen path; do not ask solely because the user omitted a filename. Ask only if the companion location cannot be established or conflicting instructions leave the destination ambiguous. Do not overwrite an unrelated existing artifact. Honor an explicit chat-only request. Re-read the saved file before finishing.
 
 Every orchestrator prompt must include:
 
@@ -263,12 +263,14 @@ The commit policy must be explicit and must use one of:
 - `ask-before-each-commit`
 - `do-not-commit`
 
-If the user has not specified commit behavior and no project/workflow default exists, stop and ask before saving the prompt. Do not silently choose `do-not-commit`, `ask-before-each-commit`, or `authorized-for-accepted-chunks`.
+Resolve commit behavior from the user's current instructions, still-applicable earlier explicit authorization for this run, or an unambiguous project/workflow policy. Normalize clear ordinary-language instructions to one of the supported values and briefly identify their source in the handoff. The user need not supply the exact label. Later explicit instructions take precedence; do not ask again for authorization already given and not withdrawn.
+
+Ask before saving only when commit authority remains missing, conflicting or ambiguous after checking those sources. General permission to implement, an example of a possible workflow, or permission for one specific commit is not authorization to commit every accepted chunk. Do not silently select a policy merely to avoid asking.
 
 If the user says to orchestrate implementation and their stated workflow preference says the orchestrator should commit accepted chunks, use `authorized-for-accepted-chunks` and include this exact policy text:
 
 ```text
-Commit policy:
+Commit policy: authorized-for-accepted-chunks
 Commits are authorized for accepted chunks only. Commit after each accepted chunk once review and required validation pass. Do not commit unrelated dirty changes. Use one-line commit messages with the chunk ID prefix when one exists.
 ```