Skip to content

docs: plan single coven distribution#278

Merged
BunsDev merged 1 commit into
mainfrom
feat/release-metadata-api
Jul 1, 2026
Merged

docs: plan single coven distribution#278
BunsDev merged 1 commit into
mainfrom
feat/release-metadata-api

Conversation

@BunsDev

@BunsDev BunsDev commented Jun 30, 2026

Copy link
Copy Markdown
Member

Summary

  • document the path to make coven the single user-facing command for daemon, CLI/TUI, and Coven Code workflows
  • keep Coven Code as a managed adapter first instead of merging repositories before the boundary is stable
  • outline phases for Cave compatibility visibility, coven code, adapter capability reporting, and the later packaging decision

Verification

  • git diff --check

Documents the path for making coven the user-facing command for daemon, CLI, and Coven Code workflows while preserving the adapter boundary.

Verification: git diff --check.

Co-authored-by: Nova <nova@opencoven.ai>
@mintlify

mintlify Bot commented Jun 30, 2026

Copy link
Copy Markdown
Contributor

Preview deployment for your docs. Learn more about Mintlify Previews.

Project Status Preview Updated (UTC)
OpenCoven 🔴 Failed Jun 30, 2026, 10:02 AM

💡 Tip: Enable Workflows to automatically generate PRs for you.

@BunsDev BunsDev marked this pull request as ready for review July 1, 2026 06:14
Copilot AI review requested due to automatic review settings July 1, 2026 06:14

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR adds an implementation plan documenting how to converge on coven as the single user-facing command for the daemon, CLI/TUI, and Coven Code workflows, while keeping Coven Code as a managed adapter boundary until the contract stabilizes.

Changes:

  • Add a phased rollout plan covering compatibility floors/visibility, a coven code alias, capability reporting, and a later packaging decision.
  • Define expected Cave UX for compatibility warnings vs optional updates.
  • Outline verification steps for both Cave and Coven changes during rollout.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

1. **User-facing command stays `coven`.** Users should not need to remember whether a workflow belongs to `@opencoven/cli` or `coven-code`.
2. **Coven Code becomes an adapter first.** `coven code` should launch the code workflow through an adapter boundary before any repo/package merge.
3. **The daemon remains the source of runtime truth.** Cave and other clients keep handshaking through `/api/v1/health` and capability discovery.
4. **Release compatibility is explicit.** Cave should warn when installed `coven` or `coven-code` versions are below the app's minimum compatible version, and show ordinary update notices separately.

## Phase 1 — Compatibility and Release Visibility

**Outcome:** Cave can tell users when Cave itself, `coven`, or `coven-code` has an update, and it can distinguish ordinary updates from versions too old for the current Cave build.
Comment on lines +108 to +115
```json
{
"id": "coven-code",
"installed": true,
"version": "0.0.22",
"command": "coven code"
}
```
@BunsDev BunsDev merged commit 93ab611 into main Jul 1, 2026
14 of 15 checks passed
@BunsDev BunsDev deleted the feat/release-metadata-api branch July 2, 2026 06:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants