Release v0.6.6 from devel

.github/workflows/ci.yml

@@ -2,7 +2,7 @@ name: CI
 
 on:
   pull_request:
-    branches: [release]
+    branches: [devel, release]
     types: [opened, synchronize, reopened, ready_for_review, edited]
 
 permissions:

.github/workflows/release.yml

@@ -18,7 +18,7 @@ concurrency:
 jobs:
   release:
     name: Publish from release and open promotion PR
-    if: github.event_name == 'push' || github.event.pull_request.merged == true
+    if: github.event_name == 'push' || (github.event.pull_request.merged == true && github.event.pull_request.head.ref == 'devel' && github.event.pull_request.head.repo.full_name == github.repository)
     runs-on: ubuntu-latest
     timeout-minutes: 25
     permissions:
@@ -37,7 +37,7 @@ jobs:
           cache: npm
       - name: Install pipeline dependencies
         run: npm ci --ignore-scripts
-      - name: Prepare version, publish package, and promote through a PR
+      - name: Publish, prepare main PR, and synchronize devel
         env:
           GH_TOKEN: ${{ github.token }}
         run: node scripts/release-pipeline.mjs

AGENTS.md

@@ -4,7 +4,10 @@ Use English for all user-facing prompts, UI labels, errors, generated bot messag
 
 Never push commits directly to `main` or modify its files through GitHub APIs.
 All changes reach `main` by merging a PR from `release`. Feature PRs target
-`release`; version and post-publication README commits belong on `release`.
+`devel`. Only a reviewed `devel` → `release` PR starts automatic publication.
+Version and post-publication README commits belong on `release`; after a stable
+publication, automation merges that published head back into `devel` without a
+PR or force push. Never reset development work to match release.
 
 ## Project context
 
@@ -24,11 +27,11 @@ steps, project setup, headless operation, and removal.
 | --- | --- | --- |
 | [docs/architecture.md](docs/architecture.md) | Component responsibilities, a short issue-to-PR overview, configuration ownership, scheduler ownership, and shared state. | Start here to understand how the system is divided before locating implementation code. |
 | [docs/bot-workflow.md](docs/bot-workflow.md) | Eight Mermaid diagrams and detailed implementation notes: startup and polling; discovery and routing; task phases; sessions and questions; media helpers; verification and publication; feedback, merging, and tab closure; status, retries, and recovery. Includes links to the source for each area. | Use for exact execution order, state transitions, checkpoint behavior, failure paths, and tracing a bot task from issue to merged PR. |
-| [docs/configuration.md](docs/configuration.md) | The standard `.opencode/automation.json` format, defaults, setup flags, configuration tracking across Git branches, authors, triggers, checks, base branches, model capabilities, media helpers, custom prompts, signatures, and auto-merge settings. | Use when adding or changing user-facing configuration, defaults, or setup examples. |
-| [docs/runtime.md](docs/runtime.md) | User-visible behavior while the bot runs: GitHub questions and permission replies, branch selection, media inputs, prompt loading, follow-up comments, session tabs, and routine management commands. | Use when changing issue conversations, session continuation, runtime tools, or TUI behavior. |
+| [docs/configuration.md](docs/configuration.md) | The standard `.opencode/automation.json` format, defaults, setup flags, configuration tracking across Git branches, repository file approvals, authors, triggers, checks, base branches, model capabilities, media helpers, custom prompts, signatures, and auto-merge settings. | Use when adding or changing user-facing configuration, defaults, or setup examples. |
+| [docs/runtime.md](docs/runtime.md) | User-visible behavior while the bot runs: GitHub questions and permission replies, branch selection, media inputs, prompt loading, follow-up comments, session tabs, runtime sidebar/status freshness, host repository inventory and discovery, local task closure, cancelling rounds while retaining tracking, and routine management commands. | Use when changing issue conversations, session continuation, runtime tools, or TUI behavior. |
 | [docs/advanced.md](docs/advanced.md) | Separate scheduler/dispatcher setup, multiple repositories, custom RPC jobs, full options, timeouts, management and retry commands, persistence, reconciliation, locks, and known limits. | Use for low-level configuration, operational troubleshooting, recovery, or ownership/concurrency changes. |
 | [docs/installation.md](docs/installation.md) | Loader registration, config-directory precedence, prerequisites, source installation, project-local installation, upgrade conflicts, testing on another machine, and migration limits. | Use when working on packaging, installers, registration, upgrades, or deployment troubleshooting. |
