@orkastery/cli 0.5.6 → 0.6.1

package/assets/adapters-en/claude-code/commands/check.md

@@ -0,0 +1,46 @@
+---
+description: Conducts the thread's CHECK phase and consolidates a single verdict.
+argument-hint: "<thread-id>"
+allowed-tools: Bash(ork:*), Read, Glob, Grep
+---
+
+# /check
+
+CHECK phase (F4): verification against the baseline, the five review axes, security with zero blockers, a delegation audit and exactly one verdict.
+
+## What this command does
+
+1. Re-runs everything on the real HEAD:
+
+```bash
+ork verify <thread>
+ork worktree audit <thread>
+```
+
+2. Runs the four reviewers from the catalog over the declared scope: `code-reviewer`,
+   `security-auditor`, `test-engineer` and `web-performance-auditor`. Use the
+   `ork-check` subagent and its siblings when you want to isolate each one's context.
+
+3. Reads the ledger for the delegation audit:
+
+```bash
+ork phase list <thread>
+```
+
+4. Consolidates ONE verdict (PASSOU = passed, PRECISA DE MUDANCA = needs changes, BLOQUEADO = blocked) and, if the mode pauses, opens the request
+   and waits. The builder answers through the authenticated channel (the host's native dialog, or
+   `/ork gate <thread> <pedido> <resposta>` in Telegram); the agent never answers for the builder:
+
+```bash
+ork gate request <thread>
+```
+
+## Adapter rules
+
+- **Zero business logic here.** This command turns intent into an `ork` call and nothing more.
+  Validating the mode, building the prompt, deciding the gate and proving the delivery is the core's job.
+- **The #TAG comes from the request, not from configuration.** The mode comes from `ork modos --do-pedido`, which uses the
+  same function as the core; without a tag, the manifest's `conduction.default_mode` applies. Validation
+  against `conduction.allowed_modes` happens inside `ork thread new`, never here.
+- **No writing product code in this command.** Writing is the job of the session that `ork`
+  dispatches, with the prompt recorded and its sha in the ledger.

package/assets/adapters-en/claude-code/commands/go.md

@@ -0,0 +1,46 @@
+---
+description: Conducts the thread's GO phase through `ork`, inside the isolated worktree.
+argument-hint: "<thread-id> [task]"
+allowed-tools: Bash(ork:*), Read, Glob, Grep
+---
+
+# /go
+
+GO phase (F3): implementation slice by slice, one atomic commit per task, inside the thread's worktree. Code is written by the dispatched session, never by this command.
+
+## What this command does
+
+1. Ensures the worktree and records the baseline BEFORE the first line of code:
+
+```bash
+ork worktree ensure <thread>
+ork verify <thread> --baseline
+```
+
+2. Dispatches the task:
+
+```bash
+ork phase run <thread> GO --prompt "<tarefa do PLAN, uma por vez>"
+```
+
+3. Re-runs the verification on the real HEAD and compares it with the baseline:
+
+```bash
+ork verify <thread>
+```
+
+4. Checks that the worktree stays consistent in git itself:
+
+```bash
+ork worktree audit <thread>
+```
+
+## Adapter rules
+
+- **Zero business logic here.** This command turns intent into an `ork` call and nothing more.
+  Validating the mode, building the prompt, deciding the gate and proving the delivery is the core's job.
+- **The #TAG comes from the request, not from configuration.** The mode comes from `ork modos --do-pedido`, which uses the
+  same function as the core; without a tag, the manifest's `conduction.default_mode` applies. Validation
+  against `conduction.allowed_modes` happens inside `ork thread new`, never here.
+- **No writing product code in this command.** Writing is the job of the session that `ork`
+  dispatches, with the prompt recorded and its sha in the ledger.

package/assets/adapters-en/claude-code/commands/goal.md

