@aksp/opencrew 1.6.3 → 1.7.1

package/templates/_opencrew/core/runner.pipeline.md

@@ -33,18 +33,7 @@ Before starting execution:
    - Crew memory from `crews/{name}/_memory/memories.md`
    - User preferences from `_opencrew/_memory/preferences.md`
 
-1a. **Check the Dashboard toggle** — the visual dashboard (`state.json` writes) is an
-    optional, opt-in feature that most installs never use (it requires running the
-    separate dashboard app from source — see README). Scan the already-loaded
-    `preferences.md` for a `Dashboard:` field:
-    - If its value is `enabled` (as written by onboarding: `- **Dashboard:** enabled`, or the
-      plain form `Dashboard: enabled`) → set `dashboard_enabled = true` for this run.
-    - Otherwise (`disabled`, missing, or preferences.md not configured yet) →
-      set `dashboard_enabled = false`. This is the default.
-    Store `dashboard_enabled` in working memory for the rest of this run. Every
-    `state.json` read/write instruction in this document is conditional on it —
-    when `false`, skip ALL of them; never create, update, or delete
-    `crews/{name}/state.json`.
+1a. **Escritório toggle** — the optional live view is off unless `preferences.md` turns it on (see "Escritório" below).
 
 > **Note on language**: The structural labels listed below are **fixed PT-BR** and must
 > never be translated — opencrew's primary supported audience is PT-BR (see AGENTS.md →
@@ -64,12 +53,9 @@ Before starting execution:
 > unless the user base expands beyond PT-BR — at that point, discuss a migration strategy
 > (e.g. i18n key mapping) rather than mixing languages in a single file.
 
-1b. **Memory format migration** — After loading `memories.md`, check whether it uses the new format by scanning for the `## Estilo de Escrita` section header:
-   ```bash
-   [ -f "crews/{name}/_memory/memories.md" ] && grep -q "## Estilo de Escrita" "crews/{name}/_memory/memories.md" && echo "NEW_FORMAT" || echo "OLD_FORMAT"
-   ```
-   - If `NEW_FORMAT` → proceed normally.
-   - If `OLD_FORMAT` (or file is empty / does not exist) → migrate before proceeding:
+1b. **Memory format migration** — After loading `memories.md`, check whether it uses the new format: it does when it has the `## Estilo de Escrita` section header (read the file with the read tool — no command).
+   - If it has the header → proceed normally.
+   - If it does not (or the file is empty / does not exist) → migrate before proceeding:
      a0. If the file exists and is not empty, FIRST copy it to `crews/{name}/_memory/memories.md.bak`
         (never lose what the crew learned), then tell the user in one line:
         "Atualizei o formato da memória da crew; a versão anterior está em `memories.md.bak`."
@@ -89,11 +75,8 @@ Before starting execution:
         ## Técnico (específico do crew)
         ```
         (Use the crew's display name for `{crew-name}`, and the crew code for `{name}` in file paths — they refer to the same crew.)
-     b. Check if `crews/{name}/_memory/runs.md` exists:
-        ```bash
-        test -f "crews/{name}/_memory/runs.md" && echo "EXISTS" || echo "MISSING"
-        ```
-        If `MISSING`, create it with:
+     b. Check if `crews/{name}/_memory/runs.md` exists (read tool — no command).
+        If it does not exist, create it with:
         ```markdown
         # Run History: {crew-name}
 
@@ -240,45 +223,47 @@ Before starting execution:
    identical to today: all agents listed, no Skipped line.
 5b. **Initialize run folder**: Generate a unique run ID for this execution:
    - Format: `YYYY-MM-DD-HHmmss` using the current timestamp (e.g. `2026-03-03-143022`)
-   - Check if `crews/{name}/output/{run_id}/` already exists
+   - Check (folder-listing tool, no command) if `crews/{name}/output/{run_id}/` already exists
      - If it does (sub-second collision), append `-2`, `-3`, etc. until the folder does not exist
-   - Create the folder using Bash: `mkdir -p "crews/{name}/output/{run_id}"`
+   - Create the folder: run the `pasta` command (see "Output Path Transformation" below) — never create a folder by command yourself
    - Store `run_id` in working memory for this run — it will be used for ALL output paths