-| [docs/releases.md](docs/releases.md) | Feature-to-release PR checks, automatic patch versions, manual npm version/tag releases, exact changelog notes, publication recovery, README commits on release, and promotion PRs into protected main. | Use for CI triggers, versioning, packaging, GitHub Release publication, branch permissions, or recovery after a failed release. |
+| [docs/releases.md](docs/releases.md) | Feature-to-devel and devel-to-release PR checks, automatic patch versions, manual npm version/tag releases, exact changelog notes, publication recovery, README commits on release, automatic release-to-devel synchronization, and promotion PRs into protected main. | Use for CI triggers, versioning, packaging, GitHub Release publication, branch permissions, or recovery after a failed release. |
 
 For common investigations:
 
@@ -40,6 +43,10 @@ For common investigations:
   and the configuration reference's automatic-merge rules.
 - **Why did a session tab open or close?** Read the runtime tab sections and
   workflow section 7.
+- **Which folders are configured, running, paused, or missing?** Read the runtime
+  repository inventory section and advanced monitoring notes. `list` and `/bot`
+  → **Repositories** use timestamped host snapshots; do not activate owners to
+  inspect them. Discovery is an explicit registration operation.
 - **Why is polling inactive or duplicated?** Read architecture ownership,
   workflow section 1, and installation registration details.
 
@@ -55,33 +62,66 @@ the installation block without making remote writes. Keep its markers intact.
   and GitHub plugin entrypoints. `src/easy.ts` resolves standard project settings;
   `src/config.ts` defines the configuration schemas and route matching.
 - `src/dispatcher.ts` owns discovery, the durable task lifecycle, questions,
-  feedback rounds, publication coordination, retries, and merge polling.
+  feedback rounds, publication coordination, retries, durable task closure, round cancellation/resumption, and merge polling.
   `src/scheduler.ts` owns interval jobs; `src/state.ts` owns persistence and locks.
 - `src/executor.ts` owns analysis, base selection, worktrees, session execution,
   verification, and pushing. `src/analysis.ts` and `src/branch.ts` validate model
-  decisions. `src/github.ts` implements GitHub calls; `src/approval.ts` evaluates
+  decisions. `src/pr-description.ts` extracts final public reports and renders and
+  reconciles managed PR descriptions. `src/github.ts` implements GitHub calls; `src/approval.ts` evaluates
   approval candidates.
 - `src/runtime.ts`, `src/worker.ts`, and `src/bridge.ts` implement worker hooks,
   runtime installation, and communication with the owner. `src/prompt.ts` loads
   instructions; `prompts/bot.md` contains the bundled bot instructions.
+  `src/repository-permissions.ts` checks canonical path boundaries for opt-in
+  repository file approvals; `src/runtime.ts` applies them only to bot sessions.
 - `src/tui.ts`, `src/ui.ts`, and `src/activity.ts` implement terminal integration
-  and task activity. `src/rpc.ts` defines RPC contracts; `src/manage.ts` exposes
+  and task activity. `src/sidebar.ts` renders the runtime panel;
+  `src/runtime-panel.ts` owns polling, freshness and presentation;
+  `src/monitor.ts` defines read-only monitoring schemas. `src/rpc.ts` defines RPC contracts; `src/manage.ts` exposes
   management operations.
+- `src/repositories.ts` owns host registry registration, explicit discovery and
+  component snapshot files; `src/repository-report.ts` defines inventory schemas
+  and shared CLI/TUI formatting. Neither inventory reader starts bot work.
 - `src/setup.ts`, `src/wizard.ts`, `src/install.ts`, and `scripts/` cover setup and
   installation. `examples/` contains configuration examples; `test/` contains
   automated tests. `package.json` defines build and validation commands.
 
-## Keeping documentation accurate
+## Keeping documentation accurate — required for every change
 
