Application improvement program

Engineering record. Status, measurements and decisions below describe the recorded implementation or review. For current usage, start with the documentation library.

This work continues the application review on branch codex/application-improvements, created from main at abbb6be. The original review contained defects, 14 broader product problems, and 73 feature ideas; those are tracked separately below.

The later main update at d1677e1 is also integrated. Its composer Improve feature retains Quick/Repository modes with cancellation, guarded Undo, safe provider permissions, disposable private committed snapshots and mutation leases. Shared access, filesystem restrictions and nonlocal execution profiles cannot bypass their execution rules through this endpoint.

Before publication, this branch also integrates main at 7a593cc: pinned worktree Git namespaces, stronger test-integrity checks, compact run-log patches and shared live-update transport. New workspace/verification helpers retain those namespace guards. Cold recovery decodes patches incrementally and refreshes source identities after compaction. Owner stream sharing uses a private channel secret and an independent enumerable lock ID; shared accounts receive neither, and identity changes close old owner connections. Targeted namespace, storage, broker, authorization and same-tick repository-picker regressions cover the integration.

Current scope: all six priority correctness packages implemented; all 14 broader problems have concrete improvements; all 73 feature items have implemented acceptance scopes. Full-suite acceptance passed. Results are recorded below; feature boundaries remain explicit rather than claiming unrestricted provider parity or complete accessibility conformance. An item is complete only when its behavior is implemented, reachable from its intended interface, documented, and covered by appropriate validation. A service interface, mock, or roadmap entry alone is not an implemented feature.

Correctness and quality gates

• Destination symlink containment and exclusive worktree copying.
• Repository selection and configuration responses cannot overwrite newer choices.
• Notes initialization, failed-write recovery, revision history, and conflicts.
• Invalid routes recover without blanking the application.
• Memory deletion descriptions match actual semantics; editing resolves conflicts.
• Critical browser flows are required by CI, with stable test synchronization.

Existing product problems

• 1. Simplify the first-run decisions.
• 2. Give the composer room instead of opening an empty side panel.
• 3. Make mobile execution controls readily accessible.
• 4. Use consistent completion and verification states.
• 5. Surface native tool approvals.
• 6. Make execution isolation explicit and enforceable.
• 7. Secure phone transport and individual sessions.
• 8. Bound history startup, storage, and browsing. Streaming recovery uses four concurrent runs; archived detail uses an eight-entry/32 MiB cache and compact source-validated projections; old attention is capped and visibly paginated. Compact IDs and active/resumable metadata still scale with history. See run storage.
• 9. Include inline GitHub review comments.
• 10. Enforce browser correctness in CI.
• 11. Make evaluation reproducible and retain experimental evidence gates.
• 12. Separate core responsibilities behind tested modules. Persistence projection/recovery/cold storage, workspace operations, shared authorization, policy enforcement, remote execution, code-host operations and repository coordination have explicit tested modules. The engine retains execution authority and the server composes the route/lifecycle boundaries; further size reduction is ongoing maintenance.
• 13. Improve keyboard, focus, touch, and screen-reader behavior. Theme/viewport browser audits, keyboard navigation and focus restoration, inert closed panels, contrast, target size, mobile tool selection and reduced motion are covered. Assistive-technology/user testing remains ongoing; no complete WCAG certification is claimed. See accessibility acceptance.
• 14. Attribute provider results with samples and uncertainty.

Feature acceptance backlog