-6. **Initialize state.json** (only if `dashboard_enabled` — see step 1a; otherwise skip this entire step, including all sub-steps below):
-   - **IMPORTANT**: When enabled, write to `crews/{name}/state.json` before every step and after every handoff, as described throughout this document. When `dashboard_enabled` is false, never create, write, or delete this file.
-   - Create `state.json` from scratch:
-     a. Read `crews/{name}/crew-party.csv` — for each agent row (skip header), extract:
-        - `id`: take the `path` column, strip `./agents/` prefix and `.agent.md` suffix
-          (e.g. `./agents/researcher.agent.md` → `researcher`)
-        - `name`: use the `displayName` column
-        - `icon`: use the `icon` column
-     b. Assign desk positions by agent order (0-based index):
-        - `col = (index % 3) + 1`
-        - `row = floor(index / 3) + 1`
-        (index 0 → col:1 row:1, index 1 → col:2 row:1, index 2 → col:3 row:1, index 3 → col:1 row:2, etc.)
-     c. Read `crews/{name}/crew.yaml` — count items in `pipeline.steps` for `total`
-     d. Write `crews/{name}/state.json` with the Write tool:
-        ```json
-        {
-          "crew": "{crew code from crew.yaml}",
-          "status": "idle",
-          "step": { "current": 0, "total": {step count from c}, "label": "" },
-          "agents": [
-            {
-              "id": "{agent id}",
-              "name": "{agent displayName}",
-              "icon": "{agent icon}",
-              "status": "idle",
-              "desk": { "col": {col from b}, "row": {row from b} }
-            }
-          ],
-          "handoff": null,
-          "startedAt": null,
-          "updatedAt": "{ISO timestamp now}"
-        }
-        ```
-        Include one entry per agent, in crew-party.csv order. For each agent, set
-        `"status"` to `"skipped"` if it is in `skipped_agents`, otherwise `"idle"`.
+6. **Escritório** — if it is on, run `iniciar`, then one `pular` per deselected agent, one after the other (see "Escritório" below).
+
+## Escritório (optional live view)
+
+A local page that shows the crew at work, off by default. Follow this section only when the
+already-loaded `preferences.md` has `Dashboard: enabled` (written `- **Dashboard:** enabled` or
+plain `Dashboard: enabled`, any letter case); otherwise run none of these commands. When it is on,
+run via Bash, from the project root, the one-line command of each moment:
+
+| Moment | Command |
+|---|---|
+| Start of the run (Initialization, step 6) | `node _opencrew/core/scripts/estado.mjs "{name}" iniciar --passos {N}` |
+| Right after `iniciar`, once per deselected agent | `node _opencrew/core/scripts/estado.mjs "{name}" pular --agente {id}` |
+| Before each step, each time it starts | `node _opencrew/core/scripts/estado.mjs "{name}" passo --n {K} --agente {id} --rotulo "{rótulo}" --mensagem "{frase}"` |
+| Before asking the question of a checkpoint (instead of `passo`) | `node _opencrew/core/scripts/estado.mjs "{name}" checkpoint --n {K} --agente {id} --rotulo "{rótulo}"` |
+| End of the run (After Pipeline Completion) | `node _opencrew/core/scripts/estado.mjs "{name}" concluir` |
+| Run aborted after `iniciar`, by the user or by an error | `node _opencrew/core/scripts/estado.mjs "{name}" falhar --motivo "{motivo}"` |
+
+- **One at a time** — Run these commands one at a time, waiting for the `ESTADO:` line of each
+  before the next — never in parallel or in the background (each one reads and rewrites the same file).
+- **Values** — `{name}`: the crew code. `{N}`: how many steps will run, checkpoints included (a
+  deselected agent's steps do not count). `{K}`: the step's position among them, from 1. `{id}`: the agent's `id` column in
+  `crew-party.csv`; a step or checkpoint with no `agent:` goes without `--agente`
+  (the table shows the full form). `{rótulo}`: the step's name, in
+  a few words. `--mensagem` goes only when the agent changed since the last `passo` (so never on the first
+  one): one sentence on what the previous agent delivered — never look at the next step. `{motivo}`: why the run stopped.
+- **Text on the command line** — `--rotulo`, `--mensagem` and `--motivo` go between double quotes,
+  on one line, starting with a letter or a digit, with only letters (accents included), digits,
+  spaces and `. , : ; - ( ) / ?`. Drop every other sign (quotes of any kind, `$`, backtick, `\`,
+  `%`, `!`, emoji). If no text is left, omit the option. Write them in the user's language.
+- **After `iniciar`**, when it answers `ESTADO:OK`, show the user once:
+  `Escritório ligado. Se a página não estiver aberta, rode em outro terminal: node _opencrew/core/scripts/escritorio.mjs`
+- **The Escritório never stops the run.** A command that fails, does not run or answers
+  `ESTADO:IGNORADO`: go on, do not repeat that event, ask nothing, and tell the user once per run,
+  in one line: `O escritório não foi atualizado nesta execução; o trabalho segue normalmente.` With
+  the reason "escritório desligado", say nothing and stop calling the script for the rest of this run.
+- The script is the only writer: never read, write or describe `crews/{name}/state.json` yourself.
 
 ## Execution Rules
 
@@ -388,11 +373,9 @@ Before executing any step that references an agent:
 To prevent linear token growth across multi-agent pipelines, apply context compression
 when passing prior agents' outputs as context:
 
-1. **TL;DR extraction**: After each agent completes, check if its output contains a `## TL;DR` section.
+1. **TL;DR extraction**: After each agent completes, check if its output contains a `## TL;DR` section
+   (a line starting with `## TL;DR` — you have the output, no command is needed).
    If present, extract and store it separately as the agent's summary.
-   ```bash
-   grep -q "^## TL;DR" "{outputFile}" && echo "HAS_TLDR" || echo "NO_TLDR"
-   ```
 
 2. **Compressed context assembly**: When preparing context for Agent N:
    - Include **TL;DR summaries** from Agents 1 through N-2 (all agents except the direct predecessor)
@@ -450,7 +433,7 @@ When an agent's `.agent.md` frontmatter contains a `tasks:` field:
    e. Check task veto conditions (same enforcement as step veto conditions below)
 
 3. **Final output**: The output of the LAST task in the chain becomes the step's output
-   - Apply the Output Path Transformation (Steps 1 and 2: run_id injection + version folder) to the `outputFile` path before saving — this applies regardless of whether the step runs as `execution: inline` or `execution: subagent`
+   - Resolve the `outputFile` path with the `saida` command (Output Path Transformation) before saving — this applies regardless of whether the step runs as `execution: inline` or `execution: subagent`
    - Save to the **transformed** outputFile path
    - This is what the next step (or checkpoint) receives
 
@@ -464,86 +447,63 @@ When an agent's `.agent.md` frontmatter contains a `tasks:` field:
 
 ### Output Path Transformation
 
-Before saving any output file in a step, apply these rules to determine the final path:
-
-#### Step 1 — Insert run_id
-
-- If the path starts with `crews/{name}/output/`, insert `{run_id}/` immediately after `output/`
-  - Example: `crews/carousel/output/slides/draft.md` → `crews/carousel/output/2026-03-03-143022/slides/draft.md`
-  - Example: `crews/carousel/output/angles-brief.yaml` → `crews/carousel/output/2026-03-03-143022/angles-brief.yaml`
-- If the path does NOT start with `crews/{name}/output/`, leave it unchanged
-
-#### Step 2 — Insert version folder
-
-Apply to every path that was transformed in Step 1:
-
-1. Determine the **output group** = the parent directory of the file (after Step 1 transformation)
-   - Example: `crews/carousel/output/2026-03-03-143022/slides/draft.md` → group is `crews/carousel/output/2026-03-03-143022/slides/`
-   - Example: `crews/carousel/output/2026-03-03-143022/angles-brief.yaml` → group is `crews/carousel/output/2026-03-03-143022/`
-
-2. Detect existing versions for this group using Bash:
-   ```bash
-   ls -1 "crews/{name}/output/{run_id}/{relative-group}/" 2>/dev/null | grep -E '^v[0-9]+$' | sort -V | tail -1
-   ```
-   - If the command returns a version (e.g. `v2`) → use `v3`
-   (Always increment the highest version found, even if lower versions have gaps — e.g. if `v1` and `v3` exist, use `v4`)
-   - If the command returns nothing (no versions yet) → use `v1`
-   (`{relative-group}` is the portion of the group path after `crews/{name}/output/{run_id}/`, e.g. `slides/` or empty string for root-level files)
-
-3. Insert the version folder immediately before the filename:
-   - `crews/carousel/output/2026-03-03-143022/slides/draft.md` → `crews/carousel/output/2026-03-03-143022/slides/v1/draft.md`
-   - `crews/carousel/output/2026-03-03-143022/angles-brief.yaml` → `crews/carousel/output/2026-03-03-143022/v1/angles-brief.yaml`
-
-4. **Cache per group**: within a single step execution, once a version is determined for a group, reuse it for all subsequent files in that same group. Do not re-run the `ls` per file.
-   If the same file path is written twice within a step, both writes go to the same versioned path (the second write overwrites the first within that version).
-
-Apply this transformation consistently for every write in this step.
+The path of every file of the run comes from one script (`caminho.mjs`), the same on every system —
+never from a path you put together, never from a shell command of your own. Run from the project
+root the one-line command of each moment and read the last line (`CAMINHO:OK {path}`,
+`CAMINHO:FALTA {path}` or `CAMINHO:REPROVADO {motivo}`):
+
+| Moment | Command |
+|---|---|
+| Start of the run (Initialization, step 5b) | `node _opencrew/core/scripts/caminho.mjs "{name}" pasta --run "{run_id}"` |
+| Before a step, for its `inputFile` | `node _opencrew/core/scripts/caminho.mjs "{name}" entrada --run "{run_id}" --arquivo "{inputFile}"` |
+| Before a step writes, for the first `outputFile` of each group | `node _opencrew/core/scripts/caminho.mjs "{name}" saida --run "{run_id}" --arquivo "{outputFile}"` |
+| After a step wrote, for each output file | `node _opencrew/core/scripts/caminho.mjs "{name}" conferir --arquivo "{path}"` |
+
+- **Values** — `{name}`: the crew code. `{inputFile}` / `{outputFile}`: the path as the step
+  declares it (raw, without the run_id). `{path}`: the path `saida` returned. The safe-name rule
+  (nome seguro) applies: the crew and every path between double quotes.
+- **`saida`** answers with the **transformed** path and creates its folder: write the file there,
+  never to the raw path. Run it once per group in a step — the other `outputFile`s of the same
+  group reuse the version folder it returned, and a file written twice in a step goes to the same path.
+- **`entrada`** answers with the newest output of that file: use the path it returns, whatever
+  its version folder.
+- **The rule the script applies** (apply it yourself only when the script does not run):
+  1. A declared path that starts with `crews/{name}/output/` gets `{run_id}/` right after
+     `output/`; any other path stays as declared, with no version folder.
+  2. The **group** is the folder of the file, run_id included (`…/output/{run_id}/`, or
+     `…/output/{run_id}/slides/`). A step writes to the group's next version folder: the highest
+     `vN` there plus 1, or `v1` when there is none — numeric order (`v10` comes after `v9`), gaps
+     not filled (`v1` and `v3` → `v4`).
+  3. A step reads the newest version that has the file: from the highest `vN` down, the first
+     where the file exists and is not empty; then the group itself, with no version folder (where
+     checkpoint answers live).
+
+  Example, one group: the researcher writes `…/v1/pesquisa.md`, the writer writes `…/v2/post.md`
+  and reads `…/v1/pesquisa.md`. Never assume `v1`.
+- **Script that does not run** (no Node, an error, or no `CAMINHO:` line): tell the user once per
+  run `Não consegui rodar a conferência de caminhos; sigo pela regra escrita e marco os arquivos como não verificados.`,
+  build the path by the rule above (the Write tool creates the folder) and continue. A file handled
+  this way skips its gate and is listed at the final approval:
+  `{arquivo} — não verificado: a conferência de caminhos não rodou`.
 
 ### For each pipeline step:
 
 0. **Agent deselection check** — Read the step's `agent:` frontmatter field.
    - If the step has an `agent:` value present AND it is in `skipped_agents` →
      announce `⏭️ Skipping {Agent Name} (deselected for this run)` and skip this
-     step ENTIRELY: no dashboard update, no input validation, no execution, no output
-     validation, no veto, no output file, no handoff. Advance to the next step in
+     step ENTIRELY: no Escritório command, no input validation, no execution, no output
+     validation, no veto, no output file. Advance to the next step in
      `filtered_steps`.
    - Checkpoints that declare `agent:` and whose agent was deselected are skipped the
      same way. Checkpoints with no `agent:` field always run (backward compatible).
    - When the selection step was skipped (no `agent_dependencies:`), `skipped_agents`
      is empty → this check never fires (legacy behavior).
 
-0b. **Update dashboard** (only if `dashboard_enabled`; otherwise skip to step 1). Write `crews/{name}/state.json` using the Write tool. Use this content:
-   ```json
-   {
-     "crew": "{crew code from crew.yaml}",
-     "status": "running",
-     "step": {
-       "current": {1-based index of this step},
-       "total": {total steps in pipeline},
-       "label": "{step id or label}"
-     },
-     "agents": [
-       {
-         "id": "{agent id}",
-         "name": "{agent displayName}",
-         "icon": "{agent icon}",
-          "status": "{working if this is the current step's agent, done if already completed, skipped if in skipped_agents, idle otherwise}",
-         "desk": {preserve existing desk positions from state.json — do not change col/row}
-       }
-     ],
-     "handoff": {preserve existing handoff object, or null if this is the first step},
-     "startedAt": "{ISO timestamp — set on the first step only, then preserve from existing state.json on subsequent steps}",
-     "updatedAt": "{ISO timestamp now}"
-   }
-   ```
+0b. **Escritório** — if it is on, run `passo`, or `checkpoint` when the step is a checkpoint (see "Escritório" above).
 
-1. **Pre-Step Input Validation** — MANDATORY. If the step's frontmatter declares an `inputFile`, validate that the input exists before executing the step. Run via Bash tool:
-   ```bash
-   test -s "{transformed inputFile path}" && echo "VALIDATION:PASS" || echo "VALIDATION:FAIL"
-   ```
-   - Apply the Output Path Transformation (Step 1: run_id injection) to the `inputFile` path before running the check.
-   - If the Bash output contains `VALIDATION:PASS` → proceed to execute the step.
-   - If the Bash output contains `VALIDATION:FAIL` → do NOT execute the step. Present to user:
+1. **Pre-Step Input Validation** — MANDATORY. If the step's frontmatter declares an `inputFile`, the input comes from the `entrada` action, never from a path you build: validate that the input exists before executing the step. Run the `entrada` command (Output Path Transformation) with the `inputFile` as declared:
+   - `CAMINHO:OK {path}` → that path is the step's input (the newest version that has the file): read the input from it and execute the step.
+   - `CAMINHO:FALTA {path}` → do NOT execute the step. Present to user:
      ```
      ⚠️ Input for {Agent Name} not found: {path}
      The previous step may have failed to produce output.
@@ -562,7 +522,7 @@ Apply this transformation consistently for every write in this step.
 - Inform user: `🔍 {Agent Name} is working in the background...`
 - Read the step's `model_tier` frontmatter field (if present).
   Valid values: `fast` or `powerful`. If absent or any other value: default to `powerful`.
-- **Before building the subagent prompt**: Apply the Output Path Transformation (Step 1: run_id injection + Step 2: version folder) to all output paths referenced in the step file. Store the transformed path(s) in working memory — they will be used both in the prompt and in post-completion verification. Never pass raw paths from the step file to the subagent.
+- **Before building the subagent prompt**: Resolve all output paths referenced in the step file with the `saida` command (Output Path Transformation, once per group). Store the transformed path(s) in working memory — they will be used both in the prompt and in post-completion verification. Never pass raw paths from the step file to the subagent.
 - Use the Task tool to dispatch the step as a subagent:
   - If `model_tier: fast`: use the fastest/lightest model available in your current IDE.
   - If `model_tier: powerful` or absent/invalid: use the default model (no model override needed)
@@ -574,7 +534,7 @@ Apply this transformation consistently for every write in this step.
   - The veto conditions from the step file (agent should self-check before completing)
   - The company context
   - The crew memory
-  - The **transformed** path to save output (e.g., `crews/{name}/output/2026-03-20-140736/slides/v1/draft.md`)
+  - The **transformed** path to save output (the one `saida` returned, e.g. `crews/{name}/output/2026-03-20-140736/slides/v2/draft.md`)
 - Wait for the subagent to complete
 - Inform user: `✓ {Agent Name} completed`
 - Proceed to Post-Step Output Validation (below) before advancing.
@@ -584,13 +544,13 @@ Apply this transformation consistently for every write in this step.
 - Announce: `{icon} {Agent Name} is working...`
 - Follow the step instructions
 - Present output directly in the conversation
-- Save output to the specified output file — apply the Output Path Transformation (Steps 1 and 2) to the path before writing. Do not write to the raw path from the step file.
+- Save output to the specified output file — resolve the path with the `saida` command (Output Path Transformation) before writing. Do not write to the raw path from the step file.
 - Proceed to Post-Step Output Validation (below) before advancing.
 
 #### If `type: checkpoint`
 - Present the checkpoint message to the user
 - If the checkpoint requires a choice (numbered list), present options as a numbered list
-- **Always include the file path** of any generated content the user needs to review. Example: "Review the content at `crews/{name}/output/{run_id}/v1/content.md` and let me know if it looks good."
+- **Always include the file path** of any generated content the user needs to review. Example: "Review the content at `crews/{name}/output/{run_id}/v2/content.md` and let me know if it looks good." (the path the script returned)
 - Wait for user input before proceeding
 - Save the user's choice/response for the next step
 - **Correction → memory, right away**: if the answer corrects something (tone, audience, a term,
@@ -603,7 +563,7 @@ Apply this transformation consistently for every write in this step.
   (e.g. the organization's name, the main audience), ask: "Isso vale para todas as crews?
   Atualizo o perfil da empresa?" — change `company.md` only after a yes.
 - **If the step frontmatter contains `outputFile`**: after collecting the user's full response,
-  apply the Output Path Transformation **Step 1 only** (run_id injection — skip Step 2, version folder) to the `outputFile` path, then write the response to the transformed path using the Write tool before moving to the next step. Checkpoint files are user input captures, not versioned output — Step 2 does not apply here, regardless of the general "every write" rule in the Output Path Transformation section above.
+  insert only the run_id in the `outputFile` path (item 1 of the rule in Output Path Transformation — no version folder, no `saida` command), then write the response to that path using the Write tool (it creates the folder) before moving to the next step. Checkpoint files are user input captures, not versioned output: they live in the group itself, where `entrada` finds them.
   Use this format:
   ```
   # Research Focus
@@ -616,28 +576,22 @@ Apply this transformation consistently for every write in this step.
 
 ### Post-Step Output Validation
 
-After a step produces output (subagent or inline) and BEFORE Veto Condition Enforcement, the runner MUST validate that the declared output files exist and are non-empty. This is a binary, non-negotiable gate — the runner does NOT proceed on memory or assumption, only on bash output.
-
-**If the step declares an `outputFile`** (single or multiple), run via Bash tool for EACH output file:
+After a step produces output (subagent or inline) and BEFORE Veto Condition Enforcement, the runner MUST validate that the declared output files exist and are non-empty. This is a binary, non-negotiable gate — the runner does NOT proceed on memory or assumption, only on the script's `CAMINHO:` line.
 
-```bash
-test -s "{transformed outputFile path}" && echo "VALIDATION:PASS" || echo "VALIDATION:FAIL"
-```
+**If the step declares an `outputFile`** (single or multiple), run the `conferir` command (Output Path Transformation) for EACH output file, with the **stored transformed path** (the one `saida` returned), not the raw path from the step file. A step with an `output_contract:` adds its options to this same call (see Output Contract Validation): one command per file.
 
-Use the **stored transformed path** (after Output Path Transformation Steps 1 and 2), not the raw path from the step file.
-
-**Rules:**
-- If ALL output files return `VALIDATION:PASS` → proceed to Veto Condition Enforcement.
+**Rules** (`FAIL` below = the last line is `CAMINHO:REPROVADO arquivo ausente ou vazio`):
+- If ALL output files return `CAMINHO:OK` → proceed to Veto Condition Enforcement.
 - **Irreversible step** (`side_effects: irreversible` — publish, post, send) with ANY
-  `VALIDATION:FAIL` → NEVER re-execute it. Tell the user: "⚠️ {Agent Name} did not save its
+  `FAIL` → NEVER re-execute it. Tell the user: "⚠️ {Agent Name} did not save its
   output, but the action may already have happened (post published / email sent). Check
   before retrying." Then offer: 1. Retry step (only after the user checked) · 2. Mark as done
   and continue · 3. Abort pipeline.
-- If ANY output file returns `VALIDATION:FAIL` (any other step):
+- If ANY output file returns `FAIL` (any other step):
   1. **Retry once**: re-execute the entire step with the same input and context.
   2. After re-execution, run the validation again for all output files.
-  3. If second attempt returns `VALIDATION:PASS` for all files → proceed normally.
-  4. If second attempt still has ANY `VALIDATION:FAIL` → present to user:
+  3. If second attempt returns `CAMINHO:OK` for all files → proceed normally.
+  4. If second attempt still has ANY `FAIL` → present to user:
      ```
      ⚠️ {Agent Name}'s output was not generated: {path}
 
@@ -649,26 +603,23 @@ Use the **stored transformed path** (after Output Path Transformation Steps 1 an
 - If the step does not declare an `outputFile` (e.g., steps that only produce inline console output) → skip output validation.
 - Checkpoint steps (`type: checkpoint`) are exempt — their output is the user's response, not a file.
 
-**IMPORTANT**: Do NOT rely on reading the file with the Read tool to "verify" output. The Read tool returns content that can be misinterpreted. Use ONLY the bash `test -s` command — its output is binary and cannot be hallucinated.
+**IMPORTANT**: Do NOT rely on reading the file with the Read tool to "verify" output. The Read tool returns content that can be misinterpreted. Use ONLY the `conferir` command — its last line is binary and cannot be hallucinated.
 
 ### Output Contract Validation
 
 If the step's frontmatter declares an `output_contract:` field, apply structured validation
-AFTER the basic file existence check passes:
+in the same call as the basic file existence check (Post-Step Output Validation):
 
-1. **Required sections check**: If `output_contract.required_sections` is defined,
-   verify each required section exists in the output file:
-   ```bash
-   grep -c "^## " "{transformed outputFile path}" | xargs -I {} test {} -ge {min_sections} && echo "SECTIONS:PASS" || echo "SECTIONS:FAIL"
-   ```
+1. **Required sections check**: If `output_contract.required_sections` is defined, add
+   `--secoes {min_sections}` to the same `conferir` command: the file needs at least that many
+   lines starting with `## `.
 
-2. **TL;DR check**: If the output contract requires a TL;DR section:
-   ```bash
-   grep -q "^## TL;DR" "{transformed outputFile path}" && echo "TLDR:PASS" || echo "TLDR:FAIL"
-   ```
+2. **TL;DR check**: If the output contract requires a TL;DR section, add `--tldr` to the same
+   `conferir` command.
 
-3. **If any check fails**:
-   - Present to user: "⚠️ Output from {Agent Name} is incomplete: {which checks failed}"
+3. **If a check fails** (the last line is `CAMINHO:REPROVADO {motivo}`, with a motivo other than
+   `arquivo ausente ou vazio`; the script reports the first one):
+   - Present to user: "⚠️ Output from {Agent Name} is incomplete: {motivo}"
    - Options as numbered list:
      1. Accept anyway and continue
      2. Retry step (re-execute the agent)
@@ -752,85 +703,34 @@ When a step has `on_reject: {step-id}` (a review step):
    lines under each file, not the "não é texto" line of **Notas**), one per line as
    `{arquivo} — {motivo}`, then the lines under `**Notas:**` in that report, as they are written,
    and repeat every "não rodou" warning of this run (checker and source check) and the line of
-   every file left unchecked by the safe-name rule. If the approved
+   every file left unchecked by the safe-name rule. List the same way every file the path script
+   did not check (see Output Path Transformation). If the approved
    text still contains `[PREENCHER: …]`, ask the user for each missing piece of real information
    and write it into the text before approving.
 
-### Dashboard Handoff (between steps)
-
-Only if `dashboard_enabled` (otherwise skip this entire section). After a step
-completes output and there IS a next step:
-
-1. **Write delivering state** — Write `crews/{name}/state.json` with:
-   - Current step's agent: `"status": "delivering"`
-   - Next step's agent: `"status": "idle"`
-   - All other agents unchanged
-   - Pipeline `"status": "running"`
-   - Add or update `"handoff"`:
-     ```json
-     "handoff": {
-       "from": "{current agent id}",
-       "to": "{next agent id}",
-       "message": "{one-sentence summary of what was produced, written in the user's language}",
-       "completedAt": "{ISO timestamp now}"
-     }
-     ```
-   - `"updatedAt"`: now
-
-2. _(No delay — proceed immediately to working state)_
-
-2. **Write working state** — Write `crews/{name}/state.json` again with:
-   - Current agent: `"status": "done"`
-   - Next agent: `"status": "working"`
-   - Keep the `"handoff"` object from step 1 unchanged
-   - `"updatedAt"`: now
-
 ### Step Execution Order (Summary)
 
 For reference, the complete execution order for each pipeline step is:
 
 ```
 0. Agent deselection check (skip step if its agent was deselected)
-0b. Dashboard update (state.json) — only if dashboard_enabled
-1. Pre-Step Input Validation (bash gate)
+0b. Escritório command (passo or checkpoint) — only if it is on
+1. Pre-Step Input Validation (script gate: `entrada`)
 2. Read step file
 3. Check execution mode and execute (subagent / inline / checkpoint)
-4. Post-Step Output Validation (bash gate)
+4. Post-Step Output Validation (script gate: `conferir`)
 5. Veto Condition Enforcement
-6. Dashboard Handoff (to next step) — only if dashboard_enabled
 ```
 
-Steps 1 and 4 are binary bash gates. If either fails, the pipeline does NOT advance — the user is consulted.
+Steps 1 and 4 are binary script gates. If either fails, the pipeline does NOT advance — the user is consulted.
 
 ### After Pipeline Completion
 
 1. Save final output to `crews/{name}/output/{run_id}/{filename}.md`
    (The run folder was created during initialization — no separate date subfolder needed)
-1b. **Update dashboard** (only if `dashboard_enabled`; otherwise skip to step 2 below). Write `crews/{name}/state.json` with:
-    - `"status": "completed"`
-    - All agents: `"status": "done"`
-    - `"updatedAt"`: now
-    - `"completedAt"`: now
-    - `"startedAt"`: preserve from existing `state.json`
-    - Keep existing `"handoff"` object
-
-### Post-Completion Cleanup (only if `dashboard_enabled`)
-
-After writing the final "completed" state to `crews/{name}/state.json`:
-
-1. Add the `completedAt` field (or `failedAt` if status is `failed`) with the current ISO timestamp
-2. Copy `state.json` to the run output folder for permanent history:
-   ```bash
-   cp "crews/{name}/state.json" "crews/{name}/output/{run_id}/state.json"
-   ```
-3. Leave the working copy of `crews/{name}/state.json` in place — do not delete it and
-   do not add an artificial delay. A dashboard watching the file already sees the
-   "completed" status the moment it's written; the next run's initialization (step 6)
-   overwrites this file from scratch. There is nothing to clean up.
-
-This archives the run state for the `runs` command while keeping crew history available.
+1b. **Escritório** — if it is on, run `concluir` (see "Escritório" above).
 
-2. **Update crew memory** — write to BOTH files (runs after Post-Completion Cleanup above):
+2. **Update crew memory** — write to BOTH files:
 
    ### 2a. Update `memories.md` (living preferences)
 
@@ -947,6 +847,7 @@ This archives the run state for the `runs` command while keeping crew history av
 - If a step file is missing, inform the user and suggest running `/opencrew edit {crew}` to fix.
 - If company.md is empty, stop and redirect to onboarding.
 - Never continue past a checkpoint without user input.
+- When the run is aborted: if the Escritório is on, run `falhar` (see "Escritório" above).
 
 ## Pipeline State
 

package/templates/_opencrew/core/scripts/caminho/argumentos.mjs

@@ -0,0 +1,49 @@
+// Linha de comando do `caminho.mjs`: a crew, a ação, as opções e a linha de uso.
+// Spec: fase-r3-runner-em-uso-real.md, §3 e §6 (repositório do OpenCrew).
+import { MSG } from '../comum.mjs';
+import { ACOES } from './nucleo.mjs';
+
+export const USO = 'Uso: node _opencrew/core/scripts/caminho.mjs <crew> <ação> --run <id> [opções]';
+
+const LISTA = ACOES.join(', ');
+const OPCAO = /^--(run|arquivo|secoes|tldr)(?:=(.*))?$/s;
+const RUN = /^(?!\.+$)[A-Za-z0-9._-]+$/;
+const INTEIRO = /^[1-9]\d{0,8}$/;
+
+/** Texto que veio da linha de comando e volta numa mensagem: uma linha só, até 200 caracteres. */
+export const limpar = (valor) => String(valor).replace(/\s+/g, ' ').trim().slice(0, 200);
+
+/**
+ * `argv` → `{ crew, acao, run, arquivo, secoes, tldr }`. Os dois primeiros argumentos soltos são
+ * a crew e a ação. Opção vale como `--nome valor` e `--nome=valor`; `--tldr` não leva valor.
+ * Opção ausente fica `undefined`.
+ */
+export function lerArgs(argv) {
+  const soltos = [];
+  const opcoes = {};
+  for (let i = 0; i < argv.length; i++) {
+    const [, nome, colado] = argv[i].match(OPCAO) ?? [];
+    if (!nome) soltos.push(argv[i]);
+    else if (nome === 'tldr') opcoes.tldr = true;
+    else if (colado !== undefined) opcoes[nome] = colado;
+    else opcoes[nome] = i + 1 < argv.length && !OPCAO.test(argv[i + 1]) ? argv[++i] : '';
+  }
+  const [crew, acao] = soltos.filter((s) => !s.startsWith('--'));
+  return { crew, acao, tldr: false, ...opcoes };
+}
+
+/**
+ * O que falta ou está errado na linha de comando, antes de olhar o disco. `conferir` recebe um
+ * caminho já resolvido: é a única ação que não precisa de `--run`.
+ * @returns {string|null} o motivo em PT-BR, ou `null`
+ */
+export function erroDeArgumentos({ crew, acao, run, arquivo, secoes }) {
+  if (!crew) return 'Falta o nome da crew.';
+  if (!acao) return `Falta a ação. Ações: ${LISTA}.`;
+  if (!ACOES.includes(acao)) return `Ação desconhecida: ${limpar(acao)}. Ações: ${LISTA}.`;
+  if (acao !== 'conferir' && !run) return MSG.faltaOpcao('--run');
+  if (run !== undefined && !RUN.test(run)) return 'O --run só aceita letras, dígitos, ponto, sublinhado e hífen.';
+  if (acao !== 'pasta' && !arquivo) return MSG.faltaOpcao('--arquivo');
+  if (secoes !== undefined && !INTEIRO.test(secoes)) return 'O --secoes é um número inteiro a partir de 1.';
+  return null;
+}

package/templates/_opencrew/core/scripts/caminho/disco.mjs

@@ -0,0 +1,36 @@
+// O que o `caminho.mjs` faz no disco: lê nomes de pastas, confere se um arquivo tem conteúdo, lê
+// um arquivo e cria pastas. Nunca cria, altera nem apaga arquivo.
+// Spec: fase-r3-runner-em-uso-real.md, regra 6 (repositório do OpenCrew).
+import { mkdirSync, readFileSync, readdirSync, statSync } from 'node:fs';
+
+/** Os nomes das pastas que ficam direto em `pasta`; pasta que não existe não tem nenhuma. */
+export function pastasDe(pasta) {
+  try {
+    return readdirSync(pasta, { withFileTypes: true }).filter((e) => e.isDirectory()).map((e) => e.name);
+  } catch {
+    return [];
+  }
+}
+
+export function ehPasta(caminho) {
+  try {
+    return statSync(caminho).isDirectory();
+  } catch {
+    return false;
+  }
+}
+
+/** É um arquivo, existe e não está vazio? */
+export function temConteudo(arquivo) {
+  try {
+    const info = statSync(arquivo);
+    return info.isFile() && info.size > 0;
+  } catch {
+    return false;
+  }
+}
+
+export const lerTexto = (arquivo) => readFileSync(arquivo, 'utf8');
+
+/** Cria a pasta com as pastas-mãe; pasta que já existe não é erro. */
+export const criarPasta = (pasta) => { mkdirSync(pasta, { recursive: true }); };