@@ -0,0 +1,55 @@
+---
+description: Opens the thread for the request and conducts the GOAL phase through `ork`.
+argument-hint: "<builder request, with optional #TAG>"
+allowed-tools: Bash(ork:*), Read, Glob, Grep
+---
+
+# /goal
+
+GOAL phase (F1): a verifiable goal, exploration of the real repository, explicit assumptions and criteria that become claims with a command. GOAL does not implement.
+
+## What this command does
+
+1. Extracts the conduction mode from the request itself, without reimplementing the parsing:
+
+```bash
+MODO=$(ork modos --do-pedido "$ARGUMENTS")
+```
+
+2. Opens the thread with that mode (`ork` validates against `conduction.allowed_modes` and refuses what
+   the project does not allow):
+
+```bash
+ork thread new "<nome curto da demanda>" --mode "$MODO" --worktree auto
+```
+
+3. Dispatches the phase, with the builder's full request:
+
+```bash
+ork phase run <thread> GOAL --prompt "$ARGUMENTS"
+```
+
+4. Records as a claim everything GOAL stated, with the command that proves each statement, and
+   re-runs:
+
+```bash
+ork claims add <thread> <arquivo> --claim "<alegacao>" --verificar "<comando>" --fase GOAL
+ork verify <thread> --so-claims
+```
+
+5. If the mode pauses in this block, presents the evidence to the builder and stops. The request comes from the core, and the
+   release is only recorded when the builder answers through the authenticated channel:
+
+```bash
+ork gate request <thread>
+```
+
+## Adapter rules
+
+- **Zero business logic here.** This command turns intent into an `ork` call and nothing more.
+  Validating the mode, building the prompt, deciding the gate and proving the delivery is the core's job.
+- **The #TAG comes from the request, not from configuration.** The mode comes from `ork modos --do-pedido`, which uses the
+  same function as the core; without a tag, the manifest's `conduction.default_mode` applies. Validation
+  against `conduction.allowed_modes` happens inside `ork thread new`, never here.
+- **No writing product code in this command.** Writing is the job of the session that `ork`
+  dispatches, with the prompt recorded and its sha in the ledger.

package/assets/adapters-en/claude-code/commands/master.md

@@ -0,0 +1,54 @@
+---
+description: Closes the thread with a typed POSTMORTEM and the human score from 0 to 5.
+argument-hint: "<thread-id>"
+allowed-tools: Bash(ork:*), Read, Glob, Grep
+---
+
+# /master
+
+MASTER phase (F6): typed POSTMORTEM, MASTER log in the frozen contract and the human score with a justification. A delivery without a MASTER log did not happen.
+
+## What this command does
+
+1. Shows the builder the failure classes from the fixed catalog:
+
+```bash
+ork master classes
+```
+
+2. Asks the owner for the score through the channel that carries proof (RM-048). **The score belongs to the human, in every mode.**
+   This command never makes up a score and never writes `--por` on anyone's behalf:
+
+```bash
+ork master pedir <thread> --formato terminal
+```
+
+   Show the line as it comes. The owner replies through Telegram (`<codigo> <0 a 5> <porque>`) and the core
+   records the score with the ingress receipt. `ork master <thread> --score ... --por` called from here is
+   refused with `master.prova-de-canal`; from their own terminal, outside the host, the owner can use it.
+3. Check that the score made it into the ledger:
+
+```bash
+ork master --todas
+```
+
+4. In modes with no MASTER pause, the delivery is accepted unless the builder says otherwise;
+   `ork master --todas` shows the deliveries with the ledger-derived index, including those already scored.
+   To close by default, always pass the thread, so that only yours is closed:
+
+```bash
+ork master <thread> --aceitar-omissao
+```
+
+   Without the thread, the command accepts ALL of the project's delivered threads, including those from other parallel
+   workstreams; `ork master --aceitar-omissao --dry-run` shows which ones, without recording.
+
+## Adapter rules
+
+- **Zero business logic here.** This command turns intent into an `ork` call and nothing more.
+  Validating the mode, building the prompt, deciding the gate and proving the delivery is the core's job.
+- **The #TAG comes from the request, not from configuration.** The mode comes from `ork modos --do-pedido`, which uses the
+  same function as the core; without a tag, the manifest's `conduction.default_mode` applies. Validation
+  against `conduction.allowed_modes` happens inside `ork thread new`, never here.
+- **No writing product code in this command.** Writing is the job of the session that `ork`
+  dispatches, with the prompt recorded and its sha in the ledger.

