Skip to content

feat: switch public shell to OpenVibeCoding #89

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
xiaojiou176 wants to merge 6 commits into from
Closed

feat: switch public shell to OpenVibeCoding #89

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
1b9cb25
feat: switch public shell to OpenVibeCoding
xiaojiou176 Apr 13, 2026
68f94c9
test: align proof room copy assertions
xiaojiou176 Apr 13, 2026
0569516
feat: productize planner desk and wake scheduling
xiaojiou176 Apr 13, 2026
b2ffafa
test: align role desk accessibility heading
xiaojiou176 Apr 13, 2026
372de0e
feat: promote planner controls and lock command deck shell
xiaojiou176 Apr 13, 2026
b6be3c5
test: align dashboard token expectations
xiaojiou176 Apr 13, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
81 changes: 49 additions & 32 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,21 +1,30 @@
# CortexPilot
# OpenVibeCoding

The command tower for AI engineering.
The open command tower for AI engineering.

Stop babysitting AI coding work. CortexPilot helps teams plan, delegate, track,
resume, and prove long-running engineering work across Codex and Claude Code
instead of juggling scattered chats, local scripts, and after-the-fact logs.
Stop babysitting AI coding work.

AI coding does not lack models. It lacks a command tower.

OpenVibeCoding is the public shell for the CortexPilot repo and runtime
compatibility layer. It helps teams plan / delegate / track / resume / prove
long-running engineering work across Codex and Claude Code instead of
juggling scattered chats, local scripts, and after-the-fact logs.

CortexPilot is a contract-first multi-agent orchestration repository.

The underlying repository, runtime, package, and compatibility names remain
`CortexPilot` where that internal surface is the truthful identifier.

The public story is intentionally narrower than the full monorepo:

- **See one proven workflow first**
- **Choose the right adoption path second**
- **Open MCP / API / builder / skills surfaces only after the real job is clear**

Current public boundary: CortexPilot is a repo-backed AI engineering command
tower, not a hosted product, and the shipped MCP surface remains **read-only**.
Current public boundary: OpenVibeCoding is a repo-backed public shell over the
CortexPilot runtime, not a hosted product, and the shipped MCP surface remains
**read-only**.

Current lane order is deliberate:

Expand All @@ -31,7 +40,14 @@ Current lane order is deliberate:

The shortest truthful answer today is:

> CortexPilot officially ships a public repo, a public Pages front door, a repo-local read-only MCP surface, a published PyPI package, a live Official MCP Registry entry, and a live ClawHub skill. The adoption-router skill is the secondary public lane. Local coding-agent starters and bundle examples remain companion/example materials, not the canonical public root. OpenHands/extensions and MCP.so external receipts exist, while hosted service, write-capable MCP, Docker distribution, and standalone npm releases remain deferred.
> OpenVibeCoding currently ships through the public CortexPilot repo, a public
> Pages front door, a repo-local read-only MCP surface, a published PyPI
> package, a live Official MCP Registry entry, and a live ClawHub skill. The
> adoption-router skill is the secondary public lane. Local coding-agent
> starters and bundle examples remain companion/example materials, not the
> canonical public root. OpenHands/extensions and MCP.so external receipts
> exist, while hosted service, write-capable MCP, Docker distribution, and
> standalone npm releases remain deferred.

Use these buckets:

Expand Down Expand Up @@ -99,11 +115,11 @@ release, new task templates, and storefront updates.
If you need contributor setup instead of product evaluation, jump to the
[30-minute onboarding guide](docs/runbooks/onboarding-30min.md).

## Why CortexPilot Exists
## Why OpenVibeCoding Exists

Most agent demos stop at "the model replied." CortexPilot is built for the next
question: **can we inspect what happened, review what changed, classify the
workflow case, and rerun it without guessing?**
Most agent demos stop at "the model replied." OpenVibeCoding is built for the
next question: **can we inspect what happened, review what changed, classify
the workflow case, and rerun it without guessing?**

The deeper product claim is straightforward:

