easy-coding-harness 0.7.1 → 0.8.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "easy-coding-harness",
-  "version": "0.7.1",
+  "version": "0.8.0",
   "description": "CLI scaffold for installing Easy Coding harness files into agent-native directories.",
   "repository": {
     "type": "git",

package/templates/common/bundled-skills/ec-meta/references/local-architecture/README.md

@@ -47,8 +47,9 @@ analysis, workflow operation). The CLI never analyzes the project.
 (user abort, no memory flow). INIT → ANALYSIS and completed MEMORY → COMPLETE are restricted
 automatic edges. A validated read-only `doc` / `analysis` / `report` task also auto-completes
 from IMPLEMENT after its full deliverable is shown, without REVIEW, VERIFICATION, MEMORY, or
-task memory. Other stage edges record `task.json.pending_transition` and require explicit user
-confirmation; code tasks may skip REVIEW and enter VERIFICATION directly. VERIFICATION remains
+task memory. Confirm mode controls non-mechanical edges: approve confirms each edge, guard
+confirms two critical gates, lite uses the same gates but forces IMPLEMENT -> VERIFICATION,
+and auto advances legal edges automatically. Lite never enters REVIEW. VERIFICATION remains
 the code-task fresh-evidence hard gate, and MEMORY keeps the conditional long-memory threshold
 gate. The active task
 pointer lives in `sessions/{ppid}.json`;

package/templates/common/skills/ec-implementing/SKILL.md

@@ -123,9 +123,10 @@ let sub-agents re-dispatch each other.
 
 - **Code task:** after all units are done and self-audited, hand back to ec-workflow. In approve
   mode it records IMPLEMENT -> REVIEW as the recommended pending edge and presents REVIEW /
-  skip to VERIFICATION / handoff. In guard/auto it automatically enters REVIEW.
+  skip to VERIFICATION / handoff. In guard/auto it automatically enters REVIEW. In lite it
+  automatically enters VERIFICATION and must not dispatch REVIEW.
 - **No-code read-only task:** after recording the successful result and showing the complete
-  deliverable, request COMPLETE in approve mode or auto-transition in guard/auto. Do not
+  deliverable, request COMPLETE in approve mode or auto-transition in guard/lite/auto. Do not
   enter REVIEW, VERIFICATION, or MEMORY; do not write short or long memory. The state API only
   accepts this terminal edge when the latest plan is `single` with `files:[]` and the latest
   result has `changed_files:[]`, a non-empty `deliverable`, and no issues/needs_attention.

package/templates/common/skills/ec-memory/SKILL.md

@@ -5,7 +5,7 @@ description: MEMORY-stage skill — archive flow entered after a green VERIFICAT
 
 # ec-memory — archive what was learned
 
-ec-workflow dispatches you during MEMORY after approve/guard acceptance or an auto-mode green
+ec-workflow dispatches you during MEMORY after approve/guard/lite acceptance or an auto-mode green
 VERIFICATION gate. Inputs: the task's `dev-spec.md`, `execution.jsonl` (the `result` and
 `verify` records are precise source material), the changed-files list, existing memory files.
 Read-only `doc` / `analysis` / `report` tasks auto-complete from IMPLEMENT and never enter

package/templates/common/skills/ec-reviewing/SKILL.md