package/assets/adapters-en/claude-code/commands/onboarding.md

@@ -0,0 +1,22 @@
+---
+description: Conducts or resumes the project interview following the agenda from the ork core.
+argument-hint: "<onboarding request>"
+allowed-tools: Bash(ork:*)
+---
+
+# /onboarding
+
+Run `ork onboarding` to get the agenda and `ork onboarding show --json` to look up
+the current answers. Work through the pending items following the agenda returned by the core. Do not duplicate
+steps or validation in this host, and do not make up answers on the builder's behalf.
+
+Record the requested public answer with `ork onboarding set <etapa> --conteudo <JSON> --por <quem>`.
+Pass the JSON as an argument, with proper shell escaping; never execute the text you received.
+Ask only for variable names for credentials. Secret values stay in the process environment
+or in the host's vault (in Hermes, `~/.hermes/.env`); do not read them or carry values into the
+conversation, the onboarding or the ledger.
+
+A requested reset uses `ork onboarding reset [etapa]`. Optional publication uses
+`ork onboarding sync --json`; present the typed degradation reason without blocking the interview.
+The memory choice guides the manifest, without editing it automatically.
+Finish with the state from `ork onboarding show --json`. Do not create a thread just to interview.

package/assets/adapters-en/claude-code/commands/ork.md

