Skip to content

feat(SUP-3466): add control-plane human/agent parity - #101

Closed
levineam wants to merge 3 commits into
mainfrom
SUP-3466/human-agent-parity
Closed

feat(SUP-3466): add control-plane human/agent parity#101
levineam wants to merge 3 commits into
mainfrom
SUP-3466/human-agent-parity

Conversation

@levineam

@levineam levineam commented Jul 17, 2026

Copy link
Copy Markdown
Owner

Summary

  • expose the authenticated control-plane service through the human CLI and agent-context MCP
  • add Codex runtime, minimal profile, packaging, and compatibility declarations
  • cover parity, authorization, runtime/doctor, module, and CLI smoke paths

Verification

  • npm --prefix modules/jarvos-agent-context test
  • npm --prefix modules/jarvos-runtime-kit test
  • node --test tests/doctor-checks-test.js
  • node tests/modules-smoke-test.js
  • node tests/cli-smoke-test.js

Related: SUP-3466

Summary by CodeRabbit

  • New Features

    • Added an authenticated control plane for managing approvals, requests, policies, conflicts, evidence, and lifecycle actions.
    • Added the jarvos-manager command for human access.
    • Added the jarvos_control_plane agent tool with support for authenticated operations.
    • Added durable state storage with configurable location and secure updates.
  • Bug Fixes

    • Added a doctor health check to detect control-plane compatibility and configuration issues.
  • Documentation

    • Documented human and agent access, authentication, supported operations, and state storage.

@coderabbitai

coderabbitai Bot commented Jul 17, 2026

Copy link
Copy Markdown

Review Change Stack

Warning

Review limit reached

@levineam, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 39 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: aff87151-aefa-4be7-844c-b767ad031344

📥 Commits

Reviewing files that changed from the base of the PR and between ed03605 and ec5e4fe.

📒 Files selected for processing (13)
  • lib/jarvos-cli.js
  • modules/jarvos-agent-context/package.json
  • modules/jarvos-agent-context/scripts/jarvos-mcp.js
  • modules/jarvos-agent-context/src/index.js
  • modules/jarvos-agent-context/test/agent-context.test.js
  • modules/jarvos-control-plane/README.md
  • modules/jarvos-control-plane/package.json
  • modules/jarvos-control-plane/scripts/jarvos-manager.js
  • modules/jarvos-runtime-kit/test/runtime-kit.test.js
  • package.json
  • profiles/minimal.json
  • runtimes/codex/README.md
  • runtimes/codex/adapter.json
📝 Walkthrough

Walkthrough

Adds an authenticated, persisted control-plane service with human CLI and MCP access, Codex runtime declarations, minimal-profile requirements, package inclusion, documentation, integration tests, and a doctor compatibility check.

Changes

Control Plane Integration

Layer / File(s) Summary
Control-plane service and CLI
modules/jarvos-control-plane/scripts/jarvos-manager.js, modules/jarvos-control-plane/package.json, modules/jarvos-control-plane/README.md
Adds authenticated stateful request operations, atomic JSON persistence, status transitions, evidence recording, CLI parsing, and the jarvos-manager executable.
Agent context and MCP access
modules/jarvos-agent-context/src/index.js, modules/jarvos-agent-context/scripts/jarvos-mcp.js, modules/jarvos-agent-context/test/agent-context.test.js
Exports control-plane execution, registers the authenticated jarvos_control_plane tool, sanitizes service options, and tests request approval flows.
Runtime declarations and distribution
runtimes/codex/adapter.json, runtimes/codex/README.md, profiles/minimal.json, package.json, modules/jarvos-runtime-kit/test/runtime-kit.test.js
Declares the control-plane module and required tool, updates profile requirements and documentation, includes runtime assets in packages, and validates the manifest.
Compatibility doctor check
lib/jarvos-cli.js
Adds and registers a doctor check for control-plane module and runtime compatibility, and exports the check helper.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Agent
  participant MCP
  participant Context
  participant Manager
  participant State
  Agent->>MCP: jarvos_control_plane(operation, authToken)
  MCP->>Context: controlPlane(operation, sanitized input)
  Context->>Manager: execute(operation, input)
  Manager->>State: authenticate and read or write state
  State-->>Manager: persisted control-plane state
  Manager-->>Context: structured result
  Context-->>MCP: operation result
  MCP-->>Agent: JSON text response
Loading

Possibly related PRs

  • levineam/jarvOS#30: Introduced the Codex and agent-context MCP server wiring extended by this change.
  • levineam/jarvOS#32: Introduced the runtime adapter validation extended with control-plane declarations.
🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly summarizes the main change: adding control-plane parity between human CLI and agent MCP access.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch SUP-3466/human-agent-parity

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 20dd9d3b0d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread modules/jarvos-agent-context/src/index.js
Comment thread lib/jarvos-cli.js

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 11c61ddd49

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread modules/jarvos-agent-context/src/index.js
Comment thread modules/jarvos-control-plane/scripts/jarvos-manager.js
@levineam

Copy link
Copy Markdown
Owner Author

Changes requested — independent review round 1 of the parity surface: 4 P1s + 1 structural

Independent engine (gpt-5.6-terra, effort high) + orchestrator verification by direct code read. All findings confirmed in modules/jarvos-control-plane/scripts/jarvos-manager.js. Do not merge.

The structural finding (root cause of all four P1s)