-Treat the implementation as the source of truth for current behavior. If code
-and documentation disagree, inspect the relevant code and tests and make the
-discrepancy explicit rather than assuming the documented behavior is implemented.
-When changing behavior, update the relevant reference page and any affected
-workflow diagrams. Keep the architecture page concise; put detailed execution
-paths in `docs/bot-workflow.md` and user-facing runtime guidance in `docs/runtime.md`.
+Documentation is part of the implementation, not a later cleanup task. **If a code
+change affects anything already described, update that description and every
+affected diagram in the same change and PR.** A change is not complete while its
+code and documentation disagree. Do not defer documentation to a later release,
+follow-up issue, or another agent.
 
-Validate changed Mermaid diagrams with a Mermaid parser when available; checking
-Markdown fences alone does not validate diagram syntax. Avoid literal semicolons
-in sequence-diagram message labels because they can be parsed as statement
-separators. For documentation-only changes, check links and formatting; application
-tests are not needed unless executable behavior also changes.
+For every code, configuration, CLI/RPC, prompt, or workflow change:
+
+1. Read the affected reference pages and compare their claims with the source and
+   relevant tests. Use the documentation map above to find all entry points.
+2. Update affected behavior, defaults, commands, examples, prerequisites, limits,
+   failure/retry paths, and recovery instructions. Check README and cross-linked
+   pages as well as the primary reference; fixing only one mention is insufficient.
+3. For automation changes, review all eight sections of `docs/bot-workflow.md`
+   for impact and update every affected Mermaid diagram and its surrounding text.
+   Show actual ordering, phase/status transitions, durable checkpoints, questions,
+   verification/publication gates, and restart paths. Do not draw desired behavior
+   as if it were implemented. Keep architecture concise and detailed paths in the
+   workflow/runtime references.
+4. Validate modified Mermaid with a parser, and check local links, headings,
+   examples and Markdown formatting. Fences alone do not prove valid diagrams.
+   Avoid literal semicolons in sequence-diagram messages. Report any validation
+   that could not be run; do not claim it passed.
+5. Before finishing, review the complete diff for code/documentation agreement.
+   In the PR description, identify the documentation updated, or state why the
+   change has no documented or user-visible behavior impact. Add accurate
+   `Unreleased` notes for changes that enter the next release.
+
+Treat implementation and verified tests as evidence of current behavior. If an
+existing discrepancy is discovered, correct the affected documentation within the
+authorized scope and make any remaining mismatch explicit. Distinguish model
+instructions from enforced runtime behavior, and branch/unreleased features from
+features already present in a published package. Do not change an unrelated
+runtime behavior merely to make an old description true.
+
+For documentation-only changes, check links, formatting and diagram syntax;
+application tests are not needed unless executable behavior also changes.

CHANGELOG.md

@@ -1,13 +1,97 @@
 # Changelog
 
 Release descriptions come from the exact version section committed with the tag.
-Add feature changes under `Unreleased`; after a PR merges into `release`, automation
+Add feature changes under `Unreleased`; after a `devel` PR merges into `release`, automation
 moves them into the new patch version's section. For a manual release, prepare
 and commit the exact version section before creating its tag. Prerelease headings
 include the full version, for example `## 0.7.0-beta.1`.
 
 ## Unreleased
 