Expand All @@ -119,7 +135,7 @@ The engineering philosophy underneath that loop is equally explicit:
- **Context Engineering**: keep the right material in the right head, and treat explicit handoff as a fallback rather than the default loop.
- **Harness Engineering**: move work through contracts, runtime bindings, approvals, and proof surfaces so the system can keep operating safely.

This repository combines:
The CortexPilot runtime underneath that public shell combines:

- **Command Tower**: one operator surface for governed AI work, live run visibility, queue posture, and L0-style oversight
- **Workflow Cases**: one stable operating record that ties request, verdict, proof, and linked runs together
Expand Down Expand Up @@ -189,7 +205,7 @@ If the first success path fails, go here next:

## The First Loop

The clearest way to understand CortexPilot is:
The clearest way to understand OpenVibeCoding is:

1. **PM**: describe the task and acceptance target
2. **Workflow Case**: confirm the case identity, queue state, and operating verdict
Expand All @@ -214,9 +230,10 @@ repository should be judged on.
`Switchyard /v1/runtime/invoke` for intake/operator-style chat paths, but
MCP tool execution still needs a tool-capable provider path and therefore
fails closed instead of pretending Switchyard already has tool parity
- CortexPilot is still **not** a hosted operator service; `cortexpilot.ai`
should be treated as a marketing/holding domain until the public contract,
support boundary, and live surface materially change
- the CortexPilot runtime under OpenVibeCoding is still **not** a hosted
operator service; `cortexpilot.ai` should be treated as a marketing/holding
domain until the public contract, support boundary, and live surface
materially change

## Public CI Safety Model

Expand Down Expand Up @@ -322,7 +339,7 @@ release-proven until they have their own healthy proof and benchmark artifacts.

Use these names as ecosystem anchors, not as co-brands or partnership claims.

- **Codex**: primary workflow audience; CortexPilot is built for governed
- **Codex**: primary workflow audience; OpenVibeCoding is built for governed
Codex-style coding runs that need cases, approvals, and replayable proof.
- **Claude Code**: primary workflow audience alongside Codex; the same
Command Tower / Workflow Case / Proof & Replay spine applies.
Expand All @@ -340,7 +357,7 @@ Use these names as ecosystem anchors, not as co-brands or partnership claims.
## Official Ecosystem Anchors

When a team asks "what is real on their side?", start from the native surfaces
below before you explain where CortexPilot fits:
below before you explain where OpenVibeCoding fits:

