OpenVibeCoding/docs/ai-surfaces/index.html at 5de7f4d6a03d3796b8a7119127b4e20caa7b22ae · xiaojiou176-open/OpenVibeCoding · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>CortexPilot | AI, MCP, and API surfaces for the command tower</title>
    <meta
      name="description"
      content="Secondary technical surfaces for the CortexPilot command tower: advisory AI briefs, read-only MCP, frontend API entrypoints, and contract-facing types for Codex and Claude Code workflows."
    />
    <meta
      name="keywords"
      content="CortexPilot, AI engineering command tower, advisory AI brief, read-only MCP, frontend API client, workflow automation"
    />
    <link rel="canonical" href="https://xiaojiou176-open.github.io/CortexPilot-public/ai-surfaces/" />
    <meta property="og:title" content="CortexPilot | AI, MCP, and API surfaces for the command tower" />
    <meta
      property="og:description"
      content="Secondary technical surfaces for the CortexPilot command tower: advisory AI briefs, read-only MCP, and current API entrypoints."
    />
    <meta property="og:type" content="article" />
    <meta property="og:url" content="https://xiaojiou176-open.github.io/CortexPilot-public/ai-surfaces/" />
    <meta property="og:image" content="../assets/storefront/social-preview-1280x640.png" />
    <meta name="twitter:card" content="summary_large_image" />
    <meta name="twitter:title" content="CortexPilot | AI, MCP, and API surfaces for the command tower" />
    <meta
      name="twitter:description"
      content="Truthful command-tower map for advisory AI briefs, read-only MCP, and API entrypoints in CortexPilot."
    />
    <meta name="twitter:image" content="../assets/storefront/social-preview-1280x640.png" />
    <script type="application/ld+json">
      {
        "@context": "https://schema.org",
        "@type": "TechArticle",
        "headline": "CortexPilot AI, MCP, and API surfaces for the command tower",
        "url": "https://xiaojiou176-open.github.io/CortexPilot-public/ai-surfaces/",
        "description": "Truthful command-tower map for advisory AI briefs, read-only MCP, and current frontend API entrypoints."
      }
    </script>
  </head>
  <body>
    <main style="max-width:960px;margin:0 auto;padding:40px 20px;font:16px/1.7 system-ui,sans-serif;color:#17232c;">
      <p>
        <a href="../">Back to the public landing page</a>
        · <a href="../compatibility/">Compatibility matrix</a>
        · <a href="../ecosystem/">Ecosystem map</a>
        · <a href="../integrations/">Integration guide</a>
        · <a href="../builders/">Builder quickstart</a>
        · <a href="../skills/">Skills quickstart</a>
        · <a href="../mcp/">MCP quickstart</a>
        · <a href="../api/">API quickstart</a>
        · <a href="../use-cases/">Use cases</a>
      </p>

      <h1>AI, MCP, and API surfaces for the command tower</h1>
      <p>
        CortexPilot is first a command tower for AI engineering. This page is not the top-level product story; it is the
        secondary technical map that shows which AI-facing, MCP-facing, and API-facing surfaces already exist for
        <strong>Codex</strong> and <strong>Claude Code</strong> workflows.
      </p>
      <p>
        Current boundary: these surfaces are <strong>not</strong> a hosted operator product, the shipped MCP node remains
        <strong>read-only</strong>, and the frontend packages remain a <strong>thin client + contract + shared substrate</strong>
        layer instead of a full SDK platform.
      </p>

      <h2>1. Explain-only AI operator copilot</h2>
      <p>
        CortexPilot already exposes a bounded AI operator brief on the workflow path instead of an unbounded floating chat box.
        Today it shows up in three major places:
      </p>
      <ul>
        <li><strong>Flight Plan preview</strong>: a pre-run advisory brief before execution starts</li>
        <li><strong>Workflow copilot</strong>: a workflow-scoped explainer over queue posture, latest run context, and next action</li>
        <li><strong>Run / compare brief</strong>: a run-scoped explainer over deltas, proof, incident context, and next operator step</li>
      </ul>
      <p>
        Read the architecture baseline in
        <a href="https://github.com/xiaojiou176-open/CortexPilot-public/blob/main/docs/architecture/mcp-and-operator-copilot-v1.md">the MCP + operator copilot architecture note</a>.
      </p>

      <h2>2. Read-only MCP surface</h2>
      <p>
        CortexPilot ships a <strong>real read-only MCP node</strong> for control-plane reads. The current public contract is:
      </p>
      <ul>
        <li>inspect runs, workflow cases, queue posture, approvals, compare, proof, and incident summaries</li>
        <li>return structured JSON for agent/tool consumption</li>
        <li>do <strong>not</strong> mutate queue items, approvals, provider state, or workflow truth</li>
      </ul>
      <p>
        This keeps MCP useful for external inspection while staying honest about the current boundary.
      </p>
      <p>
        If you want the shortest MCP-specific map, go straight to the
        <a href="../mcp/">read-only MCP quickstart</a>.
      </p>

      <h2>3. Frontend API and contract entrypoints</h2>
      <p>
        CortexPilot also exposes a thin builder edge for frontend consumers that want the same routes and contracts the dashboard and desktop use today.
      </p>
      <ul>
        <li><a href="https://github.com/xiaojiou176-open/CortexPilot-public/blob/main/packages/frontend-api-client/README.md"><code>@cortexpilot/frontend-api-client</code></a>: thin JS/TS client helpers for runs, Workflow Cases, approvals, and command-tower reads</li>
        <li><a href="https://github.com/xiaojiou176-open/CortexPilot-public/blob/main/packages/frontend-api-contract/docs/README.md"><code>@cortexpilot/frontend-api-contract</code></a>: contract-facing route/query names, generated types, and the human-readable package guide</li>
        <li><a href="https://github.com/xiaojiou176-open/CortexPilot-public/blob/main/packages/frontend-shared/README.md"><code>@cortexpilot/frontend-shared</code></a>: shared copy, locale, and status-presentation substrate for dashboard and desktop</li>
      </ul>
      <p>
        For the machine-facing HTTP boundary, open
        <a href="https://github.com/xiaojiou176-open/CortexPilot-public/blob/main/docs/api/openapi.cortexpilot.json">the public OpenAPI document</a>.
      </p>
      <p>
        If you want the shortest API-oriented map, use the
        <a href="../api/">API and contract quickstart</a>.
      </p>

      <h2>4. What we can say truthfully</h2>
      <ul>
        <li><strong>Codex</strong>: CortexPilot is positioned for Codex workflows as an operator control plane, not as an official Codex product.</li>
        <li><strong>Claude Code</strong>: CortexPilot is positioned for Claude Code workflows as the same governed command-tower path, not as an Anthropic-managed surface.</li>
        <li><strong>MCP</strong>: the current protocol story is real, but it is <strong>read-only only</strong>.</li>
        <li><strong>API / builder layer</strong>: current packages are useful integration entrypoints, but they are <strong>not yet a full SDK platform</strong>.</li>
        <li><strong>Queue pilot groundwork</strong>: repo-owned HTTP queue preview/cancel plus a confirm-gated, default-off queue-only MCP pilot server can exist internally without changing the public “read-only MCP” contract.</li>
      </ul>

      <h2>4.5. Integration and skills adoption</h2>
      <p>
        If your real question is “How do I plug this into a coding-agent team workflow without making fake plugin claims?”, use the
        <a href="../compatibility/">compatibility matrix</a>, the
        <a href="../integrations/">integration guide</a> and the
        <a href="../skills/">skills quickstart</a>.
      </p>
      <ul>
        <li><strong>Compatibility matrix</strong>: the fastest “which ladder fits my stack?” answer across agents, skills, builders, proof-first cases, and MCP.</li>
        <li><strong>Integration guide</strong>: the truthful map for Codex, Claude Code, and OpenClaw usage.</li>
        <li><strong>Skills quickstart</strong>: repo-owned playbooks and adoption guidance for repeatable agent behavior.</li>
      </ul>

      <h2>5. What stays explicitly out of scope</h2>
      <ul>
        <li>no hosted operator login surface</li>
        <li>no write-capable MCP claim</li>
        <li>no claim that queue pilot groundwork means general agent-safe mutation is already live</li>
        <li>no official partnership implication with OpenAI or Anthropic</li>
        <li>no claim that the current packages replace the orchestration runtime</li>
      </ul>
    </main>
  </body>
</html>