• 1. Guided onboarding and dependency/authentication health, including explicit terminal/browser/Docker discovery and refresh.
• 2. Repository readiness inspection and isolated command validation.
• 3. Simple and advanced composer modes.
• 4. Named versioned team presets with import/export.
• 5. Editable acceptance criteria.
• 6. Parameterized task templates.
• 7. Effective settings and provenance inspection.
• 8. Command palette.
• 9. Scoped native tool approval inbox.
• 10. Editable validated workflow graph.
• 11. Priority queue and project fairness.
• 12. Safe checkpoint pause.
• 13. Fork from a checkpoint.
• 14. Selective task reruns and downstream evidence invalidation, with pinned retained baselines and fresh final review/checks.
• 15. Quota-aware deferred execution with durable claims, reported reset windows and explicit ambiguous-launch recovery.
• 16. Token and API-equivalent usage ceilings.
• 17. Conflict-aware task assignments.
• 18. SSH remote workers with explicit repository mappings, worker-local credentials, bounded exact source/result bundles, heartbeats, cancellation, durable claims and receipt-only recovery. Actual encrypted loopback SSH acceptance passed. See worker setup.
• 19. Multiple verification gates.
• 20. Repository verification profiles.
• 21. Requirement-to-evidence mapping across workflows.
• 22. Review coverage reporting.
• 23. Change risk summaries.
• 24. Baseline and flaky-check diagnosis.
• 25. Optional mutation verification.
• 26. Visual and accessibility verification gates.
• 27. GitHub review threads with inline locations/replies, bounded complete-thread loading, explicit remote resolve/reopen, fresh revision/head checks and honest postflight race reporting. See thread synchronization.
• 28. Validate the current merge target.
• 29. Export verification reports.
• 30. Symbol-aware code search and JavaScript/TypeScript imported references through an isolated language service.
• 31. Static architecture exploration across JavaScript/TypeScript, Python, Go, Rust and Java, including manifest packages, directory boundaries, cycles, explicit unresolved/computed edges and exports. No project configuration executes. See architecture explorer.
• 32. File editing with save previews and conflicts.
• 33. Selective file/hunk application.
• 34. Three-way conflict resolution.
• 35. Multi-service workspace launch profiles.
• 36. Context inspection before dispatch: bounded directory expansion, explicit assembled-input measurements and warn/block ceilings. Hidden provider history and later file/image tokens are outside this scope.
• 37. Concurrent workspace activity coordination with in-process workspace mutation leases across starts, resumes and owned worktrees. External/manual programs remain outside the lease system.
• 38. Full checkpoint comparison and guarded staged inverse commits, alongside selective file/hunk restoration. Merge-commit mainline decisions remain manual.
• 39. Memory provenance graph.
• 40. Memory edit conflict resolution.
• 41. Memory deletion impact preview.
• 42. Stale-memory detection.
• 43. Memory duplicates and supported semantic contradictions with policy synonyms/negation, structured boolean/text/numeric interval claims, unit conversion, exact source revisions and overlapping applicability. Unsupported prose is counted and no winner is selected automatically. See semantic claims.
• 44. Dedicated versioned project conventions with immutable history, conflict-safe drafts, preview restore and guarded explicit publication.
• 45. Searchable revisioned notes.
• 46. Curated project onboarding summaries.
• 47. Explicit schedule time zones and previews.
• 48. Inspectable webhook queue.
• 49. Failed delivery replay.
• 50. Automation dry runs.
• 51. Grouped prioritized review inbox for manual and unattended questions, blocked work, failures and results.
• 52. GitLab/Bitbucket code fetch, prepared-container review, comments/replies/resolution, verified-result push, new PR creation and pinned Git merge. Durable unknown-operation receipts prevent automatic replay. Unsupported native queue/policy/atomic approval capabilities are explicit and fail closed. See code-host workflows.
• 53. Linear and Jira sources.
• 54. Opt-in external notifications.
• 55. Documented CLI and versioned API.
• 56. Multi-repository dependency DAGs, pinned verification/source policy, durable child receipts, current accepted result evidence, reviewed shipping matrices and explicit per-repository CAS merges. Actual two-repository browser acceptance passed. See coordinated changes.
• 57. Isolated agent containers.
• 58. Secure paired phone sessions.
• 59. Per-project CAS read/write allow/deny rules enforce app access and intersect current/pinned policies. Manual filtered Docker tasks use immutable prepared images, allowed committed files in a fresh Git namespace, read-only denied-write mounts, bounded outputs, confirmed cancellation and explicit source/policy/content-checked review-branch imports. Ordinary native/SSH/automated execution remains paused under restrictions. Actual Docker isolation/import/cancellation and browser acceptance passed. See filesystem policy.
• 60. Secret filtering for exported content.
• 61. Saved per-type retention policies for archived runs, attachments, run memory and worktrees, with protected exact plans and explicit offline application.
• 62. Backup and restore.
• 63. History compaction and pagination.
• 64. Sanitized diagnostic bundles.
• 65. Persistent connection status.
• 66. Continuous official supported-version CLI version/help matrix, bounded isolated installs, exact executable/version checks, protocol fixtures and retained reports. Five actual official CLI probes passed locally; GitHub Actions execution awaits a pushed branch. See compatibility evidence.
• 67. Task-specific provider comparisons.
• 68. Human rework tracking.
• 69. Critical-path timing analysis.
• 70. Reproducible benchmark fixtures and model identities.
• 71. Local scrypt identities, revocable expiring sessions, scoped viewer/reviewer project roles, safe results/feeds/exports and commit-anchored human review. Owner remains the sole executor. See shared projects.
• 72. Local VS Code integration with SecretStorage connection, task creation, run inspection, cancellation and result worktrees; packaged and tested in the actual editor host.
• 73. Explicit trusted bundled provider/workflow plugins, negotiated API/capabilities, captured hash-verified cache bytes, atomic registration and immutable run version/hash pins. No repository auto-discovery or HTTP installation. See extension contracts.