+### Documentation
+
+- Align all eight bot workflow diagrams and runtime/recovery references with the
+  implementation, including owner lifecycle, feedback queuing, session recovery,
+  verification gates, merge polling and TUI commands.
+- Require documentation and affected diagrams to be updated with each relevant
+  implementation change in repository and bundled bot instructions.
+
+### Fixed
+
+- Restore compatibility with OpenCode 2.0.6: update the pinned SDKs, discover
+  services through `/api/info`, refresh owner activity with `session.update`,
+  and interrupt sessions with `resume: false`. Replace the removed headless
+  activation command with location-scoped `plugin.list` and document validation.
+
+- Honor formal approvals for the exact verified PR commit even when publication
+  or description recovery finishes later. Retain review revocation, authorization,
+  and merge-readiness checks; keep timestamp gating for unbound merge comments.
+
+- Retry PR head propagation after a successful push when the remote branch still
+  matches the verified commit. Preserve a durable push checkpoint across restarts,
+  avoid repeating acknowledged pushes, and distinguish closed PRs from changed
+  branches while preserving manual description edits.
+
+- Keep repository inventory RPC responses valid JSON when an owner has no runtime
+  snapshots. Isolate setup-test registries so validation never adds fixture
+  repositories to the operator's inventory.
+
+- Use the successful session's final completion report as the PR description instead
+  of its initial acknowledgement. Persist reports across restarts, retain the
+  original summary plus the latest follow-up, distinguish dispatcher checks from
+  agent-reported tests, and preserve manual notes outside the managed section.
+
+- Reconcile timed-out or interrupted sessions completed manually after a blocked
+  task or service restart. Verify and publish through the dispatcher, then process
+  queued issue feedback on the same branch and PR, including legacy checkpoints.
+
+### Added
+
+- Per-repository `autoApproveRepositoryFiles` configuration, an opt-in setup
+  prompt, and `init --auto-approve-repository-files`. Bot sessions and native
+  workers can automatically access files in the repository and assigned worktree
+  across rounds/restarts, without global permission changes. Explicit denials,
+  pending questions, media-helper limits, and shell permissions remain unchanged.
+
+- Cancel a single bot round while retaining issue/PR tracking, with durable stop
+  recovery, preserved draft worktrees and fresh worktrees for later feedback.
+  Resume tracking a locally closed task without replaying its abandoned round
+  or old comments. Expose both actions in `/bot` and the CLI; show historical
+  errors only in details after closing or cancelling.
+
+- List configured repositories across the host with `opencode2-automation list`
+  (`--json` for scripts) and `/bot` → **Repositories**. Show owner/checkout paths,
+  base branches, timestamped dispatcher/scheduler status and concrete issue
+  failures without activating other bots. Register projects during init/startup;
+  import older inactive standard configurations with `list --discover <root>`.
+  Preserve missing entries and explicitly mark stopped, stale or unavailable data.
+
+- Manage tasks directly from `/bot`: inspect details, open sessions, close idle
+  tabs, restart workflows, or stop sessions and durably end tracking without
+  deleting work. Preserve closed tasks as history and skip rediscovery, feedback,
+  runtime hooks and publication after closure, including missing issue/PR cases.
+- Identify blocked, failed and closing issue keys and errors in the runtime
+  sidebar instead of showing only an anonymous attention counter.
+
+- Add a live BOT RUNTIME sidebar and `/botstatus` report with dispatcher operations,
+  scheduler scans/retries, queue counts and selected-task details. Keep stale and
+  unavailable readings explicit; monitor through read-only owner-scoped RPC.
+- Validate native sidebar rendering, reactive updates and narrow layouts as part
+  of the standard check command using pinned TUI/Bun development dependencies.
+
+- `/restartworkflow` and the matching CLI/RPC command resume a stopped task from
+  its saved stage, preserving worktrees, sessions, PRs, and feedback. Checkpoint
+  continuation requests across restarts without bypassing checks or permissions.
+
+### Changed
+
+- Collect feature PRs on `devel` without publishing a release. Run CI on PRs to
+  `devel` and `release`, and publish automatic patches only after a same-repository
+  `devel` to `release` PR is merged.
+- After stable publication and README update, automatically merge the published
+  release head into `devel` without a synchronization PR. Preserve new development
+  commits, retry concurrent updates, and fail safely on conflicts or denied pushes.
+
 ## 0.6.5
 
 ### Fixed
@@ -44,7 +128,7 @@ include the full version, for example `## 0.7.0-beta.1`.
 
 - Run full CI when feature PRs target `release`, including new commits to open PRs.
   Ordinary feature pushes no longer run CI or build packages.
-- Publish an automatic patch after a PR merges into `release`, and support manual
+- Publish an automatic patch after a `devel` PR merges into `release`, and support manual
   version tags on that branch without a second version bump.
 - Recover interrupted publication without moving tags or republishing completed
   packages. Commit README on `release` before opening or updating its PR to `main`.
@@ -74,4 +158,4 @@ include the full version, for example `## 0.7.0-beta.1`.
 - Add detailed bot workflow diagrams and a documentation map in `AGENTS.md`.
 - Expand bundled bot instructions for planning, delegation, verification, and
   handing publication back to the dispatcher.
-- Add the README banner showing an OpenCode2 agent executing a task.
+- Add the README banner showing an OpenCode2 agent executing a task.