jarvos-manager.js never calls createReconciler, createPolicyEngine, or the locked fenced store. It implements a parallel request/approval state machine in its own unlocked JSON file — a second command path with its own lifecycle, its own "policy," and its own evidence log. This is precisely what the plan prohibits: KTD10 ("new requests from any surface re-enter the common command arbiter"; "neither notifications nor harness tools may become alternate execution paths") and KTD13 ("adapters… cannot add authority, read the store directly, or invent lifecycle behavior"). The core machinery hardened over two review rounds (SUP-3464/SUP-3477 — leases, fences, action-key dedupe, WAL) is entirely bypassed by the public entry surface.

Required shape: the CLI/MCP surface must be a thin authenticated adapter that constructs a createRequest envelope and submits it to the core reconciler/policy/store, rendering the policy-filtered result. No surface-owned request state.

P1 findings (all fall out of the structure above)

  1. Caller mints approved mutationsexplainPolicy() returns allow whenever the caller passes requireApproval: false; request() then records status: 'approved'. Caller input literally decides policy outcome (R20/R25 violation).
  2. Any token holder approves anythingexecute('approve') flips any non-terminal request to approved after the shared-token check: no distinct approver, no capability check, no binding to command/generation/fence (KTD15 requires command-bound, expiring, non-inheritable approvals).
  3. Raw cross-principal disclosurelist returns load().requests verbatim; inspect/conflict-detail/evidence likewise. No principal/capability/sensitivity filtering (R24/R40).
  4. Unlocked read-modify-write racesload() … save(state) with no lock: two concurrent processes both pass the conflict check and both get approved requests for the same resource/mutation; last writer wins. The core store's locking exists precisely for this.

P2

  1. Replay/idempotency/stale-generation inputs are accepted (random id per call, no action key, no generation comparison) — R13/R35.
  2. Packaging: root package.json publishes only runtimes/codex/adapter.json while profiles/minimal.json requires codex-runtime and the doctor reports readiness from static JSON — an npm-installed minimal profile advertises a runtime it cannot set up (AE9).

Disposition

SUP-3466 returns to in_progress. Fix is a rewrite of the surface to delegate to the core (likely smaller than the current file), not point patches. Each P1 needs a test that fails against the current branch: caller-supplied requireApproval:false must be rejected or ignored; approval must require a distinct authorized approver bound to the exact command; list under a second principal must not see the first principal's requests; two concurrent requests for the same resource must yield exactly one non-conflict result. The v1 freeze cannot happen while the public surface bypasses the arbiter. Independent review re-runs on the revision until clean.

Co-authored-by: Paperclip <noreply@paperclip.ing>
@levineam

Copy link
Copy Markdown
Owner Author

Remediated the two Codex findings in ec5e4fe:

  • Package boundary: @jarvos/agent-context now depends on and imports the exported @jarvos/control-plane/manager entrypoint; package-shaped regression coverage verifies MCP startup.
  • Secret hygiene: service construction options are excluded from persisted and returned request data; regression coverage asserts the token is absent.

Verification: agent-context 23/23, control-plane 28/28, smoke 65/65, packaging dry run, and diff check all pass.

@codex review
@coderabbitai full review

@coderabbitai

coderabbitai Bot commented Jul 17, 2026

Copy link
Copy Markdown

@levineam Understood. I’ll perform a full re-review of #101, including the package-boundary and secret-hygiene remediations as well as the control-plane parity surface.

✅ Action performed

Full review finished.


Your plan includes PR reviews subject to rate limits. More reviews will be available in 40 minutes.

@levineam

Copy link
Copy Markdown
Owner Author

Closing without merge: independent review found the public surface is an alternate unlocked state machine. SUP-3466 is blocked on SUP-3478, which will add the required authenticated core application service; the adapter will be rewritten against that contract in a clean follow-up PR.

@levineam levineam closed this Jul 17, 2026

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ec5e4fe83c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

function main() {
const { operation, input } = parseCli(process.argv.slice(2));
if (operation === 'help' || input.help) { process.stdout.write(`${usage()}\n`); return; }
if (input.input) Object.assign(input, JSON.parse(input.input));

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P1 Badge Remove raw --input before merging request payloads

When a caller puts authToken or token in the JSON passed to --input to submit a full request payload, this merge leaves the original JSON string on input.input. request() only redacts authToken, token, and service, then spreads the remaining fields into the request, so that raw JSON containing the control-plane token is returned and written to the state file. Delete input.input before calling execute, or whitelist the fields that can become request data.

Useful? React with 👍 / 👎.

if (conflict) return { ok: false, status: 'conflict', conflict: { requestId: conflict.id, status: conflict.status, reason: 'an active request owns this resource and mutation class' } };
state.requests.push(draft);
addEvidence(state, draft.id, draft.status, 'request accepted by shared application service');
save(state);

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P2 Badge Serialize request state before saving snapshots

When two separate CLI/MCP callers create requests against the same state path at the same time, each invocation reads the whole JSON state, mutates its private copy, and this save replaces the file without a lock. The later rename can drop the earlier request and evidence even for independent resources; wrap the read-modify-write in the existing file-store lock or another per-state lock.

Useful? React with 👍 / 👎.

const DEFAULT_SESSION_THREAD_LOCK_TIMEOUT_MS = 30000;

function loadControlPlaneManager() {
return require('@jarvos/control-plane/manager');

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P2 Badge Keep control-plane resolvable for checkout MCP usage

In the documented Codex setup that runs modules/jarvos-agent-context/scripts/jarvos-mcp.js directly from a repo checkout, @jarvos/control-plane is not installed in any node_modules because the repo has no workspace/root dependency for the nested packages. This package-only require makes jarvos_control_plane fail with MODULE_NOT_FOUND on first use even though MCP startup can pass; add a local workspace/file dependency or a checkout fallback while preserving the exported package entrypoint for installed packages.

Useful? React with 👍 / 👎.

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.

1 participant