@@ -0,0 +1,126 @@
+---
+description: Recognizes orkastery maestro and conducts requests, resumptions and status in the conversation with the Maestro/Builder.
+argument-hint: "[natural-language request|thread|status|board|plan|doctor|modos]"
+allowed-tools: Bash(ork:*), Read, mcp__orkastery__ork_thread_status, mcp__orkastery__ork_phase_list, mcp__orkastery__ork_hitl_pending, mcp__orkastery__ork_observe, mcp__orkastery__ork_artifact_read, mcp__orkastery__ork_claims_list, mcp__orkastery__ork_git_status, mcp__orkastery__ork_thread_new, mcp__orkastery__ork_phase_run, mcp__orkastery__ork_preflight
+---
+
+# /orkastery:ork
+
+Native entry point of the plugin enabled in the project: `/orkastery:ork`. Copying the files through the
+installer still requires native activation; `/ork` alone is not a guaranteed alias.
+
+This entry point is already loaded by the owner's invocation. Do not invoke `Skill(orkastery:ork)`
+or another command to reload these instructions. Conduct the request with the tools
+already allowed.
+The eight MCP queries and creating/dispatching a thread from this entry point are valid for the invocation turn;
+they do not persist on their own into the next messages. Creating/dispatching requires a demand and scope authorized
+by the owner, a resolved mode and the core's preflight. Do not reload the skill to obtain permissions.
+These grants do not enable MCP, do not authorize other mutations and do not approve gates or human answers.
+
+Read the common contract with `Read`, without calling `Skill` to load the bootstrap:
+@${CLAUDE_PLUGIN_ROOT}/skills/core/orkastery-bootstrap/SKILL.md
+
+If the contract is already in context, use it without rereading. If the file is missing,
+report an incomplete installation; do not invent another flow.
+
+Orkastery's conversational entry point. Use the common contract to conduct the owner's intent through the core. Do not limit an execution request to pointing to another
+slash command. If you received a request and have the necessary tools, carry out the routing.
+The phase commands remain available as shortcuts; the owner does not need to know them.
+
+## Recognize the intent
+
+The literal phrase `orkastery maestro`, in a clean session, asks for a read of the overview.
+Discover the tool with `ToolSearch` on `select:mcp__orkastery__ork_maestro`,
+then query the pinned project. A query does not open a thread or a dispatch.
+With no project named, also offer the network overview (RM-054): `ork network roadmap`
+(all known projects, the threads of all machines, sources, freshness and gaps)
+or `mcp__orkastery__ork_network_roadmap` (the pinned project, on all machines), shown as it comes.
+The person's machines (RM-053) come from `ork network status` or from `mcp__orkastery__ork_network_status`
+(in MCP, only the pinned project on each machine), shown as it comes: a gap is never "no machines".
+MCP serves only the pinned project; `projeto` in any tool only checks that
+project (`projeto.fora-do-servidor` when it is a different one). A request for another project goes to the CLI with
+`--projeto <nome>` (RM-052). Read "Projeto consultado" (project queried) and "Não lido" (not read) before answering.
+A missing/ambiguous project requires resolving the context allowed by the core.
+If you already received a phase/thread/worktree, execute the received block, without recursion.
+Missing MCP or denied authentication remains a blocker; do not switch runtime,
+provider or sandbox. The CLI query `ork maestro --json` does not grant mutations.
+
+HITL usability is top priority: bullets, a recommendation and labeled options,
+internal UUID and preserved cancellation. The conductor session uses
+`mcp__orkastery__ork_request_decision`; the child session never answers on the owner's behalf.
+
+Conduction HITL is a selection (RM-057): 3 to 5 alternatives, exactly one with the
+"Recommendation" seal. Never ask the owner for an "I confirm" in free text or to paste text; the request
+they pasted with explicit authorization counts as their instruction, within that authorization.
+A doubt within the authorization becomes `ork decisao registrar` and the thread goes on. Text only when the
+factory cannot go on by itself and the owner needs to run a command in the terminal: show the
+exact command.
+
+| Owner request | Agent action |
+|---|---|
+| New demand | Resolve the mode through the core, check the preflight and open/dispatch the corresponding thread. |
+| "Continue" or an existing thread/roadmap | Read the state and the last result; resume the next authorized step, without duplicating the dispatch. |
+| "How is it going?" or status | Query the known thread; present proven progress, the blocker and the next step. |
+| Roadmap status | Run `ork network roadmap` (with `--projeto <nome>` when the owner names the project) and show the text as it comes: it brings the threads of all machines, the reservations and the source and time of each part; `ork roadmap status` reads only this machine. Do not write your own roadmap report or deduce it from the board or the overview: zero threads is not an empty roadmap, and a gap or "Nao consultado" (not queried) is never an empty roadmap. |
+| Decision or answer | Correlate it with the presented request/gate, relay it through the supported path and check the result. |
+| Onboarding | Use the agenda of `ork onboarding` and resume the existing steps. |
+| board, plan, doctor or modos | Run the corresponding query and interpret the result for the owner's intent. |
+
+## Core sources
+
+Prioritize Orkastery's MCP tools when discovered in this session, with the project
+pinned by the server. In Claude, the installed `orkastery` server exposes full names such as
+`mcp__orkastery__ork_thread_status`. If there are deferred tools, use `ToolSearch` with
+`select:mcp__orkastery__ork_thread_status,mcp__orkastery__ork_artifact_read` for those reads;
+for another operation, select its full name as actually exposed. Do not try `select:ork_thread_status`
+or guess another namespace. The initial MCP activation and the owner's consent remain native. `ork_thread_status`, `ork_phase_list` and `ork_hitl_pending` read
+state; `ork_thread_new` and `ork_phase_run` open/dispatch; `ork_observe` queries the dispatched
+native session. When a real pause/escalation allows it and a request is missing, use
+`ork_gate_request(threadId, motivo?)`; never create a request for a status query.
+`ork_request_decision(threadId, pedidoId)` presents the dialog to the owner:
+the answer comes through the host, never through an answer argument or an identity invented by the model.
+
+The CLI queries below remain useful when the corresponding tool is not available:
+
+```bash
+ork thread status <thread>
+ork phase list <thread>
+ork network roadmap [--projeto <nome>]
+ork pulse --json
+ork board plan
+ork doctor
+ork modos
+ork master
+```
+
+Use only the necessary queries. Do not run all of them on every message. The preflight belongs to the
+start of a dispatch or to a relevant environment change; a status question does not restart
+onboarding or work. If the thread is ambiguous, clarify before changing its state.
+Pauses listed in the mode's blocks are expected. To say that the owner needs to answer
+now, identify a current pending item in the thread's state/last result, with a matching gate,
+request or event. A new thread with no phase executed is not waiting on assumptions
+just because the mode's f12 block provides for that pause.
+
+## Continuity
+
+Preserve the thread/session mode, decisions and authorizations. Proceed with authorized work instead
+of ending with "may I continue?". Ask when the mode or a real ambiguity requires
+the owner's intervention, and explain what the answer unlocks. Do not approve gates on their behalf.
+
+With an existing dispatch, query `ork_observe` and handle the current native wait. Do not replace
+observation with long loops of `phase list`, sleeps or completion regex over history.
+If MCP is missing and the sandbox blocks `.git`, report that the native transport installation is pending;
+do not repeat the denied mutation or change the sandbox. Tell a native permission apart from an Ork gate.
+
+Before the dispatch, use `ork_preflight({modo})`; CLI alternative: `ork doctor --modo <modo>`. The probe follows the per-block setup, without a global inventory, and does not prove authentication, gates or delivery.
+For HEADs and Git state, query `ork_git_status`; do not invent SHAs or replace the transport with Bash Git.
+The `worktree` child profile is an opt-in of the project's installation; do not enable it through a tool argument
+or a configuration edit to bypass a block. Preserve the configured profile and the native permissions.
+
+The conductor session dispatches and follows up; a session that already received a phase executes that phase,
+without redispatching itself. The core keeps validating phases, evidence and gates.
+
+Show the result, the last confirmed progress and what happens now. Record a checkpoint
+before a future resumption; do not promise notification beyond the session's capabilities.
+Conclude with effective delivery and validation, distinguishing what still depends on CHECK, SHIP or
+human score. The list of executed commands is auxiliary diagnostics, not the owner's experience.

