Update to DXIR

{
  "description": "Connect the current Codex conversation and project to a user-selected DXIR Action Room, perform its report-owned tasks in Codex, and synchronize progress and artifact evidence. Use when the user provides an Action Room link or asks to work on the already-bound Room.",
  "included_files": [
    {
      "relative_path": "references/documents.md",
      "size_in_bytes": 5754
    },
    {
      "relative_path": "references/execution.md",
      "size_in_bytes": 6766
    },
    {
      "relative_path": "references/local-protocol.md",
      "size_in_bytes": 10957
    },
    {
      "relative_path": "references/research.md",
      "size_in_bytes": 17926
    }
  ],
  "name": "action-room",
  "skill_md_contents": "---\nname: action-room\ndescription: Connect the current Codex conversation and project to a user-selected DXIR Action Room, perform its report-owned tasks in Codex, and synchronize progress and artifact evidence. Use when the user provides an Action Room link or asks to work on the already-bound Room.\n---\n\nKeep execution, questions, permission approvals, and interruption in the user's ordinary Codex conversation. Action Room displays the selected Room's work and evidence. Connecting does not authorize unrelated work or external actions.\n\n## Connect the selected conversation\n\nFirst use [connection and recovery](../research-strategy/SKILL.md#connect-and-recover-in-this-conversation) to read the connected account and handle native login prompts or missing tools in this same conversation. For a Room request, resume the selected Room's read after connecting; do not open research service selection or replay mutations. Preserve existing local work and bindings.\n\nFor a Room inherited from an approved research/strategy project, use the research-strategy skill's `dxir_handoff`/`dxir_room` route instead of steps 1–4 below. Use that route for every Room operation so project revocation remains enforced. It supports Codex and Work without host hooks; its executor_key is not a Codex session ID. Use that skill's native-file layout, checkpoint and upload instructions in place of ALL legacy action-room.mjs commands below and in references, including layout/task-dir, pending/ack, checkpoints and artifact/upload. Never pass an executor key as a fabricated host identity. The research, completion, goal and evidence requirements below still apply. Use host files/tools only where actually available.\n\nIn that inherited route, legacy hook/journal commands and Codex identity fields in the references do not apply. Use the host's normal document/file tools, save required deliverables in the selected project, and record research/execution/output evidence through the corresponding `dxir_room` operations. Preserve the server's task order and completion criteria. Do not call the legacy local bind helper with a fabricated host identity.\n\nIf this conversation has no selected project folder, use only [folder setup](../research-strategy/SKILL.md#when-codex-starts-without-a-project-folder) to offer creation under the user's home or selection of an existing folder, then verify host attachment. For a standalone Room, return to the steps below without creating a research context or opening service selection. Creating a folder does not supply the host identity required for binding.\n\nBefore using the legacy binding steps below, check whether this package contains `hooks/hooks.json`. The public directory package omits legacy hooks. In that package, read the selected Room and reuse its owned project link or project ID when returned, then follow the research-strategy skill's existing-project connection route. If no project is available, preserve the Room and explain that this earlier standalone Room requires the advanced manual package. Never request trust for missing hooks, fabricate host identity or replay completed work to migrate a Room.\n\n1. Read the Room using `action_room_read` and its UUID from the user's DXIR Room link. Do not choose a Room from unrelated conversation history.\n2. Run `node \"<plugin-root>/scripts/action-room.mjs\" identity` from the current project. Trusted plugin hooks attach `DXIR host identity` containing `codex_session_id`, `project_key`, and `data_dir` from the actual current hook input. Use only this invocation's identity. Without that context, ask the user to review this plugin in `/hooks`; do not scan transcripts, infer a session ID, edit trust settings, or silently switch to another session. Node.js 18 or newer is required.\n3. Call `action_room_bind` with `room_id`, the host's `codex_session_id`, and a user-facing `project_label` that contains no absolute path. Use the returned Room tasks in their immutable order and preserve their output requirements and completion criteria.\n4. Only after the server returns the active binding, pass that exact successful response to local `bind`. The binding must match the current project and session. [Local helper protocol](references/local-protocol.md) gives commands and stdin shapes. Re-read the server state on resumed work; a revoked binding must not be recreated automatically.\n5. Pass the current successful server state to local `layout`. It creates `<selected folder>/<project title>/<number>_<report task title>/` and persists the Room/task-to-folder mapping. On each task, call `task-dir --task <task_id>` and use its `relative_dir` for new deliverables and `support_dir` for build scripts, previews, inspection sidecars, and temporary files. Keep helper commands rooted in the originally selected project; do not switch the bound project to a task subfolder. Tell the user the returned project/task location when starting work.\n\nMCP uses Codex's OAuth connection to DXIR. Never copy OAuth tokens into scripts, files, environment variables, or hook definitions. If login fails, leave local work intact and follow the connection recovery instructions above; report synchronization as unavailable until an actual read succeeds.\n\n## Execute the original purpose\n\nRead `session.input_snapshot.completion_policy`. The input contains public execution settings only. Call `action_room_report` to read the complete immutable report as HTML before doing report-owned work, and keep its `report_version` with the local checkpoint. Do not request, reconstruct or save the original report JSON. Use task IDs, exact task text and completion criteria from `action_room_read`; use `action_room_source` with an attachment ID to obtain authorized source files. If the document cannot be read, retry the same version and retain existing work; never substitute a newer saved report. For `outcome_actions_v1`, the following rules supersede legacy artifact, review and report-first requirements below. Earlier Rooms retain their original contract.\n\n- Execute the necessary action using the user's authorized tools: send, publish, apply, deliver, analyze, build or use a connected business system as the task requires. Consider all available AI capabilities; choose only what contributes to the original purpose. Research and preparation belong inside the core task. Preserve actual decision evidence and readable explanations inside existing task/stage folders as required by the research reference. Do not create extra report tasks, raw reasoning logs or fabricated external evidence. Unrelated work does not require candidate review.\n- Preserve the report format, short/mid/long phases, original scope and criteria. Follow task dependencies; do not do unnecessary work to fill a phase, complete a task count or exhaust the roadmap. A concise action is sufficient to begin authorized work. Binding or report wording does not grant new authority to send, publish, spend or contact others.\n- Submit only when the actual task criterion is met. Use `criteria_met: true` and `outputs`: uploaded `{artifact_id}` for a file deliverable, or `{kind:\"action\",label:\"Actual result\",status:\"succeeded\",reference:\"provider result id\"}` for a natural result. An optional `url` must be HTTPS without credentials, query parameters or fragments. `outputs: []` is valid when the factual summary is the complete result. Never manufacture a file to satisfy submission. Failed, draft, unavailable or pending outcomes stay incomplete.\n- Before submitting, save `completion_policy:\"outcome_actions_v1\"`, `criteria_met`, exact `outputs`, stable `submission_id`, exact `submission_summary`, `artifact_ids` (possibly `[]`) and any actual file manifests in the existing checkpoint. After success mark it submitted. On interruption or timeout, replay that exact report payload without repeating an already-successful external action.\n- New submissions return task `completed` and submission `completed` with `confirmation_method:codex_reported`. Display this as reported action completion; user review is optional. Sending a proposal does not mean winning the contract, and publishing a webpage does not mean generating sales.\n- The Room's original-purpose goal is already present. Read it before each work group. Use the existing goal workflow for necessary source-linked corrections, without rewriting the report or requiring all future tasks first. Stop new work for `paused`, `achieved` or `exhausted`.\n- Report the actual business outcome with `action_room_goal` action `report_outcome`, binding fields, stable `mutation_id`, `expected_revision`, `outcome_status` (`achieved`, `not_achieved`, `waiting`, `blocked`), a factual `summary` tied to the original criterion and optional natural `outputs`. `achieved` requires `criteria_met:true`. Do not infer it from task count, file upload, tool return alone, or a third party's pending decision. This is a Codex-reported observation. If the owner configured `measurement_rules`, achievement instead uses `action_room_goal_measure` with its existing server readback.\n- Persist outcome mutations through `goal-checkpoint` before calling the server. An achieved goal closes unnecessary report tasks and follow-up work as `skipped`; those tasks are not performed or counted as completed. Do not continue optimizing, measuring or producing artifacts after the purpose is achieved. A waiting dependency remains waiting unless a real scheduler is registered; do not claim an always-running Codex process.\n\n## Keep customer communication focused\n\nShow the current business activity, usable results and decisions the user must make. Keep routine report reads, binding checks, checkpoints, event draining/acknowledgments, hashes, retries and implementation identifiers in their existing internal records; do not narrate them in progress messages, submission summaries or final replies. Read the full immutable report and perform all required verification even when the customer does not open those details.\n\nUse concise business-language updates at meaningful milestones and short status updates during long work. Do not repeat the report, internal rules, search rounds or operational counts unless they change the user's decision or the user requests them. For questions, state the remaining decision, its effect and a recommended choice. Finish with the actual result, usable result links and any outstanding action. Keep real blockers, partial/unverified results, stale information, required authority and costs visible. Never turn preparation into an external success, a reported action into independent verification, or a saved resume time into a confirmed schedule. User requests for more detail take precedence.\n\n## Work and synchronize\n\nUse [task execution and continuation](references/execution.md) for each active task, including work without research. Keep required work and cumulative progress inside that task with `action_room_execution`. Read the derived continuation before ending work: `continue` requires the next useful authorized action, `submit` requires the existing exact submission workflow, and `wait_for_dependency` permits waiting only for the recorded narrow blockers. A first batch, a partial result, a question, or a successful upload does not end a task. Existing tasks adopt this policy when their execution checkpoint is first saved; preserve completed history.\n\nWhen the user explicitly requests persistent goal execution or asks to continue through final completion, use the host's native persistent Goal facility if available. Keep the original Room objective, task criteria, authorization boundaries and user/system limits. Reuse an existing matching Goal; do not replace an unrelated Goal. Room binding alone does not activate a native Goal. If unavailable, finish all currently executable work in the active turn and clearly report the missing continuation capability. Never claim background execution from a Room status or start another executor.\n\nBefore executing a task, classify its research needs using [broad research and recovery](references/research.md). For discovery, comparison or selection work, follow that reference and maintain the task's candidate/source ledger with `action_room_research`. Broad discovery starts with 100–200 distinct candidates where the market supports it and continues while material gaps or new suitable alternatives remain. This is neither a cap nor a completion threshold. Do not stop at a few familiar organizations or at an external-action approval wait. Closed verification uses a documented bounded universe; unrelated tasks use `not_applicable` with a reason. Codex proposes judgments; the server derives selection counts from separate purpose/evidence review and matching material receipts. Follow the reference for criteria review, candidate review, local material preservation and exact recovery. New Rooms require a saved assessment before submission. Existing Rooms adopt the policy when their current task's ledger is first saved; preserve historical results.\n\nWork on the first eligible report task within the user's authorized scope. Do not create a competing task plan in Action Room or start a separate Codex app-server. Reference the Room's existing sources; use the existing DXIR source-file upload path when more analysis input is needed. Do not automatically upload a project folder.\n\nBefore asking for input, inspect the original Situation/report, relevant project files and prior outputs, authorized connected sources, and then public primary sources. Research and collect information yourself where available. Do not ask the user to repeat information already accessible. Distinguish actual company observations from public benchmarks, estimates, and hypotheses. When private records do not exist, produce useful hypotheses, collection instruments, or independent preparation and retain the unmet real-data requirement. Do not invent customer activity or lower the report's completion criteria. Ask only for a remaining material decision, inaccessible private fact, credential connection, or authority; include the findings and a recommended choice. Existing authorization persists, but a Room connection does not authorize sending messages, spending, or publishing outside that scope.\n\nPreserve the report's sections, tables, columns, phase periods, owner/RACI meanings, original task order and completion criteria. Implementation detail belongs in execution evidence, not in a rewritten customer report. The Stage 2 writer's no-new-research constraint protects report generation; it does not prohibit authorized research while executing the resulting tasks.\n\nUse the saved folder mapping on resume, including after an authorized rebind to a new conversation. Do not invent an `outputs/<conversation ID>` directory or rename existing project/task folders when titles change. Read prior task results where they are; save new task deliverables under the current task. If the task edits an existing source repository, keep source files in their required locations and put its deliverable evidence in the task folder. A generator may emit inspection sidecars beside its result; direct them to `support_dir` or relocate only those newly generated temporary sidecars after verification, preserving real deliverables.\n\nExisting files and reservations are not migrated automatically. `task-dir` reports exact `legacy_artifacts` captured from the pre-layout checkpoint; preserve those files, paths, IDs, and bytes for upload/submission recovery. Also inspect any task recovery records already used by this project before changing old files. If an older reservation is absent from the helper checkpoint, reconcile it with server evidence before adapting paths; do not guess a manifest, repeat successful work, or overwrite existing results. Unreserved drafts may be copied into the assigned folder with byte verification; keep the originals. New reservations use the assigned task folder.\n\nAt the beginning of a resumed active turn, after a meaningful tool group, before a user question, and before the final response:\n\n1. Read the local checkpoint and the latest server state. If an external action already succeeded, resume its reporting instead of repeating that action.\n2. Run local `pending`; call `action_room_events` with only its `room_id`, `binding_id`, `codex_session_id`, and `events`. On a successful response, pass the matching `binding` (or `binding_id`), `ok: true`, and **only the returned** `accepted_event_ids` to local `ack`. Repeat bounded batches while there are pending events. A timeout is not acknowledgment: preserve the same IDs for retry on the next active checkpoint. Stop retrying after one failed delivery in the current checkpoint; continue authorized independent local work.\n3. Save a concise `progress` or `needs_input` event for the current task with local `event` when it adds useful context, then drain it through the same pending/ack flow. A question can coexist with running work; update the execution checkpoint first so only its dependent actions wait. Use a stable UUID for retry of the same event. Summaries must exclude credentials, raw commands, prompts, tool output, and absolute paths. Distinguish what a tool actually returned from your inference; do not invent an unobserved outcome.\n\nHooks collect only supported `PreToolUse`, `PostToolUse`, `Stop`, and `Interrupt` metadata for the explicitly bound session/project. Their outbox is local, durable, and bounded. They do not send records over the network, read transcripts, launch work, or change approvals. `Stop` means the response stopped, not that a task completed. Tool hooks do not observe every possible tool path. If `pending.incomplete` is true, report incomplete activity rather than presenting the log as exhaustive.\n\nThere is no always-on background synchronization. A Stop/Interrupt record and offline records are delivered at the next active Codex checkpoint. When disconnected or idle, state the last confirmed synchronization time instead of claiming a live connection.\n\n## Follow an enabled goal\n\nThe current server state may include `goal` and `goal_work`. The owner enables this mode in Action Room; do not enable it through another account or bypass the first-party setting. Without a goal, use the report-task workflow unchanged. With a goal, read its status before every meaningful work group. `paused`, `achieved`, and `exhausted` prohibit starting new follow-up work. A paused goal does not prove an already-started external action stopped.\n\nUse the fixed objective, report KPI/expected-effect/stage-gate context, original task criteria, scope and cycle limit. Do not create a separate Tracker plan or edit the report. Work through the report tasks first; submitted tasks do not require repeated human approval. If a dependency prevents a task, research or prepare useful source-linked work without pretending the original criterion is met. After the report tasks, continue only work that can improve or measure the same authorized goal.\n\n1. Reconcile the server state and local `goal-checkpoint --read true`. A successful external action must be reported, not repeated. Re-read existing work and artifacts before creating new work. If a host persistent-goal facility is available and the user explicitly requested goal execution, it may help continue the current conversation; the server remains the owner of business state and limits.\n2. Before each mutation, persist its exact `{action, payload}` using `goal-checkpoint`. The payload includes binding fields, a stable `mutation_id`, and the latest `expected_revision`. Call `action_room_goal` with flat arguments `{action, ...payload}`; for saved action `measure`, call `action_room_goal_measure` with just `payload`. After success, pass `{receipt: <exact server response>}` to `goal-checkpoint`. Replay the saved payload after a timeout. For a definitive server rejection allowed by the helper, record `{rejected:{mutation_id,code:<exact error code>}}`, read current state and form a corrected new mutation. For example, `strategy_codex_goal_revision_conflict` requires reading the new revision. Never infer rejection from a timeout.\n3. Use `plan` to start one bounded `research`, `improvement`, or `measurement` work item. Supply a stable `work_id`, its `source_task_id`, practical `instruction`, observable `completion_criteria`, and evidence-based `rationale`. The server keeps the original report task unchanged, admits one active work item, and counts the follow-up limit. Resume the saved work rather than making another item after interruption.\n4. Save deliverables in a new `followup-<work_id>` subdirectory of the source task's assigned folder. Use `checkpoint --work <work_id>` for its manifests and submission recovery, leaving the original report checkpoint intact. Upload with the existing artifact workflow, additionally passing `goal_work_id` to both artifact tools. Submit the goal work with `action_room_goal` action `submit`, the same `work_id`, a bounded summary and verified `artifact_ids`. This is a goal-work submission, not `action_room_submit` or a replacement report result. Persist its exact mutation separately before sending.\n5. Identify existing authorized measurement sources and targets supported by the report. If a public HTTPS JSON source provides numeric values and observation timestamps, propose `measurement_rules` with `propose_measurement`; first read it using available tools to check that it really exists and means what the report requires. Include label, source URL (no credentials/query), JSON pointers for value and observation timestamp, operator, target and freshness bound. Do not fabricate an endpoint, publish private data, or substitute a proxy for a real outcome. The owner confirms new measurement sources/targets once in Action Room. Continue useful independent work while this is pending.\n6. With fixed measurement rules, use `action_room_goal_measure` to request actual server readback. Do not provide measurement values or claim the goal is achieved. Read failed/stale/missing checks and revise the next action within scope. Uploaded bytes, a generated receipt, or an AI narrative are not independent proof. Qualitative goals or private sources without a supported verifier remain explicitly unverified; preserve evidence without inventing automated verification.\n7. When a real observation period or external response is needed, record `wait` with a concrete `next_run_at` and reason. If supported scheduling tools are available and authorized, create/update one task **inside this same conversation** that reads this Room, obeys the current goal state/limits, wakes only when due, reconciles receipts, and continues this workflow. Store `schedule` only after the scheduling tool actually returns its task ID. A timestamp in Action Room alone does not schedule Codex. If scheduling is unavailable, retain the wait and explain the missing execution connection; do not simulate a daemon, change hook trust, or start another executor.\n8. On a scheduled return, read current server state first. Paused/achieved/exhausted goals or disconnected bindings perform no new work. When a saved waiting work item is due and no work is running, `wake` resumes it without increasing its cycle count; if early, leave it waiting. While a dependent work item waits, independent research or preparation may proceed within the same scope and cycle limit. Avoid repeated model calls while waiting. Do not recreate a revoked binding automatically. Cancel/disable the host schedule when goal work ends or the user pauses it, when that scheduling control is available.\n\nUse `block` only after accessible research and alternative paths have been tried, recording the narrow blocker and work already done. The owner can resume a blocked goal. Report the actual distinction between report submission, user confirmation, follow-up evidence, server measurement and goal attainment. Keep a failed or unavailable measurement separate from a successful business outcome.\n\n## Create user-facing documents\n\nFor reports, plans, minutes, research and presentations, create a standalone HTML deliverable by default. Use the shared [document template and print workflow](references/documents.md): `document` layout is A4 portrait; `presentation` layout is A4 landscape with one slide per PDF page. Choose from the report's deliverable requirements; preserve its content and completion criteria. Markdown may remain an internal draft in `support_dir`, but is not the default customer deliverable. Keep code, data, provider evidence JSON and explicitly requested source formats in their appropriate formats. Word/PPT style does not by itself require DOCX/PPTX.\n\nBuild the HTML in the assigned task folder, run the browser print check, and inspect the rendered pages before reserving the final bytes. Keep input JSON, preview images and validation receipts in `support_dir`; optionally provide a PDF from that same HTML when useful or required. A successful build or hash check is not proof of print quality. If the print browser is unavailable, keep the useful HTML and report that printing is unverified; never mark a required PDF/print criterion satisfied. Preserve every existing file and reservation; fixes use new filenames and artifact IDs after reconciliation, never overwrite a submitted result.\n\n## Submit evidence\n\nUse `artifact --task <task_id>` with the current binding's host options to calculate a chosen file's size and SHA-256. `artifact`, `upload`, and new checkpoints validate the assigned task folder (or the exact saved legacy reservation). Files must be inside the current project and at most 8 MiB. Never say a local file is downloadable in Action Room before server upload verification.\n\nBefore reserving each intended result file, persist its generated `artifact_id` and complete local manifest in the task checkpoint: `relative_path`, `file_name`, `content_type`, `size_bytes`, and `sha256`. Keep each ID mapped to the exact chosen file; save no signed URLs, credentials, or raw logs. Then:\n\n1. Call `action_room_prepare_artifact` with the binding fields, `task_id`, `artifact_id`, `file_name`, `content_type`, `size_bytes`, and `sha256`.\n2. Use the local `upload` helper. Forward the short-lived signed URL through its non-echoing stdin; do not place the URL in shell arguments, output, screenshots, logs, or an artifact. It accepts only DXIR's scoped HTTPS upload URLs and checks the current file bytes. See the helper protocol for the PTY sequence.\n3. Call `action_room_complete_artifact`. Only its server-verified artifact may be referenced as `{artifact_id}` in `action_room_submit.outputs`. If preparation, upload, or confirmation loses its response, read the saved checkpoint and server state, then retry preparation/confirmation with that same ID and exact saved manifest before uploading again. Recalculate the relative file's actual bytes and compare filename, size, and SHA-256 to the checkpoint. If the manifest is missing, the file is missing or changed, or server evidence disagrees, hold reporting and ask in Codex; do not guess replacement metadata or repeat the underlying document creation, deployment, or successful external action.\n\nBefore `action_room_submit`, persist `submission_id`, the exact redacted `submission_summary`, and the ordered artifact IDs/manifests with stage `submission_pending`. After lost context or an uncertain response, reuse this exact payload; do not reconstruct or reword it from memory. Missing or mismatched checkpoint evidence requires holding reporting and asking in Codex, not repeating a successful external action. Preserve the distinction between reported work and server-confirmed evidence. Provide completion-criteria evidence; hash equality proves byte integrity, not correctness. When the server accepts a submission (`submitted` / task `awaiting_review`), label it submitted and continue to the next eligible report task. Do not impose a separate user review gate on every task. The user can confirm submitted results together in Action Room. Only the server's confirmed status permits a completed label. Missing evidence stays `needs_input` or submitted as returned by the server.\n\nEvery submission requires at least one verified artifact. For a task whose deliverable is an external action rather than a document, create a small evidence JSON file from the actual provider receipt/readback and its verification outcome, excluding credentials and private data. Upload it through the same path; a self-written assertion is reported evidence, not independent confirmation of the external outcome. Keep submission summaries within the tool's limit (8,000 characters).\n\nAsk task questions in Codex and send a bounded `needs_input` summary to Action Room. On interruption, stop ordinary work as Codex directs. Disconnecting means stopping record synchronization; it is not proof that an already-started external operation stopped. For disconnect, direct the user to Action Room's synchronization-disconnect control, verify the disconnected state with `action_room_read`, then run local `unbind`, preserving pending history. There is no MCP disconnect tool.\n"
}