@@ -9,6 +9,7 @@ ec-workflow dispatches you when code IMPLEMENT finishes. Read-only `doc` / `anal
 tasks auto-complete from IMPLEMENT and never enter REVIEW. You judge the code change set and
 return a verdict that drives the next transition. Inputs: the changed files (from
 execution.jsonl `result` records), `dev-spec.md`, `.easy-coding/RULES.md`, `test-strategy.md`.
+Lite-mode code tasks never enter REVIEW; they proceed from IMPLEMENT to VERIFICATION.
 
 Communicate with the user in the user's language.
 

package/templates/common/skills/ec-task-management/SKILL.md

@@ -23,7 +23,7 @@ panel", not just the unfinished task list. On every invocation:
    - `session_confirm_mode` (`project default` when null)
    - `effective_confirm_mode`
 4. Show the supported conversational changes in the user's language: set this session to
-   `approve`, `guard`, or `auto`, and restore the project default.
+   `approve`, `guard`, `lite`, or `auto`, and restore the project default.
 
 Never omit the confirm-mode section, even when the unfinished task list is empty. A bare panel
 invocation is read-only: do not set or clear the session override until the user explicitly asks
@@ -87,20 +87,22 @@ Use the snapshot already required by the default panel and show:
 - `session_confirm_mode` (`project default` when null)
 - `effective_confirm_mode`
 
-When the user asks to change the current session, use native choice UI when available and offer
-exactly `approve`, `guard` (recommended default), and `auto`. The native free-form Other input
-may receive `restore project default`; do not invent a fourth button when the UI is limited to
-three choices.
+When the user asks to change the current session, use native choice UI when available. When the
+UI is limited to three choices, offer `guard` (recommended default), `lite`, and `auto`; accept
+`approve` or `restore project default` through the native free-form Other input. A text fallback
+must list all four modes and the restore action.
 
 Set an override through the state API, never by editing the session JSON:
-`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py set-confirm-mode --session-file <P> --mode <approve|guard|auto> --agent <agent-id>`.
+`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py set-confirm-mode --session-file <P> --mode <approve|guard|lite|auto> --agent <agent-id>`.
 
 Restore project configuration through:
 `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py clear-confirm-mode --session-file <P> --agent <agent-id>`.
 
 Use the returned snapshot as authoritative and report the effective mode. Preserve any existing
 `pending_transition`; when it becomes automatic, ec-workflow consumes its original target via
-`auto-transition` instead of losing the completed stage outcome.
+`auto-transition` instead of losing the completed stage outcome. The exception is an existing
+IMPLEMENT -> REVIEW edge after switching to lite: ec-workflow must cancel it and automatically
+enter VERIFICATION because lite never runs REVIEW.
 
 ## Boundaries
 

package/templates/common/skills/ec-verification/SKILL.md

@@ -21,7 +21,7 @@ NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
 
 NO ARCHIVE WITHOUT A GREEN GATE
 - Verification passing evidence is mandatory in every confirm mode.
-- approve/guard require user acceptance before MEMORY; auto advances after the green gate.
+- approve/guard/lite require user acceptance before MEMORY; auto advances after the green gate.
 - Confirmation mode never turns failed or missing evidence into acceptance.
 ```
 
@@ -53,7 +53,7 @@ Append one `verify` record per check:
 
 ## 3. Gate decision
 
-- All three pass AND coverage satisfied → present the verification result; approve/guard wait
+- All three pass AND coverage satisfied → present the verification result; approve/guard/lite wait
   for user acceptance, while auto hands the green result to ec-workflow for automatic MEMORY.
 - Any failure → append the failing `verify` record, summarize failures, select
   VERIFICATION -> IMPLEMENT, and follow the effective confirm mode.
