> **Historical capability inventory, not the dogfooding checklist.** The current issue body and [scope decisions](https://github.com/githubnext/ace2/issues/5#issuecomment-5986572832) define MVP and core/QOL. Broader scenarios below remain evidence for their separate issues.

## Review evidence and acceptance criteria

Moved from the issue body to keep the active work checklist concise. These notes preserve the reviewed scope, evidence, acceptance scenarios, and implementation constraints; the issue body owns priority and completion status.

Assessment: October 4, 2026, America/Toronto, against source [`ce1bd9b`](https://github.com/githubnext/ace2/commit/ce1bd9bde77955b15521a5cbeee1236bdc14fa13). Issue bodies were refreshed during the review. In particular, this uses **#8 updated October 5 at 01:11:20 UTC**, with its six native-computer-use slices and explicit browser/audio boundaries. Session evidence stops at the start of this audit; source status is not a claim about every installed build or unmerged lane.

## What the review says

**The original #5 checklist would not cover all the development workflows in the recent sessions. Even completing that list and #6, with the revised #8, would not establish 100% dogfooding without the additional scopes and acceptance criteria below.** The main omissions are browser automation and debugging, reading generated images, and the lifecycle of external harnesses and coordinated background work. Several issues describe a surface without specifying the behavior needed to replace the tools used in those sessions.

Ace can already do substantial development. Native agents can read, edit, run commands, create lanes, invoke subagents, and use Git and GitHub through the shell. Ace has local terminals and diffs. [PR #1](https://github.com/githubnext/ace2/pull/1) and [PR #2](https://github.com/githubnext/ace2/pull/2) report work completed entirely in Ace. Later PRs used Ace terminals for checks, Git, builds, and release operations while Codex supplied orchestration, edits, and computer use. The blocker is not a missing compiler or release system.

A credible way to establish the goal is to reproduce the actual development loop in Ace, including its browser and desktop verification steps, then require several complete deliveries without a separate external coding harness, editor, or terminal. Porting every convenience feature from old Ace is a different milestone. It should not substitute for proving this loop.

The most important findings are:

1. Make browser interaction and debugging explicit; neither native desktop control [#8] nor opening a dev server [#16] promises browser DOM/session integration and console/network diagnostics. Updated #8 explicitly separates that capability. 2. Define [#9] as a working external-harness lifecycle, if retaining Codex and Claude Code is required. Importing a transcript alone does not move the work into Ace. 3. Add an agent tool for reading local image artifacts. The installed native file reader explicitly rejects images, even though uploaded images and desktop captures work. 4. Promote child-chat access [#19], questions [#21], steering [#24], and completion attention [#12] into the required development loop. Check background work and follow-up behavior separately from merely showing more chats. 5. Treat terminal correctness [#48], window/layout isolation [#45], and existing-data recovery as acceptance gates. They affect whether it is safe to stay in Ace all day. 6. Prove a real second-machine delivery and upgrade through [#10] and [#39]. [#49] is a distinct live-handoff requirement; remote viewing is not evidence that handoff works.

<details> <summary>Detailed scope behind the checklist</summary>

### Detailed scope behind the checklist

1. **Complete native computer use — #8.** Finish its already-defined action, input, app/window/dialog, visual-targeting, and shared-activity slices. Inspection is shipped. Keep the updated issue's replay, cancellation, coordination, execution-host and OS-permission requirements. 2. **Browser interaction and debugging — new scope.** Explicit browser/tab identity, DOM/accessibility inspection, screenshots, actions, console/network diagnostics, uploads, viewport/mobile emulation, and reconnect. Related: #8's explicit browser boundary and #16. 3. **Read generated images from the execution host — new scope.** Let the native agent inspect a saved screenshot/render by path and retain bounded visual evidence. Incoming uploads and desktop capture are different paths. Related: #26. 4. **Continue the required external harnesses inside Ace — #9, expanded acceptance.** Cover Codex and Claude Code, existing work and fresh runs, required tools/skills, questions, output, steering, child work, lane ownership, and restart. A transcript copy does not meet this promise; native computer use remains independent of #9. 5. **Control and inspect ongoing chats — #19, #21, #24.** Open/continue child chats; ask durable questions; show/edit/delete pending input and make steering behavior visible. Basic busy-input steering already exists. 6. **Interactive subagent supervision — new scope.** Start independent work, continue the parent, inspect partial findings, send follow-ups, interrupt chosen work, collect results, and preserve ownership across restart. Parallel one-shot subagents already exist; #19 alone is not the full lifecycle. 7. **Background/interactive jobs and live tool progress — new scope.** Supported job identity, input, progress, readiness, completion, logs, stop and reconnect for builds/dev servers/watchdogs. Surface pi's live tool progress in Ace. Long shell commands and completed diagnostics already work. Related: #12, #16, #29. 8. **Trust terminal and window state — #48, #45, #44.** Exact first command after terminal restoration; independent acknowledged window/layout state; collapsed controls absent from accessibility/focus navigation. These are observed failures, not speculative polish. 9. **Develop, upgrade, and recover Ace from Ace — acceptance scope plus #39.** Real checks, CI repair, signed canary delivery, second-Mac upgrade, existing-channel continuation, recoverable development failures, and no lost or blindly replayed work. Existing backup/update mechanisms are the foundation. 10. **Complete real team development — #10, #11, #15.** Two machines/people, coherent project identity, peer terminals and actual remote work. Also verify agent channel discovery/messaging across hosts; human routing does not establish that agent capability. 11. **Move active work off the current machine — #49.** Preserve history, children, lanes and dirty/untracked files, ensure one executor, and make destination readiness and restarted native/browser state explicit. This is distinct from viewing another host. 12. **Bring attention back to waiting or finished work — #12.** Completion/failure attention, with question/waiting states coordinated with #21. Do not require watching the active channel continuously. 13. **Human file, branch, and review workflow — #22, #28, #20.** Browse/edit files, take over existing branch/PR work, inspect Git state and perform review/delivery from Ace. Agent edits, terminal editors, Git and `gh` are already usable routes. 14. **Required instructions, skills, integrations, and attachments — #27, #26 plus explicit tool scope.** Preserve the actual lane's instructions and run the required skill/tool, including linked resources. A picker does not provide global/plugin/MCP capability. Accept logs/docs and retain usable artifacts. Research can use a supported docs tool or shell route. 15. **Open the correct lane preview — #16.** Associate the dev server and URL with the lane. This supports browser work but is not the browser automation backend or a full process manager. 16. **First-class CI and GitHub operations — #29, #30.** Checks/logs/dispatch/rerun/cancel and issue/PR/review actions. Existing `gh` and release CLI use inside Ace counts already. 17. **Agent-addressable tabs and keyboard navigation — #43, #31.** Selected-window discovery/rename and channel/tab/action switching. #43 has unmerged PR #46 at the reviewed baseline; preserve the separate #45 persistence contract. 18. **Complete hosted-channel use — #13.** App creation, authenticated browser access, and messaging other channels. Core hosted execution already exists; do not describe it as absent. 19. **Shared project activity — #17, #35, #14.** Lobbies, chat presence/typing, and prompt directory updates. Existing polling is functional but can delay discovery. 20. **Conversation editing and branching — #25, #33.** Message operations and channel forks with explicit durable/lane/side-effect semantics. These do not replace import or crash recovery. 21. **Real-phone qualification — #18.** Actual device use, terminal controls, diff layout, networking and notifications. Browser emulation is not proof on a phone. 22. **Resume and navigation context — #36, #34, #32.** Briefing/team pulse, channel info, and pinning. The dashboard already has a Pick back up list with summaries; Channel info already opens a summary/details sidebar. Clarify the remaining scope. 23. **Additional input and attention — #38, #37.** Dictation, sounds and window glow. The reviewed sessions do not establish these as blockers for the core development loop.

**Already implemented, reconcile the tracker:** #23 names and rolling summaries shipped in `f1446bf`, including existing-data validation. It remains open; do not schedule another implementation solely from its checkbox state.

</details>

## What counts as 100%

For the sampled work, the participant must be able to start from an issue, resume existing work, research, implement, coordinate agents, inspect files and diffs, exercise the app, fix failures, review, create and update a PR, and build and verify a release from Ace.

GitHub, CI, browsers, macOS dialogs, providers, and external command-line tools can still be used. The requirement is that Ace owns the development conversation and gives the participant and agent supported access to the needed tools and results. Running `gh`, `git`, `wrangler`, `bun`, or a repository validation script from an Ace terminal or agent shell counts. Their absence as dedicated buttons is not a hard capability gap.

Opening Codex in a separate app to reason about the code, editing in another editor because Ace cannot support the workflow, or using an external agent's browser tools to finish verification is an escape from Ace. Running an external harness in an Ace terminal can be a useful bridge, but it does not prove integrated channel history, steering, subagent ownership, usage, or recovery. Decide which level [#9] promises and test that level explicitly.

Before claiming 100%, require:

- Each person doing Ace development completes ordinary work in Ace; one successful channel is insufficient evidence for the whole team. - At least one native-harness delivery and, if external harnesses remain part of the team's intended workflow, an existing Codex and Claude Code continuation each complete inside Ace. - A UI change is verified through browser and native desktop tools from its channel. Shell checks alone do not establish UI correctness. - A review/fix cycle, a failing CI recovery, and a signed canary delivery finish inside Ace. - An existing channel survives the release and resumes real work. A second Mac participates. - The people doing Ace development complete the acceptance workflows without a required separate coding-harness/editor/terminal escape. Record escapes in the relevant issue and each PR's **Built in Ace** section; do not reclassify an escape as success because most commands ran inside Ace.

These are completion criteria, not claims that the audit performed them. Human-only OS consent, login, or device-unlock steps are legitimate handoffs. Keep the pending task and continuation visible in the channel; they are not evidence that Ace needs to bypass the operating system.

## Evidence and limits

The review combines local Codex and Claude Code histories from `../ace` and `ace2`, current source and installed pi tools, all children of [#5] and [#6], related distribution issues, and the recent PRs' **Built in Ace** records. Session paths are imperfect repository labels: several runs started in old Ace and then built Ace2. The evidence inventory below identifies the work rather than assuming that a session's initial directory is its only target.

The histories show what was requested and which tools were called. Tool use alone does not prove that Ace cannot perform the same task. Capability claims below distinguish source evidence, observed escapes, practical shell routes, and behavior still needing validation. This was a history and implementation audit, not a new full runtime certification. Raw transcripts, images, credentials, and unrelated personal material are not included.

### Sessions reviewed

**Codex:** all six recent top-level sessions in the two checkout paths, three per checkout, starting September 29–October 4. Inventoried 44 related child-session files; reviewed child coordination and returned results in the root histories. Copied parent context was not counted as new independent sessions. Excluded this audit, its children, and an old March session. **Claude Code:** all 11 parent histories in the two project-history directories, plus nine available child histories, September 30–October 4. Six children invoked through a Workflow were visible in its parent call but had no separate history files in those directories. No claim is made to have audited other teammates' machines or every historical Ace checkout.

Codex root records contain **1,082 computer-use calls, 45 subagent spawns, 240 follow-up assignments, 452 agent messages, 73 compactions, and 24 question-tool calls**. The Claude sample contains **2,011 deduplicated tool events**, including 1,692 Bash and **222 Chrome DevTools events**: 44 screenshots, 37 DOM/accessibility snapshots, 39 clicks, 30 JavaScript evaluations, plus uploads, console/network inspection, viewport changes, mobile emulation, and drag.

These are evidence counts, not estimates of effort, time spent, successful outcomes, or relative productivity. Codex counts use root response records rather than duplicated event/compaction histories; shell/web occurrences inside orchestration scripts are not treated as separate successful outcomes. Claude counts deduplicate tool-use IDs within each file. The two counting methods are not directly comparable.

| Evidence | Session ID | Historical date / launch checkout | Work actually reviewed | | --- | --- | --- | --- | | C1 | `01a0effd-95ef-7093-8c38-093ef6d478f4` | Sep 29, `../ace` | Local-first reconstruction, cells, native UI, team setup, two-machine checks, release and real-provider evaluation. Extensive agent follow-up and 44 compactions. | | C2 | `01a0f2f9-ced6-7b60-90bb-66102ffe03f1` | Sep 30, `../ace` | Infrastructure/storage research and deployed-state inspection through web and shell tools. | | C3 | `01a0f880-5dff-7632-bb63-b7ea235ea93c` | Oct 1, `../ace` | Harness/model continuity investigation, lane-ownership repair, durable architecture research, and an interactive architecture map from visual references. | | C4 | `01a0fdc5-715b-7a50-9bec-41cb2a2d2dc7` | Oct 2, `ace2` | Packaged desktop/helper/settings, project-first flow, native pickers, updater/signing, backups, usage, providerless human chat, and real-model update continuation. | | C5 | `01a103f2-c537-7273-875a-54005552f0b6` | Oct 3, `ace2` | Issues/PRs pages, real rendered diff debugging in Safari, helper PATH, updates, caching and shared sidebar. | | C6 | `01a108ef-55ee-7f60-88e7-37989f2c71c5` | Oct 4, `ace2` | Canary, tracker migration, names/summaries, tab API, two-window behavior, embedded native inspection, persisted images, picker-open shutdown, and upgrade checks. | | CC-01 | `169c4927-e389-48ad-b66b-26a5029e4968` | Sep 30, `../ace` | MIT-release license/provenance review split across three research agents. | | CC-02 | `040a8d61-c298-461d-b91f-48a0bbfcc3f5` | Sep 30, `../ace` | Cmd+O project/folder flow, lane skill, native build/process handling, PR and merge. | | CC-03 | `9cef56d4-f52d-4ce1-af31-aa8f0de205c9` | Oct 1, `../ace` | Domain research via shell/network queries; adjacent product work, not a hard coding blocker. | | CC-04 | `60ffb519-7f02-466b-a9a9-f12487eddf94` | Oct 1, `../ace` | External-agent control research, old/current chat-composer comparison, selected ports, PR and merge. | | CC-05 | `2f1d4c7b-33a9-405b-ad89-6fddb7d448eb` | Oct 1, `../ace` | Six-way review/cleanup of tests, mocks, docs and comments; combined report and PR. Shared-lane historical writes must be adapted to Ace's current one-writer-per-lane rule. | | CC-06 | `dbc55c55-71fe-4e4f-9efa-3d4b5872b4d6` | Oct 1, `../ace` | Identity implementation and revision toward Tailscale; real CLI/network checks and PR work. | | CC-07 | `b6ad029b-4b78-4b85-81a2-caf178e81390` | Oct 1, `../ace` | Agent instruction editing and real channel/subagent verification; browser inspection, failed-run debugging, background watchdogs and cancellation. | | CC-08 | `58da654a-a64c-4a69-bc54-08b08eed99eb` | Oct 1–2, `../ace` | Screenshot-driven macOS window-control fix, issue, build, PR and merge. | | CC-09 | `a445cafb-e30f-409e-b62b-c45ba400350d` | Oct 2–3, launched `../ace`, worked across old Ace and **ace2** | Ace2 bootstrap and shared UI port, real providers, gateway/hosted channels, Cloudflare deployment/docs, logging, Diff/Terminal tabs, images, mobile web and context usage. | | CC-10 | `db9efa8d-e8c5-44e8-8393-df40598f12d3` | Oct 3, `../ace` | Isolation/external-harness investigation motivated by missing computer use. | | CC-11 | `4d07af1b-2e69-4e82-8a99-47beb3e5d383` | Oct 3–4, `ace2` | Screenshot-informed process interruption; machine assistance, not evidence that Ace's shell cannot stop a process. |

Codex dates above are local session starts; Claude spans use embedded UTC timestamps. To reproduce privately, locate the Codex rollout with the session ID under `~/.codex/sessions/`, or the Claude `<session-id>.jsonl` under the corresponding `~/.claude/projects/` checkout directory. Raw histories are deliberately not attached to this issue.

High-value trace anchors: C3 lines 527/596 and 2196 distinguish a historical lane failure from its reported fix; C4 lines 3967/5300 cover upgrade/real-run continuation; C5 lines 583/777/805/851/1070 cover developer-console/DOM/shadow-root inspection; C6 lines 1764/1797/1935 cover two-window behavior and 3695/3775/4083 cover native capture/replay. CC-07 lines 1300/1330 contain background watchdog invocations; CC-09 lines 6246/6256/6301 cover image uploads, 7288 mobile/touch emulation, and 8695/8744 console/network inspection. These are raw-log line anchors at the audit cutoff, not links that expose transcript contents.

### Repository development records

| Record | What it establishes | | --- | --- | | [PR #1](https://github.com/githubnext/ace2/pull/1) | Comparing old Ace and updating the porting list was reported entirely in an Ace channel. | | [PR #2](https://github.com/githubnext/ace2/pull/2) | The automatic Diff-tab change was reported entirely in Ace. | | [PR #3](https://github.com/githubnext/ace2/pull/3) | GitHub Issues/PRs work used Codex for edits, review, React Doctor, smoke checks, and Safari inspection; Ace ran checks, builds, and Git/PR commands. | | [PR #4](https://github.com/githubnext/ace2/pull/4) | Packaged PATH debugging used Codex investigation, edits, and minimal-environment smoke checks; Ace ran the remaining checks and Git/PR operations. | | [PR #46](https://github.com/githubnext/ace2/pull/46) | Tab API work used Ace terminals and a real Ace agent for validation, but external orchestration, edits, and computer use. This PR was unmerged at the snapshot. | | [PR #47](https://github.com/githubnext/ace2/pull/47) | Native desktop observation shipped. Builds, runtime checks, and Git/GitHub operations ran in Ace; Codex still supplied orchestration, source work, and computer use. |

These PRs are additional evidence, not six additional independent sessions. The local `../ace` checkout also contains local-first reconstruction work; a legacy component or design aspiration is not proof that the current checkout ships that behavior. #6 remains the old-feature reference. Its deliberate exclusion of Plan and Document tabs is preserved.

## Coverage of the original checklists

“Covered” means the issue explicitly describes the work; it does not mean implementation or verification is complete. “Residual” means the literal issue scopes do not guarantee the workflow. Current status refers to the source baseline above, not every installed app or lane. The comparison uses #5 before this expansion and the latest revised #8; added scopes above are precisely what the old checklist did not guarantee.

| Workflow | Today | After the original #5 checklist | After that checklist and #6 | | --- | --- | --- | --- | | Edit code; run checks and Git commands | Native file/shell tools and lanes exist. Human file editing lacks a File tab. | Agent work remains possible. | [#22] adds the human file surface. | | Review changes and deliver PRs | Diff and GitHub read views exist; `git`/`gh` can mutate from Ace. | Already feasible by shell. | [#20], [#28]–[#30] improve the workflow; execution evidence still required. | | Inspect native apps and macOS dialogs | App/window inventory and observation shipped in #47 / canary 0.0.10; no native clicks or typing. | Updated [#8] explicitly covers input, clipboard, menus/dialogs, visual targeting, replay/cancellation/coordination, and shared activity. | Covered by #8; its signed-app, real-model and second-machine criteria still must pass. | | Exercise and debug the web UI | No installed browser automation/debugging tools. | [#16] opens a preview; [#8] operates native browser Accessibility/pixels and explicitly excludes DOM/browser-session integration. | Residual browser tool gap. | | Inspect a screenshot or render written to disk | Native `read` returns `unsupported_image`. Composer images and desktop tool images work. | Residual. | [#26] is non-image upload support, not an agent image reader. Residual. | | Continue existing Codex/Claude Code work | No integrated external harness in the channel registry. | [#9] names bringing in an existing run; ongoing lifecycle needs acceptance criteria. | Still ambiguous unless [#9] explicitly includes continued execution and recovery. | | Ask questions and redirect a busy agent | Busy input already steers; stop exists. Question cards and queued-input visibility/edit/delete are not connected. | Completion notices [#12] help, but question/queue controls remain. | [#21] and [#24] cover the surfaces; real waiting and steering semantics must pass. | | Coordinate parallel reviews and implementation | Native subagents exist; tool batches can run in parallel. Child tool calls wait for a final answer. | No explicit interactive subagent lifecycle work. | [#19] exposes chats; background status, follow-up, interruption, and result collection remain underspecified. | | Keep working while CI/dev servers run | Shell can run long commands; local terminals exist. | [#11], [#16], [#48] improve access and correctness. | [#29] handles CI actions; generic process handles, input, completion wakeups, and recovery remain unspecified. | | Use repository rules and skills | Root AGENTS/CLAUDE instructions and repository skill/rule discovery exist. | No further tool/skill scope. | [#27] is a picker, not global/plugin skill discovery or MCP integration. | | Research docs and upstream code | Shell HTTP/Git tools can do it; the sampled harnesses supplied richer web/MCP tools. | Feasible manually; equivalent research tooling is unspecified. | Same unless tool integration is explicitly scoped. | | Maintain long-run context | Durable pi history, automatic compaction, usage, and rolling summaries exist. | Cross-cutting long-work/restart validation remains necessary. | [#33], [#36] improve resumption; still prove the actual long-session workflow. No new goal subsystem is justified by this sample. | | Work across two hosts | Tailnet routing exists; real team verification remains [#10]. | [#10], [#11], [#15] address key paths. | Same; test teammates' actual workflow. | | Move active work off the current machine | Not implemented; backups do not move lanes or execution. | [#49] covers a recoverable live handoff. | Same; browser/native state that cannot transfer must be reported honestly. | | Trust multiple windows and reconnects | Shared layout/navigation can overwrite each other; a stray-prefix terminal defect is reported; replay is a suspected cause. | [#44], [#45], [#48] cover observed failures. | Same; protect these behaviors as regression scenarios. | | Build and install Ace from Ace | Existing release CLI/CI and update handoff support this. | [#5] alone does not include the second-Mac upgrade check. | [#39] is in [#7], outside both lists; include it in the end-to-end gate. |

## What needs explicit scope

The following are recommended issue additions or acceptance expansions. They are not a second backlog. Split new scopes into linked child issues without duplicating the existing issue scopes.

### Browser automation and debugging from a channel

**Priority: required for UI development. Coverage: new child of #5, related to #8 and #16.**

The histories used browser snapshots, screenshots, clicking, filling, JavaScript evaluation, console and network inspection, uploads, viewport changes, and mobile emulation. A screenshot of a native browser window does not replace those debugging capabilities. Opening a URL does not supply an agent tool to inspect the page or prove the result.

The required scope is a supported browser backend with explicit browser/tab identity, navigation, accessible/DOM inspection, screenshot capture, interaction, console/network diagnostics, and viewport control. Include file upload when replaying the attachment workflow. It may wrap an existing browser tool or MCP implementation; a universal plugin marketplace is not a prerequisite. The execution host must be clear for local and hosted channels.

Acceptance: from an Ace channel, launch a lane's dev server, open its correct URL, reproduce a UI defect, inspect the console or failing request, edit the lane, verify the fix at desktop and narrow widths, and retain the evidence in the chat. Reconnect and identify the same browser target without guessing. Confirm that the tools act on the execution machine, not whichever client is currently viewing the channel. Include a real native Ace-window check through [#8]. The revised #8 already owns native browser Accessibility/pixel operation; do not duplicate that work in this separate browser scope.

### Read and retain generated visual artifacts

**Priority: required for visual verification. Coverage: new child of #5, related to #8 and #26.**

Ace installs pi's `CodingTools` in [channel.ts](https://github.com/githubnext/ace2/blob/ce1bd9bde77955b15521a5cbeee1236bdc14fa13/packages/channel/src/channel.ts). At this baseline, the installed pi `read` tool reads text and explicitly returns `unsupported_image` for image files. Therefore a shell script can create a screenshot or render, but the native agent has no direct file-to-model image tool. This is narrower than claiming Ace has no vision: uploaded images and `desktop_inspect` already reach the model and durable transcript. Opening an image in a native viewer and inspecting that window is an indirect route, especially once [#8] is complete; it is not a direct path-based image tool.

Acceptance: generate a PNG in a lane, ask the native agent to inspect it by path, and verify the image appears in the tool result for the participant and survives reopening the channel. Exercise a hosted channel too if hosted execution is being claimed. Define supported formats, size bounds, and clear errors using the existing bounded image path. A useful extension is rendering PDF pages through a shell tool and inspecting the output; a full document editor is not required.

Distinguish a durable captured image from a link to a temporary file. Long command output also spills to temporary files today; a participant should know when a linked artifact may disappear. Use pi for durable chat/tool content. Do not introduce a second message or run store.

### External harness continuation, not just import

**Priority: required if the team intends to keep either external harness. Coverage: expand #9.**

The recorded escapes were not just opening old transcripts. Codex and Claude Code kept editing, running tools, receiving follow-up instructions, creating subagents, and conducting UI checks. Copying their messages into a native chat would leave those dependencies outside Ace.

Specify support separately for starting a new run, attaching to an existing one, importing historical context, and resuming after interruption. Preserve the relationship between the channel, chat, harness session, and lane. Make tool output, errors, images, usage, active work, and terminal/background processes visible. Establish how questions, queued input, stop, kill, subagents, and model selection map to the external harness. State what cannot transfer.

Acceptance: choose one real unfinished Codex session and one Claude Code session, continue each in Ace on its existing work, receive a new human correction, run the required tools, produce a reviewable diff and PR, then reconnect/restart without launching a duplicate writer or losing output. Verify the same lane has at most one writing chat. Preserve pi as the channel system of record; adapter-specific state must not become a competing channel store.

An alternative is to complete those tasks with the native harness and deliberately accept a context handoff. That can meet the development goal, but it is a different product promise from fully hosting the original harness. Keep this distinction explicit in [#9] so that a context handoff is not mistaken for external-harness continuation.

### Interactive subagents and background work

**Priority: required for the observed parallel workflow, with a shell/CLI bridge possible. Coverage: expand #19/#24 or add a focused child of #5.**

The current [subagent tool](https://github.com/githubnext/ace2/blob/ce1bd9bde77955b15521a5cbeee1236bdc14fa13/packages/channel/src/agents.ts) creates a durable child chat, can choose a model, and waits for its answer. pi can execute multiple tool calls in a batch; Ace does have parallelism. The child receives the task rather than the parent's transcript, and its registry removes the subagent extension, so it cannot recursively create children through that tool. Human access to those chats is the separate [#19] gap.

What the richer sessions additionally used was starting work, receiving partial findings, sending corrections while other work continued, following up with an existing agent, stopping a specific task, and collecting its eventual result. A visible child chat does not by itself provide those operations to the parent agent. The CLI can open chats and submit detached work; that is a possible bridge to validate rather than pretending no route exists.

Acceptance: run three independent review tasks, keep the parent available, send a correction to one, stop another, inspect the remaining child, and integrate the results. Read-only reviews can share a lane; separate writers must use separate lanes. Exercise parent stop/kill and reopening so no child silently continues against the wrong ownership. Do not copy the old shared-writer pattern just because an external harness permitted it.

Long commands themselves are already supported: pi's shell captures streaming output, spills large output to a file, and has no default timeout. Ace currently projects completed tool text/images but does not forward pi's live `tool_execution_update` events. Completed text includes rendered diagnostics such as the full-output path; those are not lost. An agent build should expose progress while it runs, not require a separate terminal to find out whether it has stalled. The missing contract is a supported way to start/poll/input/stop an interactive or background job and notify the chat when it finishes. Acceptance should include a dev server plus a CI run while the participant continues asking questions, reconnects, and eventually stops the work. Terminal sessions closing during a desktop update is a documented behavior; report it and restart deliberately rather than claiming transparent process migration.

### Rules, skills, tool integration, and research

**Priority: validate the actual required toolset. Coverage: expand #27 only where relevant; browser tooling deserves its own issue.**

[Context loading](https://github.com/githubnext/ace2/blob/ce1bd9bde77955b15521a5cbeee1236bdc14fa13/packages/channel/src/context.ts) already reads root `AGENTS.md` and `CLAUDE.md`, lists repository `.agents/skills` and `.claude/skills`, and lists `.claude/rules`. It is not equivalent to all user-level skills, plugin-provided tools, nested instruction semantics, custom-agent definitions, or MCP configuration from the external harnesses. [#27] currently promises a composer picker for checkout skills and agents.

Inventory the set actually used for Ace work: repository rules, lane/review workflows, React Doctor where applicable, browser tools, and documentation research. A shell command or explicitly read local skill can be sufficient. A tool that only exists inside Codex or Claude Code cannot be made available by displaying its name in the composer. The current local `../ace` Codex adapter is a reference, not proof of integration parity: its private profile disables ambient MCP/plugin and host-skill discovery. Porting that adapter alone would not bring all the sampled tools into Ace.

Acceptance: in a lane, load the intended instructions and a real skill, run its required command, and show its result. Repeat with a selected custom agent if the team uses one. For research, retrieve a primary source and preserve its URL and supporting evidence. Shell `curl`/Git or a docs tool can meet that need; generic MCP parity is not necessary unless the chosen required tools depend on it. Do not require all installed plugins for dogfooding.

### Long work, resumption, and model controls

**Priority: validate the observed long-run workflow. Coverage: #9/#24/#36 and the existing pi recovery contract.**

Ace already uses durable pi history and compaction, resumes unfinished work, reports token usage, and maintains rolling summaries. It is incorrect to describe all long-session support as missing. The current channel model reference is provider/model ID; the sampled external harnesses also exposed richer orchestration and run controls that the channel protocol does not currently promise.

Acceptance: continue a substantial task across compaction and a host restart, retaining the user's latest constraints, unfinished work, lane, and tool results. Exercise a human correction while busy. The reviewed Codex root logs contain no explicit goal-tool use, so this review does not propose a new goal or budget subsystem. Model-effort controls should be added only where an actual required workflow establishes the need. Completing a rolling-summary UI or a channel fork does not establish continuity by itself. Busy input already uses pi's `whenBusy: "steer"`; [#24] is about exposing and controlling pending input, not inventing basic steering.

### Developing, upgrading, and recovering Ace from Ace

**Priority: required before claiming the whole team can stay in Ace. Coverage: #10, #39, #45/#48 and existing data/update contracts; #49 for actual host movement.**

Keep the installed working Ace separate from the source build being modified. The existing development profile, separate data and Keychain services, release CLI, and CI signing pipeline already support this separation. Use them; no new release platform is needed.

Acceptance: build a signed canary from an Ace channel, inspect CI and repair a failure through Ace, explicitly publish, install on a second Mac, and reopen an existing channel with retained history and real model continuation. Preserve a verified backup and dirty/untracked lane work for any storage migration. Follow [data](https://github.com/githubnext/ace2/blob/ce1bd9bde77955b15521a5cbeee1236bdc14fa13/docs/data.md) and [updates](https://github.com/githubnext/ace2/blob/ce1bd9bde77955b15521a5cbeee1236bdc14fa13/docs/updates.md); never reset a store to obtain a green result. Include a documented recovery route if the development build breaks the UI the participant is using.

Also qualify agent-to-agent work across hosts. The local native `channels`/`message` tools currently use the local catalog, while human gateway routing can reach peers; hosted messaging is separately unfinished under [#13]. A real two-machine pass must distinguish human chat, remote tool execution, peer terminals, agent discovery/delivery, and actual channel movement. Do not treat one as proof of the others.

For [#49], test a separate active-work handoff: destination readiness, source execution ending before destination execution starts, dirty and untracked files, interrupted transfer, and native/browser work moving to the destination. A backup is not a lane transfer, **Kill** is not a pause, and connecting to another host is not moving the channel. Treat this as a distinct capability with its own completion evidence, rather than counting remote viewing as a successful handoff.

### Tracker and documentation corrections

- The revised [#8] is current: it records inspection shipped in [PR #47] / canary 0.0.10, explicitly scopes the remaining native slices, and separates DOM/browser-session and direct audio APIs. Those native requirements are covered work, not omissions discovered by this review. Hosted inspection evidence so far used the local Workers/Durable Objects runtime. - [#23] remains open although durable metadata, user rename, agent naming, summaries, and migration checks are present. [#34] has a summary/details surface, and [#36] has a Pick back up list. Open status alone is not absence of code. - [#43] has an unmerged [PR #46]. Its related bugs [#44]/[#45] were observed during that work; do not assume its API is on the audited baseline. - The architecture's final “Not yet built” paragraph still broadly lists terminals and attachments. Local terminals and image input exist. Interpret the remaining gaps as the specific peer/hosted terminal and attachment capabilities, and reconcile the wording. - [#39] is outside #5/#6, but the second-Mac upgrade belongs in the dogfooding evidence. - [#40]–[#42] concern wider distribution/source release. They are not evidence that the team cannot build Ace in Ace. Do not make public source publication a prerequisite for this goal.

## Acceptance sessions to run entirely in Ace

Record channel, lane, source revision, model/harness, machine/build, result, and evidence links in the relevant issue. These are real-runtime scenarios; they do not request a new suite of mock-based tests. Use existing scripts and checks appropriate to each change.

| Session | Steps and observable pass condition | Main coverage | | --- | --- | --- | | A. Start and deliver ordinary work | Select a project; choose an issue or existing branch; create/use its lane; edit; run required checks; inspect Ace's Diff; create a PR with Built in Ace filled accurately. | #20, #22, #28–#30; existing shell route | | B. Browser bug | Start the lane's dev server, target the right tab, reproduce a bug, inspect DOM/console/network, fix it, and verify desktop/narrow layouts. Keep screenshots and diagnostic evidence readable after reopening. | Browser gap, #16, #26 | | C. Native desktop bug | Inventory the intended Ace app/window, exercise Settings or a native dialog with actions, verify accessibility and visual state, then confirm local versus destination-host targeting. | #8, #10 | | D. Generated artifact | Create a screenshot/render in the lane, inspect it by path with the native model, change the source based on that inspection, and reopen the tool result. | Image-reading gap | | E. Continue Codex | Bring one unfinished real session into Ace, retain its lane/context, steer it, review output, complete its PR, and reconnect without duplicate execution. | #9, #24 | | F. Continue Claude Code | Repeat with a real Claude Code session and its required skills/tools. Verify support independently rather than inferring it from Codex. | #9, #27 | | G. Parallel review | Parent coordinates three reviewers, receives partial findings, redirects one, stops another, opens a child chat, and combines the results. Separate writing lanes; parent kill reaches children. | #19; subagent lifecycle | | H. Long command and attention | Keep a dev server and CI/build work running while exchanging new instructions. Inspect progress, handle a question, observe completion, reconnect, and terminate the intended process. | #12, #16, #21, #24, #29; jobs | | I. CI and review recovery | Read a failed check/review, locate its cause, fix it in the lane, rerun the relevant checks, update the PR, and complete review through Ace. | #20, #29, #30; existing `gh` route | | J. Window and terminal reliability | Give two windows different tabs/names; navigate, reload, close either, and reconnect. Acknowledged state survives. Paste into a restored terminal and verify the first command is exact. Collapsed controls leave focus/accessibility navigation. | #43–#45, #48 | | K. Long context and restart | Continue a substantial task across compaction and helper restart; inspect retained constraints, lane, usage, tool output, and unfinished work. Do not repeat unsafe actions silently. | Existing pi behavior, #9, #24, #36 | | L. Release Ace from Ace | Build the clean, pushed lane through release CI; inspect failures/logs; explicitly publish; upgrade a second Mac; reopen existing channels and continue with a real model. | #10, #39; data/update contracts | | M. Team work | Two real people/machines find the same project/channel, read and invoke as intended, exercise peer terminals, disconnect/reconnect, and confirm execution stays on the owning host. | #10, #11, #14, #15 | | N. Move active work | Move an active channel with dirty/untracked files and a child chat; interrupt and recover the transfer; verify only the destination executes and native activity moves there. | #49; separate from M |

A–D and G–M establish the native development loop. E/F additionally establish the external-harness promise, which remains tracked in [#9]. N establishes the machine-handoff promise in [#49]. Report these outcomes separately; a native-only pass does not close the external-harness or host-movement requirements. Hosted channels and real-phone use need their own passes when included in scope; a local desktop result cannot certify them.

## Source checks behind the capability claims

- [Channel tool registration and durable resume](https://github.com/githubnext/ace2/blob/ce1bd9bde77955b15521a5cbeee1236bdc14fa13/packages/channel/src/channel.ts#L91): coding tools, lanes, child agents, metadata, messaging, and optional native desktop tools; no installed browser/MCP layer. - [Subagent contract](https://github.com/githubnext/ace2/blob/ce1bd9bde77955b15521a5cbeee1236bdc14fa13/packages/channel/src/agents.ts#L32): task/model parameters, durable child, child extension removal, wait for final answer. Parallel tool execution is available in pi; the missing piece is interactive supervision. - [Busy input submission](https://github.com/githubnext/ace2/blob/ce1bd9bde77955b15521a5cbeee1236bdc14fa13/packages/channel/src/channel.ts#L306): `whenBusy: "steer"` already exists. - [Live-event projection](https://github.com/githubnext/ace2/blob/ce1bd9bde77955b15521a5cbeee1236bdc14fa13/packages/channel/src/channel.ts#L469) and [completed results](https://github.com/githubnext/ace2/blob/ce1bd9bde77955b15521a5cbeee1236bdc14fa13/packages/channel/src/channel.ts#L522): live tool updates are not forwarded; completed text/images are, including diagnostics rendered into the text by pi. - [Repository instruction and skill discovery](https://github.com/githubnext/ace2/blob/ce1bd9bde77955b15521a5cbeee1236bdc14fa13/packages/channel/src/context.ts#L5): supports root files and two repository skill directories; not all global/plugin resources. - [Human chat selection](https://github.com/githubnext/ace2/blob/ce1bd9bde77955b15521a5cbeee1236bdc14fa13/apps/app/src/channel.tsx#L14): fixed to chat 1 at this baseline, despite multi-chat CLI/backend support. - [Native desktop tools](https://github.com/githubnext/ace2/blob/ce1bd9bde77955b15521a5cbeee1236bdc14fa13/docs/desktop-tools.md): observation-only implementation and local/hosted execution semantics. - Installed `@earendil-works/pi-durable@1.0.0`, `dist/tools/read.js:27–40`, explicitly returns `unsupported_image`; `dist/tools/bash.js` exposes command and optional timeout, with no default timeout or interactive job-handle API. These are dependency-source observations, not a fresh live-model test. Check the installed package under `packages/channel/node_modules/` when upgrading it.

## Implementation boundaries to preserve

Keep the channel runtime-neutral. Inject browser, desktop, filesystem, and process capabilities from the execution environment; machine-specific work belongs to the host. Use the shared protocol types and UI components. Put durable chats, runs, questions, tool results, and child ownership in pi. Keep personal window layouts out of channel history. Preserve the single collaborator-agent switch and the existing tailnet model rather than adding unrelated roles or per-tool approval systems.

Every stored-format change needs a versioned migration checked against a backup of an existing channel. Preserve project-first desktop behavior: opening a folder adds a project; creating a channel is separate. Full dogfooding includes respecting those ownership and data contracts while modifying Ace itself.

## Built in Ace for this review

This review began in Codex. Parallel history/source analysis and preparation of this issue body used Codex because Ace cannot host this existing harness run ([#9]). Initial inventory also used the external shell. Ace Canary's terminal ran the checkout check. Publishing was attempted through Codex computer use, but a clipboard timeout and a changed UI target interrupted those attempts; the issue update used `gh` through the external shell. These computer-use failures do not establish an Ace defect. Native actions remain under [#8], and this existing harness remains outside Ace under [#9]. This is a partial-dogfooding result. The suggested acceptance sessions have not been rerun by this audit.

[#5]: https://github.com/githubnext/ace2/issues/5 [#6]: https://github.com/githubnext/ace2/issues/6 [#7]: https://github.com/githubnext/ace2/issues/7 [#8]: https://github.com/githubnext/ace2/issues/8 [#9]: https://github.com/githubnext/ace2/issues/9 [#10]: https://github.com/githubnext/ace2/issues/10 [#11]: https://github.com/githubnext/ace2/issues/11 [#12]: https://github.com/githubnext/ace2/issues/12 [#13]: https://github.com/githubnext/ace2/issues/13 [#14]: https://github.com/githubnext/ace2/issues/14 [#15]: https://github.com/githubnext/ace2/issues/15 [#16]: https://github.com/githubnext/ace2/issues/16 [#17]: https://github.com/githubnext/ace2/issues/17 [#18]: https://github.com/githubnext/ace2/issues/18 [#19]: https://github.com/githubnext/ace2/issues/19 [#20]: https://github.com/githubnext/ace2/issues/20 [#21]: https://github.com/githubnext/ace2/issues/21 [#22]: https://github.com/githubnext/ace2/issues/22 [#23]: https://github.com/githubnext/ace2/issues/23 [#24]: https://github.com/githubnext/ace2/issues/24 [#25]: https://github.com/githubnext/ace2/issues/25 [#26]: https://github.com/githubnext/ace2/issues/26 [#27]: https://github.com/githubnext/ace2/issues/27 [#28]: https://github.com/githubnext/ace2/issues/28 [#29]: https://github.com/githubnext/ace2/issues/29 [#30]: https://github.com/githubnext/ace2/issues/30 [#31]: https://github.com/githubnext/ace2/issues/31 [#32]: https://github.com/githubnext/ace2/issues/32 [#33]: https://github.com/githubnext/ace2/issues/33 [#34]: https://github.com/githubnext/ace2/issues/34 [#35]: https://github.com/githubnext/ace2/issues/35 [#36]: https://github.com/githubnext/ace2/issues/36 [#37]: https://github.com/githubnext/ace2/issues/37 [#38]: https://github.com/githubnext/ace2/issues/38 [#39]: https://github.com/githubnext/ace2/issues/39 [#40]: https://github.com/githubnext/ace2/issues/40 [#41]: https://github.com/githubnext/ace2/issues/41 [#42]: https://github.com/githubnext/ace2/issues/42 [#43]: https://github.com/githubnext/ace2/issues/43 [#44]: https://github.com/githubnext/ace2/issues/44 [#45]: https://github.com/githubnext/ace2/issues/45 [#48]: https://github.com/githubnext/ace2/issues/48 [#49]: https://github.com/githubnext/ace2/issues/49 [PR #46]: https://github.com/githubnext/ace2/pull/46 [PR #47]: https://github.com/githubnext/ace2/pull/47

Migrated from [TODO.md](https://github.com/githubnext/ace2/blob/21ac3df5cf6c963cf20e33b0d470ba45eac40150/TODO.md); expanded from the recent Codex/Claude Code history review.

This formatting update also used Codex and `gh` outside Ace, continuing the #8/#9 escape recorded above.

## Dogfooding scope

#5 now separates **MVP** (a complete native development loop is possible) from **core/QOL** (the work controls and everyday surfaces that keep us in Ace). Chat and project presence remain core through #35 and #17. Composer defaults and sticky mode are tracked in #59.

- Native inspection/action/verification (#8), browser tools (#50), and a real delivery/recovery pass (#55) establish MVP. #8 and #50 can proceed independently; #55 validates their combined workflow. #8's entire native-automation roadmap is not an additional MVP gate. - External-harness continuity (#9) and direct saved-image inspection (#51) are core. Native pi already supports coding, and a native image viewer provides an indirect image-inspection path. - #10 verifies baseline two-host collaboration. It does not wait for peer terminals, repository-wide project identity, or agent-to-agent discovery.

The remaining work stays tracked outside #5:

- #58 owns host migration (#49), peer terminals (#11), project identity (#15), peer-agent messaging (#57), hosted channels (#13), directory updates (#14), and phones (#18). - #6 retains the broader old-Ace feature inventory, including Git/CI management UI, uploads, skill pickers, navigation conveniences, conversation editing/forks, and dashboard/input polish. Dogfooding-relevant issues may be referenced there while owned by #5. - #7 retains distribution work, including published-upgrade qualification on another Mac (#39). - #56 tracks actual skill/tool integration beyond the composer picker. #43 remains standalone tab-control work.

Created focused issues for the previously untracked browser, image, subagent, job, live-progress, native-qualification, skill/integration, and peer-messaging scopes. Every work item in #5 now links an issue.

The [earlier session review](https://github.com/githubnext/ace2/issues/5#issuecomment-5986485157) is a broader evidence inventory, **not a list of dogfooding gates**. Its detailed scenarios remain useful in their owning issues; the current #5 body defines dogfooding scope. Shell Git/gh/CI work inside Ace counts, and #55 validates existing mechanisms rather than requesting a new release platform.

Composer reference: `ace-old` uses Esc to leave agent mode and double Esc within 350 ms to enter it. Ace2 already has that handler; #59 verifies its integration and restores per-channel navigation stickiness, alongside the requested agent-first default.

These tracker edits used Codex and `gh` outside Ace, continuing the #8/#9 escape recorded in that review.

New native dogfooding finding: https://github.com/githubnext/ace2/issues/79. `desktop_apps` copied activity/visibility defaults from mutation inventory rather than observing them, so repeated `active: []` output could not prove the desktop's actual activity. A focused client change will preserve exact PID/generation inventory and join real presentation metadata, reporting unknown when unavailable. No implicit activation or OS-lock conclusion; signed and live validation are pending.

Dogfooding findings from #91 work in Ace Canary 0.0.11: https://github.com/githubnext/ace2/issues/94 (plain-text braces dropped from timeline messages) and https://github.com/githubnext/ace2/issues/95 (trailing colon included in linkified URLs).