Implementation boundaries

Mutation, visual and accessibility gates execute explicitly configured repository scripts; they do not supply mutation engines or image baselines. External provider APIs were validated with HTTP fixtures and real local Git repositories, not live third-party account writes. GitLab/Bitbucket code fetching is explicit; ordinary source-text imports remain read-only. Native containers and encrypted loopback SSH use fake CLIs, with no inference quota. Official compatibility probes execute only version/help. Shared roles grant review access; phone pairing grants owner control. Critical-path metrics use observed time, not predictions.

Architecture and semantic-memory analysis are bounded static/deterministic tools, not complete runtime dependency discovery or unrestricted natural-language reasoning. Extensions are trusted full-authority server code. Remote workers must be provisioned explicitly. Code-host native queues and unsupported policy semantics require the provider UI. These are documented implementation boundaries, not silently simulated success.

Validation

Use fake agents for development. Never spend real provider quota, publish results, send external notifications, or mutate third-party accounts as a side effect of the test suite. Account-dependent features require explicit configured credentials for live acceptance testing; fixture coverage is recorded separately.

The first checkpoint passed 621 unit tests with three opt-in Docker cases skipped; those three native Docker cases passed separately. Its full browser suite passed 35/35. The second batch's unit run passed 688/688 executed checks (three optional Docker cases skipped). Focused browser acceptance also covers conventions, dependency discovery, deferred restart/receipt recovery, selective reruns, retention, context budgets, commit reversions and language-service references. The final full browser rerun passed 45/45 after the folder-picker race fix. The VS Code extension passed actual host acceptance on installed VS Code 1.141.0, and the packaged VSIX passed the same host acceptance after isolated installation, including delayed-response connection/disconnection regressions. No real provider quota, external notifications or third-party account mutations were used. The test runner limits unit concurrency to four files and browser concurrency to two because these suites launch real Git, server and browser processes.

The final implementation checkpoint passed 812 unit checks with six optional native-runtime checks skipped. Those five real Docker checks and the encrypted loopback SSH check passed separately. The full browser suite passed 64/64. The last filtered-task concurrency changes passed 31 focused unit checks and 2/2 browser flows after the main suite had started. Native acceptance includes fresh-home credential seeding with dummy credentials, denied-file/original-Git absence, read-only mounts, exact review-branch import and confirmed cancellation. The packaged VSIX passed actual installed VS Code host acceptance again. Typecheck, UI/worker builds, 68 accessibility renderings and local documentation links passed. Provider version/help probes used actual official binaries; no live inference, account mutation or notification delivery occurred.

After integrating the newer main composer feature, 19 existing browser and accessibility checks, four new Improve browser flows and two shared/policy security flows passed. Eleven prompt-improvement unit checks and all 14 server-reliability checks passed, including a delayed-turn lease/cancellation test that exposed and fixed an incorrect 400 response for concurrent run starts. A subsequent source review moved Improve out of the working checkout entirely so external edits can never be discarded by read-only cleanup. Final typecheck and UI/worker builds passed. The Improve menu adds two mobile theme audits, bringing the accessibility acceptance total to 70 renderings; both mobile screenshots were inspected for readable controls and overflow.