@@ -64,21 +64,23 @@ After a green gate, present an acceptance summary: what changed (files + summari
 verification results (lint/type/test), and the coverage status. Then the user takes time to
 test manually. Their response routes:
 
-- **"accepted"** (approve/guard) → request VERIFICATION -> MEMORY and present the standard boundary gate.
+- **"accepted"** (approve/guard/lite) → request VERIFICATION -> MEMORY and present the standard boundary gate.
 - **"problem here"** → scope judgment against the dev-spec:
   - in scope → select VERIFICATION -> IMPLEMENT and follow the effective confirm mode; after
-    repair, approve presents the IMPLEMENT choice while guard/auto default to REVIEW.
+    repair, approve presents the IMPLEMENT choice, guard/auto default to REVIEW, and lite
+    returns directly to VERIFICATION.
   - out of scope → propose a new task (`spawned_from` = current task id); the current task
     may archive now (if already satisfactory) or stay suspended.
 - **"cancel"** → ec-task-close.
 
 Repair sizing: a trivial tweak is fixed and re-verified inside VERIFICATION; a logic/structure
-change formally returns to IMPLEMENT. After repair, present the standard IMPLEMENT completion
-choice again so the user may enter REVIEW or skip directly to VERIFICATION.
+change formally returns to IMPLEMENT. After repair, approve presents the standard IMPLEMENT
+completion choice again; guard/auto enter REVIEW, while lite returns directly to VERIFICATION
+without offering REVIEW.
 
 ## 5. Archive entry
 
-In approve/guard, acceptance does not mutate the stage directly. Hand control to ec-workflow
+In approve/guard/lite, acceptance does not mutate the stage directly. Hand control to ec-workflow
 to call `request-transition --stage MEMORY`, then present:
 1. Confirm entering MEMORY
 2. Hand off to another agent

package/templates/common/skills/ec-workflow/SKILL.md

@@ -76,7 +76,7 @@ INIT --[always auto]--> ANALYSIS -> IMPLEMENT -> REVIEW -> VERIFICATION -> MEMOR
                  +-- replan ---+          +--- fix -----+
                               ^                         |
                               +------- repair ----------+
-edge behavior --[effective confirm mode: approve / guard / auto]--> target stage
+edge behavior --[effective confirm mode: approve / guard / lite / auto]--> target stage
 any stage --[user abort via ec-task-close]--> CLOSED
 ```
 
@@ -84,7 +84,7 @@ any stage --[user abort via ec-task-close]--> CLOSED
 |---|---|---|---|
 | INIT | ec-workflow | collect context, settle scope AND delivery form (change code vs. produce a document) | work complete; auto-transition to ANALYSIS |
 | ANALYSIS | ec-analysis | dev-spec + execution plan; code tasks also get test strategy | mode-aware transition to IMPLEMENT |
-| IMPLEMENT | ec-implementing | code changes or one read-only deliverable | code defaults to REVIEW when automatic; approve may choose VERIFICATION |
+| IMPLEMENT | ec-implementing | code changes or one read-only deliverable | guard/auto default to REVIEW; lite enters VERIFICATION; approve chooses |
 | REVIEW | ec-reviewing | multi-dimension code review | verdict selects a legal mode-aware target |
 | VERIFICATION | ec-verification | hard gate: lint/typecheck/test + coverage | mode-aware transition to MEMORY or IMPLEMENT |
 | MEMORY | ec-memory | write short memory, then run the conditional long-memory gate | memory work complete; auto-transition to COMPLETE |
@@ -120,8 +120,9 @@ it, routing matches, and switching happens again.
 
 - **Code tasks may skip only REVIEW.** ANALYSIS cannot jump to VERIFICATION and code tasks never
   skip VERIFICATION. In `guard` and `auto`, an automatic code path chooses REVIEW as the default
-  successor to IMPLEMENT. In `approve`, the user may explicitly choose REVIEW or skip it and
-  enter VERIFICATION.
+  successor to IMPLEMENT. In `lite`, IMPLEMENT must enter VERIFICATION directly and the state
+  API rejects IMPLEMENT -> REVIEW. In `approve`, the user may explicitly choose REVIEW or skip
+  it and enter VERIFICATION.
 - **Resolve the effective confirm mode first.** Read `[easy-coding:confirm-mode:X]` or the state
   API snapshot. Session mode overrides project `behavior.confirm_mode`; missing project
   configuration defaults to `guard`.
@@ -130,11 +131,16 @@ it, routing matches, and switching happens again.
   - `guard` (default): only ANALYSIS -> IMPLEMENT and VERIFICATION -> MEMORY require explicit
     confirmation. Every other legal edge uses `auto-transition` after its owner selects the
     evidence-backed target.
+  - `lite`: uses the same two confirmation gates as guard, but code IMPLEMENT automatically
+    enters VERIFICATION and never dispatches REVIEW.
   - `auto`: every legal edge uses `auto-transition`.
   `ec-task-close` remains an explicit user abort and is not triggered by confirm mode.
 - **Confirmation policy changes prompts, not evidence.** No mode chooses product scope,
-  delivery form, API contracts, or risk decisions for the user. No mode bypasses dev-spec,
-  execution, review, verification, or memory checkpoints.
+  delivery form, API contracts, or risk decisions for the user. Lite intentionally omits REVIEW;
+  every mode still preserves its applicable dev-spec, execution, verification, and memory gates.
+- **Lite pending-edge compatibility.** If the status context contains
+  `[easy-coding:lite-review-bypass-required:IMPLEMENT->REVIEW]`, cancel that stale pending edge,
+  then call `auto-transition --stage VERIFICATION`. Never consume or re-request REVIEW in lite.
 - **Always-automatic mechanical edges.** After INIT work completes, call `auto-transition` for
   ANALYSIS. After `memory-complete`, call `auto-transition` for COMPLETE. These two edges never
   create `pending_transition` in any mode.
@@ -183,7 +189,7 @@ it, routing matches, and switching happens again.
   A summary or execution.jsonl record is not a substitute; missing user-visible delivery keeps
   the task in IMPLEMENT. The execution log must contain a matching `dispatch` immediately before
   the accepted result for that unit. After delivery, use `request-transition` in approve mode
-  or `auto-transition` in guard/auto mode for COMPLETE; do not enter REVIEW, VERIFICATION, or
+  or `auto-transition` in guard/lite/auto mode for COMPLETE; do not enter REVIEW, VERIFICATION, or
   MEMORY and do not write memory.
 - **On an automatic edge** call:
   `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py auto-transition --session-file <P> --stage <TARGET> --agent <agent-id>`.
@@ -206,14 +212,15 @@ it, routing matches, and switching happens again.
 - **Repair loop sizing** (after VERIFICATION): a trivial tweak may be fixed inside
   VERIFICATION and re-verified without a status change; a logic or structure change selects
   VERIFICATION -> IMPLEMENT and follows the effective mode. After repair, approve mode presents
-  the IMPLEMENT choice again; guard/auto follow the default REVIEW path.
+  the IMPLEMENT choice again; guard/auto follow the default REVIEW path, while lite returns
+  directly to VERIFICATION.
 - **Scope guard** (repair loop): if the user's fix request falls outside the dev-spec scope
   (features or files absent from the change-scope table), say so explicitly and propose a
   new task with `spawned_from` set to the current task id. Never silently absorb scope creep.
 - **Task switching is allowed at any stage.** The suspended task retains its stage in
   task.json. Do not run memory flows for suspended tasks — only completed tasks get archived.
 - **Archive only after the configured acceptance gate.** VERIFICATION passing does not complete
-  the task. A green gate requests VERIFICATION -> MEMORY in approve/guard, or advances
+  the task. A green gate requests VERIFICATION -> MEMORY in approve/guard/lite, or advances
   automatically in auto. After entry, MEMORY writes one short entry first, records it through `memory-short-complete`,
   then asks the state API for the authoritative `memory` instruction. `action == "no-op"`
   skips long-memory reads/writes; `action == "distill"` processes exactly `trim_count` older
@@ -228,6 +235,7 @@ it, routing matches, and switching happens again.
 Hook breadcrumbs you may receive: `[workflow-state:X]`, `[current-task:Y]`,
 `[easy-coding:session-file:P]`, `[easy-coding:confirm-mode:M]`,
 `[easy-coding:handoff-from:Z]`,
+`[easy-coding:lite-review-bypass-required:IMPLEMENT->REVIEW]`,
 `[easy-coding:init-required]`.
 
 Resuming an active task (whether from session restart, claim, handoff, or task switch):
@@ -236,12 +244,14 @@ Resuming an active task (whether from session restart, claim, handoff, or task s
    records tell you exactly where work stopped.
 3. If the task was claimed from another agent, read the latest `handoff` record first for the
    fast summary and tell the user which previous agent handed it off.
-4. If `pending_transition` exists, do not rerun the completed stage action. Compare the stored
-   edge with `effective_confirm_mode`. If the edge is now automatic, call `auto-transition` for
-   its stored target; otherwise re-present the confirmation/handoff/Other choices. For a
-   read-only task in IMPLEMENT, cancel any stale REVIEW/VERIFICATION edge before the terminal
-   check below. At an approve-mode IMPLEMENT boundary for a code task, re-present the special
-   REVIEW / skip to VERIFICATION / handoff choices.
+4. If `pending_transition` exists, do not rerun the completed stage action. Handle
+   `[easy-coding:lite-review-bypass-required:IMPLEMENT->REVIEW]` before the generic pending-edge
+   rule: call `cancel-transition`, then `auto-transition --stage VERIFICATION`. Otherwise compare
+   the stored edge with `effective_confirm_mode`. If the edge is now automatic, call
+   `auto-transition` for its stored target; otherwise re-present the confirmation/handoff/Other
+   choices. For a read-only task in IMPLEMENT, cancel any stale REVIEW/VERIFICATION edge before
+   the terminal check below. At an approve-mode IMPLEMENT boundary for a code task, re-present
+   the special REVIEW / skip to VERIFICATION / handoff choices.
 5. If a read-only task resumes in IMPLEMENT with a valid successful result, output its complete
    deliverable again and follow the effective mode to COMPLETE. Otherwise tell the user what is
    being resumed and from which stage, then continue.

package/templates/main-constraint/AGENTS.md.tpl

@@ -11,13 +11,13 @@ user in the user's language.
 Start every work reply with the single Markdown blockquote status line injected by the hook,
 then a blank line. Do not render the machine breadcrumbs to the user.
 
-`{confirm-mode}` is the capitalized effective mode (`Approve`, `Guard`, or `Auto`); a session
+`{confirm-mode}` is the capitalized effective mode (`Approve`, `Guard`, `Lite`, or `Auto`); a session
 override takes precedence over the project mode.
 
-- Ready: > **Easy Coding [{confirm-mode}]** · Ready · Use `ec-workflow` to start or resume a task, `ec-brainstorming` to brainstorm, or `ec-task-management` to manage tasks or session settings
-- Waiting init: > **Easy Coding [{confirm-mode}]** · Waiting init · Use `ec-init` to initialize
-- Active task: > **Easy Coding [{confirm-mode}]** · `{current-task}` · `{workflow-state}`
-- Handoff: > **Easy Coding [{confirm-mode}]** · `{current-task}` · `{workflow-state}` · Handoff -> `{source-agent}`
+- Ready: > **Easy Coding** · **{confirm-mode}** · Ready · Use `ec-workflow` to start or resume a task, `ec-brainstorming` to brainstorm, or `ec-task-management` to manage tasks or session settings
+- Waiting init: > **Easy Coding** · **{confirm-mode}** · Waiting init · Use `ec-init` to initialize
+- Active task: > **Easy Coding** · **{confirm-mode}** · `{current-task}` · `{workflow-state}`
+- Handoff: > **Easy Coding** · **{confirm-mode}** · `{current-task}` · `{workflow-state}` · Handoff -> `{source-agent}`
 
 Skill names in the status line are bare names (`ec-init`, `ec-workflow`) and never include
 platform prefixes such as `/` or `$`. If no status line is injected, do not invent one.
@@ -41,9 +41,9 @@ First run `ec-init`; daily work goes through `ec-workflow`.
 
 - Effective confirm mode is session override > project `behavior.confirm_mode` > `guard`.
   `approve` confirms every legal edge except INIT -> ANALYSIS and MEMORY -> COMPLETE; `guard`
-  confirms only ANALYSIS -> IMPLEMENT and VERIFICATION -> MEMORY; `auto` confirms none.
-  Automatic code flow chooses IMPLEMENT -> REVIEW. Confirmation mode never changes scope,
-  delivery form, evidence gates, or the legal transition graph.
+  and `lite` confirm only ANALYSIS -> IMPLEMENT and VERIFICATION -> MEMORY; `auto` confirms none.
+  Guard/auto code flow chooses IMPLEMENT -> REVIEW; lite chooses IMPLEMENT -> VERIFICATION and
+  never runs REVIEW. Confirmation mode never changes scope, delivery form, or evidence gates.
 - Confirmation-required edges use `pending_transition`; automatic edges use the restricted
   `auto-transition` API. A read-only task creates no test-strategy.md, never enters REVIEW,
   VERIFICATION, or MEMORY, and writes no task memory.

package/templates/main-constraint/CLAUDE.md.tpl

@@ -11,13 +11,13 @@ user in the user's language.
 Start every work reply with the single Markdown blockquote status line injected by the hook,
 then a blank line. Do not render the machine breadcrumbs to the user.
 
-`{confirm-mode}` is the capitalized effective mode (`Approve`, `Guard`, or `Auto`); a session
+`{confirm-mode}` is the capitalized effective mode (`Approve`, `Guard`, `Lite`, or `Auto`); a session
 override takes precedence over the project mode.
 
-- Ready: > **Easy Coding [{confirm-mode}]** · Ready · Use `ec-workflow` to start or resume a task, `ec-brainstorming` to brainstorm, or `ec-task-management` to manage tasks or session settings
-- Waiting init: > **Easy Coding [{confirm-mode}]** · Waiting init · Use `ec-init` to initialize
-- Active task: > **Easy Coding [{confirm-mode}]** · `{current-task}` · `{workflow-state}`
-- Handoff: > **Easy Coding [{confirm-mode}]** · `{current-task}` · `{workflow-state}` · Handoff -> `{source-agent}`
+- Ready: > **Easy Coding** · **{confirm-mode}** · Ready · Use `ec-workflow` to start or resume a task, `ec-brainstorming` to brainstorm, or `ec-task-management` to manage tasks or session settings
+- Waiting init: > **Easy Coding** · **{confirm-mode}** · Waiting init · Use `ec-init` to initialize
+- Active task: > **Easy Coding** · **{confirm-mode}** · `{current-task}` · `{workflow-state}`
+- Handoff: > **Easy Coding** · **{confirm-mode}** · `{current-task}` · `{workflow-state}` · Handoff -> `{source-agent}`
 
 Skill names in the status line are bare names (`ec-init`, `ec-workflow`) and never include
 platform prefixes such as `/` or `$`. If no status line is injected, do not invent one.
@@ -39,9 +39,9 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
 
 - Effective confirm mode is session override > project `behavior.confirm_mode` > `guard`.
   `approve` confirms every legal edge except INIT -> ANALYSIS and MEMORY -> COMPLETE; `guard`
-  confirms only ANALYSIS -> IMPLEMENT and VERIFICATION -> MEMORY; `auto` confirms none.
-  Automatic code flow chooses IMPLEMENT -> REVIEW. Confirmation mode never changes scope,
-  delivery form, evidence gates, or the legal transition graph.
+  and `lite` confirm only ANALYSIS -> IMPLEMENT and VERIFICATION -> MEMORY; `auto` confirms none.
+  Guard/auto code flow chooses IMPLEMENT -> REVIEW; lite chooses IMPLEMENT -> VERIFICATION and
+  never runs REVIEW. Confirmation mode never changes scope, delivery form, or evidence gates.
 - Confirmation-required edges use `pending_transition`; automatic edges use the restricted
   `auto-transition` API. A read-only task creates no test-strategy.md, never enters REVIEW,
   VERIFICATION, or MEMORY, and writes no task memory.

package/templates/shared-hooks/easy_coding_state.py

@@ -50,12 +50,13 @@ ALWAYS_AUTO_TRANSITIONS = {
 }
 READ_ONLY_COMPLETION_TRANSITION = ("IMPLEMENT", "COMPLETE")
 NO_CODE_TASK_TYPES = {"analysis", "doc", "report"}
-CONFIRM_MODES = {"approve", "guard", "auto"}
+CONFIRM_MODES = {"approve", "guard", "lite", "auto"}
 DEFAULT_CONFIRM_MODE = "guard"
-GUARD_CONFIRM_TRANSITIONS = {
+CRITICAL_CONFIRM_TRANSITIONS = {
     ("ANALYSIS", "IMPLEMENT"),
     ("VERIFICATION", "MEMORY"),
 }
+LITE_SKIPPED_TRANSITION = ("IMPLEMENT", "REVIEW")
 
 LEGACY_STAGE_MAP = {
     "WAITING_CONFIRM": "ANALYSIS",
@@ -198,7 +199,7 @@ def read_project_confirm_mode(root: Path) -> str:
         if mode not in CONFIRM_MODES:
             raise StateError(
                 "Invalid behavior.confirm_mode in .easy-coding/config.yaml: "
-                "expected approve, guard, or auto."
+                "expected approve, guard, lite, or auto."
             )
         return mode
     return DEFAULT_CONFIRM_MODE
@@ -208,7 +209,7 @@ def resolve_confirm_mode(root: Path, session: dict) -> tuple[str, str | None, st
     project_mode = read_project_confirm_mode(root)
     session_mode = session.get("confirm_mode")
     if session_mode is not None and session_mode not in CONFIRM_MODES:
-        raise StateError("Invalid session confirm_mode: expected approve, guard, or auto.")
+        raise StateError("Invalid session confirm_mode: expected approve, guard, lite, or auto.")
     effective_mode = str(session_mode or project_mode)
     return project_mode, str(session_mode) if session_mode else None, effective_mode
 
@@ -950,13 +951,23 @@ def transition_requires_confirmation(
         return True
     if confirm_mode == "auto":
         return False
-    if confirm_mode == "guard":
-        return (previous, current) in GUARD_CONFIRM_TRANSITIONS
+    if confirm_mode in {"guard", "lite"}:
+        return (previous, current) in CRITICAL_CONFIRM_TRANSITIONS
     if confirm_mode == "approve":
         return True
     raise StateError(f"Unknown confirm mode: {confirm_mode}")
 
 
+def validate_confirm_mode_transition(
+    previous: str,
+    current: str,
+    confirm_mode: str,
+) -> str | None:
+    if confirm_mode == "lite" and (previous, current) == LITE_SKIPPED_TRANSITION:
+        return "LITE MODE TRANSITION: IMPLEMENT -> REVIEW is disabled; use IMPLEMENT -> VERIFICATION."
+    return None
+
+
 def is_automatic_transition(
     previous: str,
     current: str,
@@ -1040,7 +1051,7 @@ def build_status_line(
     session_file: str | Path | None = None,
 ) -> str:
     state = snapshot_state(root, session_file, session)
-    status_brand = f"> **Easy Coding [{str(state['effective_confirm_mode']).capitalize()}]**"
+    status_brand = f"> **Easy Coding** · **{str(state['effective_confirm_mode']).capitalize()}**"
     task_id = state["current_task"]
     if task_id:
         status = str(state["status"])
@@ -1096,7 +1107,15 @@ def build_machine_breadcrumbs(
             if target:
                 lines.append(f"[easy-coding:pending-transition:{source}->{target}]")
                 task_type = str(task.get("type") or "") if task else ""
-                if is_automatic_transition(
+                # A mode switch can leave a REVIEW edge that lite must bypass instead of consume.
+                mode_violation = validate_confirm_mode_transition(
+                    source,
+                    target,
+                    str(state["effective_confirm_mode"]),
+                )
+                if mode_violation:
+                    lines.append(f"[easy-coding:lite-review-bypass-required:{source}->{target}]")
+                elif is_automatic_transition(
                     source,
                     target,
                     task_type,
@@ -1257,7 +1276,7 @@ def set_session_confirm_mode(
     session_file: str | Path | None = None,
 ) -> dict:
     if mode not in CONFIRM_MODES:
-        raise StateError("Invalid confirm mode: expected approve, guard, or auto.")
+        raise StateError("Invalid confirm mode: expected approve, guard, lite, or auto.")
     session = ensure_session(root, session_file)
     session["confirm_mode"] = mode
     session["last_agent"] = agent
@@ -1446,6 +1465,9 @@ def request_transition(
     violation = validate_transition(previous, stage, task_type)
     if violation:
         raise StateError(violation)
+    mode_violation = validate_confirm_mode_transition(previous, stage, confirm_mode)
+    if mode_violation:
+        raise StateError(mode_violation)
     if is_automatic_transition(previous, stage, task_type, confirm_mode):
         raise StateError(
             f"Transition {previous} -> {stage} is automatic in {confirm_mode} mode; "
@@ -1488,9 +1510,13 @@ def apply_transition(
 
     previous = str(task.get("status") or "idle")
     task_type = str(task.get("type") or "")
+    confirm_mode = resolve_confirm_mode(root, session)[2]
     violation = validate_transition(previous, stage, task_type)
     if violation:
         raise StateError(violation)
+    mode_violation = validate_confirm_mode_transition(previous, stage, confirm_mode)
+    if mode_violation:
+        raise StateError(mode_violation)
     if previous == "ANALYSIS" and stage == "IMPLEMENT":
         validate_analysis_readiness(root, resolved_task_id)
     if previous == "MEMORY" and stage == "COMPLETE":
@@ -1571,6 +1597,9 @@ def confirm_transition(
         )
     if stage and stage != target:
         raise StateError(f"Pending transition targets {target}, not {stage}.")
+    mode_violation = validate_confirm_mode_transition(source, target, confirm_mode)
+    if mode_violation:
+        raise StateError(mode_violation)
     if is_automatic_transition(source, target, task_type, confirm_mode):
         raise StateError(
             f"Transition {source} -> {target} is automatic in {confirm_mode} mode; "