package/assets/adapters-en/claude-code/commands/plan.md

@@ -0,0 +1,47 @@
+---
+description: Conducts the thread's PLAN phase through `ork`.
+argument-hint: "<thread-id> [note]"
+allowed-tools: Bash(ork:*), Read, Glob, Grep
+---
+
+# /plan
+
+PLAN phase (F2): sliced tasks with `touch_paths` and a verify per task, decisions D1..Dn with a single home. PLAN does not implement.
+
+## What this command does
+
+1. Reads the real state of the thread before anything else:
+
+```bash
+ork thread status <thread>
+```
+
+2. Dispatches the phase:
+
+```bash
+ork phase run <thread> PLAN --prompt "<o que o plano precisa cobrir>"
+```
+
+3. Reserves the regions the plan declared it would touch, so that another thread does not write over them:
+
+```bash
+ork lease acquire "path:<glob>" --thread <thread> --motivo "PLAN reservou a regiao"
+```
+
+4. Exports the typed handoff to the next phase, instead of relying on the session's memory:
+
+```bash
+ork handoff export <thread> --proxima-fase GO
+```
+
+5. If the mode pauses, presents the tradeoffs with options and a recommendation, and waits for the verdict.
+
+## Adapter rules
+
+- **Zero business logic here.** This command turns intent into an `ork` call and nothing more.
+  Validating the mode, building the prompt, deciding the gate and proving the delivery is the core's job.
+- **The #TAG comes from the request, not from configuration.** The mode comes from `ork modos --do-pedido`, which uses the
+  same function as the core; without a tag, the manifest's `conduction.default_mode` applies. Validation
+  against `conduction.allowed_modes` happens inside `ork thread new`, never here.
+- **No writing product code in this command.** Writing is the job of the session that `ork`
+  dispatches, with the prompt recorded and its sha in the ledger.