The post-merge full unit run passed 828 checks with six optional native-runtime cases skipped (already passed separately). After private-snapshot hardening, all 15 Improve checks and all 15 server-reliability checks passed again, including external source edits/commits, private cleanup, executable-configuration exclusion, snapshot bounds and early environment checks across both API prefixes. The four Improve browser flows passed with the isolated backend; the final menu-wrapping change also passed its mobile/profile regression and visual inspection. The final subprocess PATH fix passed 15 foundation/filesystem-policy unit checks and the policy browser flow. Actual malicious cwd/relative-bin executables were refused for inherited and overridden PATHs; explicit absolute fixture binaries remain usable. The exact-route regression passed again after adding malformed suffix/method checks across both API prefixes.

Result-first product experiences

The composer retains its outcome starters and now records an explicit task type on new runs. Expand Workflow advice from this repository to inspect check success, acceptance feedback, correction samples and supporting runs, then apply a workflow deliberately. Suggestions require three completed samples per workflow, retain failures in their denominator and do not infer task types from older prose. They describe history, not task difficulty or a predicted winner.

Running work has a compact progress card with dispatch pause and run priority. Auto teams also have a Who's doing what map: select a task to inspect its owner, paths, dependency blockers and open questions. A task priority applies at the next dispatch and cannot override dependencies, occupied members/paths, review reservations or budgets. Existing journaled dispatches remain pinned on resume. Standing-team task priorities remain controlled by their mission.

Finished results lead with Try this result, evidence, and commit-specific Accept result / Needs more work feedback. The preview waits for its allocated port before opening. Feedback neither publishes nor substitutes for standing-team approval. Project pages and Insights show historical acceptance, median elapsed time to a verified result, recorded correction time and merged runs. Unrated runs and missing correction records are explicit; missing corrections are not zero-minute samples. Acceptance refers to the latest recorded decision, which can belong to an earlier commit. The result screen flags that difference.

Show me what changed captures the running app beside an optional original URL at the same viewport. Snapshots use fresh browser profiles and can be downloaded; they are visual observations rather than automated proof. For a recorded scenario, the result instead also offers a replay and a step-by-step screenshot walkthrough beside the original replay.

Try two alternatives launches two ordinary runs from the same exact result commit with separate instructions and budgets. Each result has its own preview, check state and continuation link. No branch is chosen, merged or published automatically. If a comparison launch fails partway through, inspect recent runs before requesting another; successful children remain visible in their group.

Record a bug and prepare its regression test

1. Open a local HTTP app in Browser and choose Record a bug.
2. Reproduce the flow. Clicks, text input, single-select changes and Enter/Tab/Escape are supported. The recording follows same-origin document navigation. Shadow DOM, nested frames, file uploads, gestures and authenticated fixtures require adapting the exported test.
3. Stop recording, inspect/remove interactions, name the scenario and specify an expected element selector and visible text. Save the immutable scenario.
4. Replay original scenario checks that assertion in fresh Chrome and saves a screenshot walkthrough. Password/credential fields are excluded; review other recorded form values before saving. Replays can mutate the app's data.
5. Prepare verified fix attaches a generated Playwright regression test to a new pipeline draft. The agent is instructed to demonstrate failure before the fix and success afterward, adapting it to the repository's test setup. Review the draft and its check configuration before starting.
6. On the result, start its preview and Replay scenario on this result to compare observations. A replay never changes the run's independent check or proof verdict. Only the specified visible-text assertion is tested. The recorded branch head is informational: dev servers can serve an older build or uncommitted files, so a browser replay does not certify a Git tree.

Recordings are owner-only, stored privately under CODEFLOW_HOME/journeys, included by ordinary backups, and available from each project's Recorded scenarios library after restart. Export the generated test or delete an unused scenario and its evidence there. Limits: 100 scenarios per host, 30 interactions per scenario, 1,920px recording width, four retained replay receipts per scenario, 2.5 million base64 screenshot characters per receipt, 16 MiB per evidence file, one replay at a time, and the existing 45-second snapshot execution deadline. Uncaptured frames are omitted, never synthesized. Replay checks local app URLs, refuses code-flow's own listener ports and keeps document navigation on the selected origin. The existing snapshot network caveats also apply. Filesystem restrictions pause these operations; shared reviewers cannot access recordings.

Project pages now lead standing teams with a Project briefing showing up to three actionable opportunities. Ready drafts come first, followed by reported impact and recency. Cards expose users, benefit, risk, source quotes and the pinned source commit. Dismiss opportunity records a rejection through the existing team decision service, so subsequent discovery respects it. Schedules and standing teams remain explicitly activated by the owner.

Documentation library · Development guide