[ifdotpy]

Remove the whole PROGRESS.md feature: Studio no longer asks lead agents to write <stateDir>/progress/<agentId>/PROGRESS.md (VM leads: <layrHome>/.studio/progress/<id>/PROGRESS.md), and no longer watches, reads, measures or shows it.

Removed

• Web renderer: the progress panel above the composer (AgentPanel, ProgressMarkdown, progress cache, layout reports, the "progress hidden" preference scope), and its specs and status notes.
• client-core: the progress module (progress.read, progress.peek, progress.cache_*).
• HTTP API: GET /api/panel, POST /api/panel/layout, the schemas ProgressPanel, PanelLayoutBody, PanelLayoutReport, PanelLayoutResult, and the panel member of ResourceRef. Changed in openapi.json, then pnpm run contracts:generate (new api.ts and schema hash). The Python models, the constraint baseline (acceptedOperationRemovals) and the HTTP conformance ledger follow.
• Rust runtime: progress_panel.rs, progress_watch.rs, the native progress watch in the sync stream, the ProgressWatch port, the progress-layout server subcommand, the progress folder creation in workspace readiness, the progress folder as a sandbox writable root (thread config, turn sandbox, monitor commands), the progress text in developer instructions and turn context, progress_template in preparation-resources.json, and the shared values MAX_PROGRESS_FILE_BYTES, PROGRESS_FILE_LIMIT_LABEL, PROGRESS_LAYOUT_*.
• Python server: codex_progress.py, codex_progress_watch.py, codex_progress_layout.py, codex_panel.py, the routes, the sync hub watchdog, and the same instruction, sandbox and context parts. VM guest: the agent.progress method and the .studio/progress provisioning in line.bind.
• Skills and docs: the text that asks leads to update PROGRESS.md, codex-workspace/references/panel.md, and the sections in docs/orchestration.md, docs/sync-protocol.md, docs/product-guide.md, docs/windows-server.md, the runtime READMEs and the operation map in docs/plans/rust-runtime-work-breakdown.md. docs/verification stays as history.
• Tests that exist only for the feature (progress file, runtime, layout and panel contracts, watcher tests, panel browser specs). Tests that used panel only as a sample resource kind now use queue.

Kept for compatibility

• The orchestration_context tool schema does not change. Its topic enum still has panel. A catalog change would change the catalog digest of live threads and start a catalog refresh. topic=panel now returns PROGRESS_FILE_RETIRED_NOTICE, and topic=background no longer has the workflow entry.
• origin/main added PanelGuidance, a pre-SQL read of panel.md for topic=panel. It is removed with the panel guide. The test callback_panel_returns_the_retired_progress_notice checks that topic=panel returns the notice and reads no skill file.
• PROGRESS_FILE_RETIRED_NOTICE is owned by runtime-schema/src/shared_values.rs. The Python copy has a parity check in shared-values-contract.py.
• A lead whose known context versions have progressFile (old leads) gets one turn-context block [Studio progress file retired] with the notice, and the manifest records the notice version, so it is sent once. New leads and workers never get it.
• Stored data stays readable and unused. Nothing is deleted: old <stateDir>/progress/ folders, agent PROGRESS.md files, PROGRESS.layout.json, the client client_progress table, preparedContext.versions.progressFile and codex-progress-hidden:* preferences. The server still accepts that preference key, so old stored preferences pass validation. No migration.
• The provider launch command of Codex and Claude app-servers does not change.

Resume safety

The receipt check (thread_prepare::reduce_receipt, ThreadRejection::Stale) compares the prepared and current snapshots by receipt identity, agent, epoch, account, connection, cwd, settings, thread and attempt. It does not compare developer instructions or guidance. Both snapshots come from the same build. The role text is frozen in nativeRoleGuidance, so old leads keep their role text. A changed instruction digest of a loaded thread only causes a new thread/resume, as for any settings change.

New test account_worker::tests::closure::a_lead_prepared_with_the_old_progress_file_resumes_its_thread: a lead with an old frozen role that names PROGRESS.md, a preparedContext and a delivered manifest with progressFile, and a progress/<id>/PROGRESS.md file. It checks:

• The resume has no progress text and no progress writable root.
• The reply is accepted with no error.
• The first turn has the notice once. Its sandbox writes only the cwd.
• The second turn has no notice.
• The old file content is unchanged.

The turn-preparation corpus has Rust-vs-Python cases for the notice: old version gives the notice, retired version gives none, worker gives none.

Checks

• just test-fast on 66f87c4 (rebased on origin/main 96c6b55): passed, 825 s.
• just test-comprehensive on 6a26b98 (on origin/main 69637aa): every step passed except one load timeout.
  • Steps that passed: server 6257 passed, 0 failed, 225 skipped; server bridge 103 passed; renderer build; Rust Clippy.
  • Rust nextest: 3092 passed, 1 failed. The failure was studio-runtime-server::integration wave7_p01_registry::registry_drains_strict_account_pages_after_one_global_wake, a 23 s wait that ran out at load about 140. Alone it passed 2 of 2 (13 to 14 s).
  • The recipe stops at the first failed step, so I ran its remaining steps one by one on the same commit, and all passed: web typecheck:focused, test:api-contract-types, typecheck:client-helper, web vitest unit (1241 passed, 2 skipped), tooling (36 passed), browser smoke (9 passed).
• Between the two runs, origin/main got b7c5c05 and 96c6b55, which do not touch files of this PR. The rebase had no conflicts, and just test-fast passed again on the new commit.
• Focused Rust tests on 6a26b98: 138 passed. They include callback_panel_returns_the_retired_progress_notice and a_lead_prepared_with_the_old_progress_file_resumes_its_thread.
• studio-contracts --check: passed.
• An earlier just test-fast run on 6a26b98 failed in tooling tests only because the shell had /usr/bin/python3 (3.9) first on PATH. It passed with Homebrew Python first, and origin/main failed the same way with 3.9.

Earlier runs: on 7e4b32043 and 7be4fc8f0 at load near 200, rust-messages-http-contract.py::MessagesHTTPContract.test_managed_send_matches_python_rows_for_every_delivery_and_replay failed once in the comprehensive server step and once alone. At lower load the same suite file passed 4 of 4 on the rebased branch and 1 of 1 each on 7e4b32043, 815919e and 23fc606.