package/assets/adapters-en/claude-code/commands/ship.md

@@ -0,0 +1,45 @@
+---
+description: "Delivers the thread through `ork ship`: serialized merge and proven push."
+argument-hint: "<thread-id> [--para <branch>]"
+allowed-tools: Bash(ork:*), Read, Glob, Grep
+---
+
+# /ship
+
+SHIP phase (F5): merge serialized by lease, update against the base, push proven by command and a rollback plan. No `git push` by hand: a push by hand is not proven, and the per-project adapter guard (`ork adapter install claude-code`) blocks it.
+
+## What this command does
+
+1. Resyncs when the base has moved:
+
+```bash
+ork worktree sync <thread>
+```
+
+2. Rehearses the whole delivery before touching anything:
+
+```bash
+ork ship <thread> --para main --dry-run
+```
+
+3. Delivers, with the authorization recorded:
+
+```bash
+ork ship <thread> --para main --autorizar-push "<quem>"
+```
+
+4. Shows the proof to the builder: `mergeSha`, `shaRemoto` and `pushVerificado` in the ledger.
+
+```bash
+ork phase list <thread>
+```
+
+## Adapter rules
+
+- **Zero business logic here.** This command turns intent into an `ork` call and nothing more.
+  Validating the mode, building the prompt, deciding the gate and proving the delivery is the core's job.
+- **The #TAG comes from the request, not from configuration.** The mode comes from `ork modos --do-pedido`, which uses the
+  same function as the core; without a tag, the manifest's `conduction.default_mode` applies. Validation
+  against `conduction.allowed_modes` happens inside `ork thread new`, never here.
+- **No writing product code in this command.** Writing is the job of the session that `ork`
+  dispatches, with the prompt recorded and its sha in the ledger.

package/assets/adapters-en/codex/skills/ork/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: ork
+description: "Recognizes orkastery maestro in a clean session: queries the overview, resumes threads and presents native decisions in the Codex conversation with the Maestro/Builder."
+license: MIT
+---
+
+# Orkastery in Codex
+
+When you receive `orkastery maestro` literally, the first action is the `ork_maestro` tool of the
+`orkastery` MCP server, discovered in the namespace actually exposed: it queries the pinned
+project. With the tool exposed, do not run `ork maestro`, `ork doctor`, `ork onboarding` or
+`ork experiencia show` in the shell before it or in its place: the CLI resolves the project by the session directory, and that is the
+class of error the phrase avoids (Codex activation proof, RM-032).
+
+Only after `ork_maestro` (or, without MCP, `ork maestro --json`), query `ork experiencia show --json`
+in the session's project. When `experience` is true,
+read `../core/<skill>/SKILL.md`, using the name returned in `skill` by the core:
+`orchestration-experience-pt-br` or `orchestration-experience`. Language, timezone and depth
+come from the same query. If false, do not activate the pack. The dedicated block in AGENTS.md also
+points to this catalog; installation does not change native permissions.
+
+After `ork_maestro`, the phrase `orkastery maestro` still asks only for the overview,
+without opening work. With no project named, also offer the network overview
+(`ork_network_roadmap`, or `ork network roadmap` in the CLI), with sources, freshness and gaps.
+Follow the context selection and the limits of the common bootstrap.
+Without MCP, the `ork maestro --json` query stays read-only if the CLI is
+available; mutations without native transport stay pending. Never use Bash Git
+or a sandbox change as substitutes. A child session continues the received phase.
+
+HITL is top priority in the presentation: short bullets, a recommendation and options
+with clear labels; internal UUID. Use `ork_request_decision` in the conductor session and preserve
+the literal answer/cancellation of the elicitation. Do not use a generic agent question
+as gate approval, nor text in toolargs as human identity.
+
+Conduction HITL is a selection (RM-057): 3 to 5 alternatives, exactly one with the
+"Recommendation" seal. Never ask the owner for an "I confirm" in free text or to paste text; the request
+they pasted with explicit authorization counts as their instruction, within that authorization.
+A doubt within the authorization becomes `ork decisao registrar` and the thread goes on. Text only when the
+factory cannot go on by itself and the owner needs to run a command in the terminal: show the
+exact command.
+
+Use the `orkastery-bootstrap` skill from the same installed catalog to conduct the request.
+The owner talks about the goal; you operate the `ork` core and present the result and the next
+step. Preserve the thread's mode and authorizations. If you already received an Orkastery phase,
+run that phase within the received scope, without redispatching yourself.
+
+- Waits: never start verify, build or the suite with `&` inside the command, because the process gets lost and the session waits for a notice that never comes; run `ork verify` in the foreground, with `timeout` (it waits its turn in the heavy-resource queue), or use the host's background execution, which tells you when it finishes; never wait with `pgrep -f` whose pattern shows up in the command itself, because the loop finds itself and never ends: wait for the output file with a deadline, or for the saved PID.
+
+When discovered, prefer the MCP tools bound to the project by the server:
+`ork_thread_status`, `ork_phase_list`, `ork_hitl_pending`, `ork_thread_new(nome, modo)`,
+`ork_phase_run(threadId, fase, prompt, runtime?, model?, effort?, dryRun?)`, `ork_observe(threadId)`
+and `ork_request_decision(threadId, pedidoId)`. Use the namespace actually exposed, without assuming another project.
+
+- New request: resolve the mode through `ork`, check preflight and open/dispatch the thread.
+- Resumption: read `ork thread status <thread>` and the last result in `ork phase list <thread>`;
+  continue the authorized work without repeating onboarding, approval or implementation.
+- Roadmap status: use `ork_network_roadmap` (or `ork network roadmap --projeto <nome>`) and show the
+  text as it comes, with the threads of all machines, the sources and the gaps; `ork_roadmap_status` is
+  only for this machine. Do not write your own roadmap report: a gap is never an empty roadmap.
+- The person's machines (RM-053): use `ork_network_status` (or `ork network status`) and show the text
+  as it comes, with the beat of each machine, the source and the gaps; a gap is never "no machines".
+- Status: present the thread's evidence; `ork pulse --json` shows who needs to act.
+  The pauses of the mode's blocks are expected: only say "waiting for you" with a current human
+  dependency proven in the state/last result, identifying the gate, request or event.
+  A new thread with no phase run and no open request is not yet awaiting a verdict.
+- Existing dispatch: check `ork_observe` for the current native progress or block;
+  do not wait for completion with long `phase list` loops, sleeps or regex over history.
+- Decision: if a real pause/escalation allows it and a request is missing, use `ork_gate_request(threadId, motivo?)`;
+  never create a request for status. Correlate thread/request and use `ork_request_decision` to present
+  the native dialog. The answer is provided by the owner to the host; never invent human identity
+  or pass an answer as a model argument. A native permission does not approve another gate.
+- Delivery: distinguish what was implemented, validated, published and what is still pending.
+
+Phases, checks and gates belong to the core. The phase skills and the checklists of the
+catalog come with this entry. If the common skill is missing, report an incomplete
+installation instead of inventing another methodology.
+
+Use the project's `ork` executable. If it is not on the session PATH, the installer recorded
+this path: `{{ork_bin}}`. Do not change global configuration to resolve the PATH.
+
+Without MCP and with `.git` protected by the sandbox, report a pending installation of the native
+transport; do not repeat the denied mutation, do not create the thread by other means and do not widen the sandbox.
+
+No background monitor is created by this skill. Follow along while the session is
+active and leave a checkpoint for resumption, with the last result and next step proven.