- **Codex**:
- repo: [openai/codex](https://github.com/openai/codex)
Expand All @@ -359,21 +376,21 @@ below before you explain where CortexPilot fits:
- skills docs: [docs.openclaw.ai/tools/skills](https://docs.openclaw.ai/tools/skills)
- registry/catalog: [openclaw/clawhub](https://github.com/openclaw/clawhub)

These anchors matter because CortexPilot should fit around the real ecosystem
These anchors matter because OpenVibeCoding should fit around the real ecosystem
surfaces that already exist:

- **Codex**: Codex now has real plugin surfaces of its own, including local
marketplace installs and a curated official directory. CortexPilot should sit
marketplace installs and a curated official directory. OpenVibeCoding should sit
around Codex workflows with command tower, proof, replay, read-only MCP, and
repo-owned skills or local bundle examples until a real published listing
exists.
- **Claude Code**: Claude Code's current native surfaces include plugins, MCP,
hooks, subagents, and project configuration. CortexPilot should wrap those
hooks, subagents, and project configuration. OpenVibeCoding should wrap those
governed workflows with command tower, proof, replay, read-only MCP, and
repo-owned starter kits rather than pretending a published CortexPilot
repo-owned starter kits rather than pretending a published OpenVibeCoding
marketplace listing already exists.
- **OpenClaw**: adjacent integration layer with real skills and plugin/catalog
surfaces on its side, while CortexPilot stays on the review/proof/read-only
surfaces on its side, while OpenVibeCoding stays on the review/proof/read-only
integration side unless a mapped native path is explicitly shipped and
tested.

Expand All @@ -387,13 +404,13 @@ The strongest public loop is now:
3. Reuse the Workflow Case as a **share-ready recap asset** instead of keeping
it trapped inside a single operator page.

That turns CortexPilot from “a repo you can run” into “a repo you can show,
That turns OpenVibeCoding from “a repo you can run” into “a repo you can show,
review, and hand off.”

## Builder Entry Points

These are the current public-facing entry points for teams that want to build
around CortexPilot without pretending a full SDK platform already exists:
around OpenVibeCoding without pretending a full SDK platform already exists:

- [packages/frontend-api-client/README.md](packages/frontend-api-client/README.md): thin JavaScript/TypeScript client entry points for dashboard, desktop, and web surfaces, including the repo-owned `createControlPlaneStarter(...)` bootstrap path for overview + agents + contracts + role-config integration.
- [packages/frontend-api-contract/docs/README.md](packages/frontend-api-contract/docs/README.md): human-readable contract package guide for generated frontend-safe route/query/type imports.
Expand All @@ -413,16 +430,16 @@ If your team needs starter assets instead of only wording, open:

## Shortest Cross-Ecosystem Adoption Order

If you are integrating CortexPilot into a coding-agent workflow, the shortest
If you are integrating OpenVibeCoding into a coding-agent workflow, the shortest
truthful order is:

1. Confirm the native ecosystem surface first:
- Codex CLI / IDE
- Claude Code overview / MCP
- OpenClaw repo / skills / ClawHub
2. Use the public [compatibility matrix](https://xiaojiou176-open.github.io/CortexPilot-public/compatibility/)
to choose the right CortexPilot entrypoint.
3. Pick the first CortexPilot lane based on the job:
to choose the right OpenVibeCoding entrypoint.
3. Pick the first OpenVibeCoding lane based on the job:
- [read-only MCP](https://xiaojiou176-open.github.io/CortexPilot-public/mcp/)
for protocol inspection
- [skills quickstart](https://xiaojiou176-open.github.io/CortexPilot-public/skills/)
Expand All @@ -445,7 +462,7 @@ truthful order is:

## Best Fit

CortexPilot is a strong fit if you are building or evaluating:
OpenVibeCoding is a strong fit if you are building or evaluating:

- agent workflows that need **reviewable evidence**
- orchestration systems that need **replay / re-exec**
Expand All @@ -454,7 +471,7 @@ CortexPilot is a strong fit if you are building or evaluating:

## Not A Fit

CortexPilot is not the right choice if you want:
OpenVibeCoding is not the right choice if you want:

- a polished hosted SaaS product
- write-capable agent control-plane mutations through MCP today
Expand Down Expand Up @@ -488,7 +505,7 @@ The current stage freeze keeps two high-risk directions explicitly constrained:
- **Hosted operator surface** remains **No-Go**.
- `cortexpilot.ai` is still a weak marketing/holding domain, not a production
front door.
- The current public contract still describes CortexPilot as source code plus
- The current public contract still describes OpenVibeCoding as source code plus
operator/demo surfaces, not as a hosted service.
- Reopen hosted only if the public boundary, support contract, privacy/security
wording, and live front door materially change together.
Expand Down
6 changes: 6 additions & 0 deletions apps/dashboard/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -42,6 +42,12 @@ repository is already a finished consumer product.

- PM workspace: registry-driven task-pack selection plus `execution_plan_report`
preview before execution starts.
- Planner desk: a first-class planner-facing triage route that pulls
`planning_wave_plan`, `planning_worker_prompt_contracts`,
`planning_unblock_tasks`, and `completion_governance_report` into one
planning control desk, now with inline queue / dispatch controls so planners
can act on the next contract instead of only reading artifacts and clicking
away to other desks.
- Agents: the first-screen role catalog now also hosts a repo-owned role
configuration desk for previewing and saving future compiled defaults
(`system_prompt_ref`, bundle refs, and role-level runtime binding) while
Expand Down
Loading
Loading