Document coding agent progress messages and delivery recovery

AGENTS.md

@@ -4,7 +4,7 @@
 - **Lifecycle:** Active
 - **Authority:** Governing instructions for work in this repository, subordinate
   to current explicit user direction and higher-level safety rules
-- **Last reviewed:** 4 September 2026
+- **Last reviewed:** 11 September 2026
 - **Review trigger:** A material change to Von's product focus, authority model,
   security posture, or acceptance doctrine
 
@@ -518,6 +518,17 @@ validation and deployment evidence, and any material limitation. This is
 standing authorisation for those completion messages. Verify delivery through
 canonical message read-back before reporting that the summary was sent.
 
+For work requested by Michael, also send major blockers and significant
+milestones to him in Von, alongside updates in the normal coding interface.
+Michael explicitly authorises these reports; do not ask again for each message.
+Keep reports concise and useful, distinguish partial progress from completion,
+and include any action needed from him. Routine tool steps do not need separate
+messages. Use the agent's own registered identity and the
+[coding-agent messaging route](docs/engineering/codex_dgx_worker.md#interactive-coding-agent-messages),
+with host-specific configuration in the operator's personal `AGENTS.md`.
+If delivery fails, report that in the normal interface, retain the pending
+message for a safe retry and continue independent authorised work.
+
 Update current guidance when a durable invariant or routing rule changes. Put
 incident-specific commands, identities, paths, and outputs in dated incident
 records or version control history, not in this constitution. Prefer replacing

docs/design_index.md

@@ -82,6 +82,7 @@ live.
 | Substantial, architecture-sensitive, or older-doc-dependent work | This index, then the applicable sections below |
 | Task product selection and continuing a responsibility from Tasks | [Task responsibility continuation](engineering/task_responsibility_continuation.md) |
 | Subscription-backed coding task pickup on the DGX | [Codex DGX worker pilot](engineering/codex_dgx_worker.md) |
+| Coding-agent progress and completion messages in Von | [Interactive coding-agent messages](engineering/codex_dgx_worker.md#interactive-coding-agent-messages); operator-specific delivery configuration in personal `AGENTS.md` |
 | Enduring role competence, organisational continuity, active acquisition, learned reuse or transfer | [Role-learning convergence](engineering/role_learning_convergence.md), with the [staged development rehearsal](engineering/role_convergence_rehearsal.md); live Jira owns delivery status and the next integrating increment |
 | Material security exposure: authentication/authorisation, private or cross-namespace data, secrets, untrusted content with tool authority, effects outside ordinary bounded and recoverable delegation, deployment, or administrator surfaces | [Security considerations](engineering/security_considerations.md) |
 | Substantial agent-behaviour implementation | Relevant sections of the [modern agentic AI primer](engineering/intro_to_modern_agentic_ai_for_coding_agents.md) |

docs/engineering/codex_dgx_worker.md

@@ -41,6 +41,45 @@ the operator-enabled deployment command described below. The chosen
 GitHub account and current authentication status belong in the Jira decision
 surface, not in the task's text.
 
+## Interactive coding-agent messages
+
+The reporting requirement lives in [AGENTS.md](../../AGENTS.md#9-completion-and-maintenance).
+Interactive Codex VS Code uses `#V#codex_vscode` (Codex VS Code); the DGX worker
+uses `#V#codex_dgx` (Codex DGX). Keep these identities distinct. Michael's
+recipient identity is `#V#michael_witbrock`; the existing SAIL organisation is
+`#V#university_of_auckland_strong_ai_lab`.
+
+Use an available canonical Von message tool or the existing trusted operator
+helper for the intended Von instance. Absence of an exposed MCP message tool
+does not establish that messaging is unavailable. A local development or
+migration database can lack an identity that exists in the user's running Von;
+check the configured delivery route before declaring the identity missing or
+asking for account setup. Do not recreate identities or grant memberships to
+repair a connection to the wrong instance.
+
+The verified interactive helper accepts an operator-owned JSON file containing
+`key`, `subject`, `content` and an optional native `task_id`. It binds the sender,
+recipient and organisation itself, checks membership, calls
+`message_service.create_message_idempotently`, and reads the result back as the
+recipient. Use a unique key for each milestone or report; preserve both key and
+exact payload when retrying the same delivery. A changed message needs a new
+key. Include a task link when available; omit `task_id` if that native task has
+not been verified in the destination instance.
+
+Keep host aliases, installed helper/environment paths, credentials and delivery
+receipts in operator-owned configuration outside Git. The operator's personal
+`AGENTS.md` records the concrete route and recovery instructions. Invoke the
+helper with its PDM-managed Python environment. Reporting alone must not start
+the coding worker, a model request or unrelated event workflows. Keep normal
+coding-interface updates as well as Von messages; the delivery receipt proves
+message persistence, not completion of the work being reported.
+
+For an explicitly requested recurring report, record the actual scheduler,
+cadence, completion trigger, retry/idempotency state and host-availability
+dependency. Verify an immediate delivery and the installed schedule separately.
+Do not treat an imported task, a passive assignment or an enabled schedule as
+proof of execution, or stop reports at an intermediate migration milestone.
+
 ## Controller and authority
 
 [`scripts/codex_von_worker.py`](../../scripts/codex_von_worker.py) uses the