restore-attended-chat-user-authority

Restore human-directed authority for attended chat agents

Metadata

Statusdone
Assignedagent-937
Modelpi:openai-codex:gpt-5.6-sol
Created2026-07-30T21:30:50.681188751+00:00
Started2026-07-30T21:33:36.973246686+00:00
Completed2026-07-30T22:31:32.281375036+00:00
Tagschat, prompting, policy, regression
Tokens32251091 in / 52019 out

Description

The bundled universal role contract in src/text/agent_guide.md intentionally imposes an obsolete thin-task-creator policy on attended chats: it says chat agents must only create/publish WG tasks, NEVER read/search/edit source or run commands/tests, and may read only WG state. A production Pi chat obeyed that prompt and refused a human request to read repository files. The product decision is now explicit: an attended chat is the human's interactive repository operator. It should carry out the human's explicit request with the normal handler tool surface—read/search/explain/edit/run/test or delegate to WG workers—rather than forcing every action through wg add. Delegation remains available and often useful but is not mandatory.

Replace the attended-chat contract everywhere it is injected or duplicated (universal guide, Pi/Claude/Codex addenda/first-turn prompts, generated docs/examples, prompt snapshots). State that explicit human direction authorizes ordinary repository inspection and mutation within actual OS/project/tool scope. Require confirmation for genuinely irreversible/external side effects and accurately report a real missing tool/policy denial; never fabricate a blanket “contract does not allow reading files.” Preserve the distinct dispatcher, worker completion/finalization, bounded evaluator, and deep-FLIP containment contracts exactly. Do not grant unattended agents chat authority or weaken isolation.

Audit chat task exec_mode/context/cwd and handler argv after the preceding TUI transport fix so Pi receives its normal built-in tools plus WG tools. A user request to read a known repository file must result in a real read and answer; a user request to make a harmless edit/test may do so; a request to create/delegate a WG task still works. Mere discussion must not trigger unsolicited mutation. Update migration/release notes because this intentionally changes long-standing behavior and existing tests currently assert the old STOP/NEVER prompt.

Validation

  • Prompt/unit snapshots for Pi, native Codex, and Claude attended chats contain the human-directed operator contract and exclude the old blanket source/tool prohibitions.
  • Worker, bounded evaluator, and deep-FLIP prompt/capability tests remain unchanged and fail closed.
  • Credential-free behavioral chat smoke asks fake/model chat to read a known file and proves the tool request/path/result; separately exercise a harmless user-directed edit/command and WG task delegation.
  • Assert no unsolicited write occurs for a read-only/conversational request and irreversible/external actions still require explicit confirmation.
  • Run relevant chat prompt/tool smokes, focused Rust tests, cargo fmt --check, and cargo clippy.

Depends on

Required by

Messages 6 messages (6 unread)

  1. #1user2026-07-30T21:34:32.526295392+00:00read
    Exact live production quote from the affected Pi chat, after being asked to read repository files: “The binding project instruction says to run and follow wg agent-guide. That guide explicitly states: A chat agent NEVER reads source files.” Treat this as the canonical regression assertion. The current session is correctly prioritizing the old bundled guide, so user wording cannot repair it. Remove the prohibition and duplicates, test prompt hierarchy, and document that existing sessions must be restarted after accepted binary installation to receive the new contract.
  2. #2user2026-07-30T21:36:45.086556062+00:00read
    Reporter-approved target contract should be SHORT and positive, not another long rule lattice. Core wording: “You are the human’s attended repository assistant. Follow the human’s request using your normal tools. Use WorksGood/`wg` to create, delegate, publish, inspect, and monitor tracked work when task management is requested or useful. Do not force every request into a task, and do not refuse repository inspection or implementation merely because you are a chat agent.” Add only a very brief explanation that WorksGood is the project task graph/worker coordinator and `wg` is its expert CLI. Preserve ordinary real safety/OS/project constraints, but avoid exhaustive CAN/CANNOT lists and duplicated STOP sections. Keep detailed worker/evaluator contracts role-scoped elsewhere. Update tests to pin this concise positive contract and absence of the old prohibitions.
  3. #3user2026-07-30T21:37:22.145655079+00:00read
    Final product rule from reporter: at the WorksGood layer, attended chat has NO role-based operation denylist. If the human explicitly asks, that request authorizes any operation exposed by the normal tool surface: read, search, write, edit, execute, test, inspect, dispatch, or graph/service management. Do not add replacement allowlists or paternalistic chat-only restrictions. Only actual tool/OS/platform constraints remain; if blocked, name that real constraint. Treat an explicit unambiguous request as authorization; clarify only ambiguity, not the mere fact that an operation is powerful.
  4. #4restore-attended-chat-user-authority2026-07-30T21:47:14.217502624+00:00read
    Acknowledged message #1 — I am pinning the exact production refusal quote/prohibition as absent, testing prompt precedence, and documenting that installed-binary acceptance must be followed by chat restart.
  5. #5restore-attended-chat-user-authority2026-07-30T21:47:14.346568751+00:00read
    Acknowledged message #2 — I will shorten the attended contract to the reporter-approved positive wording, remove duplicated STOP/rule lattices, and keep detailed unattended role contracts separate.
  6. #6restore-attended-chat-user-authority2026-07-30T21:47:14.479757283+00:00read
    Acknowledged message #3 — I will remove chat-only confirmation/operation restrictions: explicit unambiguous human requests authorize the full normal tool surface; only actual tool/OS/platform/project constraints remain, with clarification only for ambiguity.

Log