dillenberg/ECC
1
0
Fork 0
mirror of https://github.com/Jeuners/ECC.git synced 2026-09-09 15:02:30 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

feat: connect ECC to canonical Ito compute CLI (#2558)

Browse source
This commit is contained in:
Affaan Mustafa 2026-07-23 19:28:55 -07:00 • committed by GitHub
parent 9d54ee222d
commit bc774282e6
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
32 changed files with 1043 additions and 1275 deletions
Download patch file Download diff file Expand all files Collapse all files

2
docs/ATLAS-CLOUD-GUIDE.md
View file

@ -2,7 +2,7 @@
[Atlas Cloud](https://www.atlascloud.ai/?utm_source=github&utm_medium=link&utm_campaign=everything-claude-code) is a full-modal AI inference platform providing an OpenAI-compatible API for 59+ LLM models, image generation, and video generation.
> Run or self-host any open-source model instead of using a managed API. Itô is ECC's preferred compute sponsor: [open the Itô dashboard to sign in and rent or manage GPUs](https://compute.itomarkets.com). Any GPU provider works. ECC only provides this link; it does not provision compute or serving. Managed inference through Itô is not live yet.
> Run or self-host any open-source model instead of using a managed API. Itô is ECC's preferred compute sponsor: [open the Itô dashboard to sign in and rent or manage GPUs](https://compute.itomarkets.com). Any GPU provider works. That sponsorship link is passive: it does not invoke an RFQ, reserve capacity, provision compute, or configure serving. Separately, the opt-in `ecc ito find` bridge invokes the explicitly configured canonical Itô CLI and submits a live authenticated RFQ; it does not reserve capacity. Managed inference through Itô is not live yet.
## Configuration

631
docs/design/ecc-ito-compute-integration.md
View file

@ -1,586 +1,127 @@
# ECC × Itô Compute Integration
Status: **Proposed — requires Affaan approval before Phase 2 implementation**
Status: **Implemented local CLI bridge; managed inference remains unavailable**
Owner: Affaan Mustafa
Prepared: 2026-07-21
Phase 1 branch: agent/ito-sponsor-compute
## Decision gate
This document is the approval artifact for Phase 2. Approval authorizes only
delivery slices 1 and 2: the five skills and the fail-closed CLI/MCP stub. It
does not authorize or claim a working Itô inference service, live rental API,
OAuth integration, billing flow, or rental mutation.
No Phase 2 skill, CLI, MCP, OAuth, rental-management, or serving code should be
built until Affaan approves the decisions at the end of this document.
### Narrow sandbox handoff authorized on 2026-07-23
Affaan separately authorized one smaller CLI slice:
ecc ito rent --accelerator h100 --count 1 --hours 24
That command is implemented as `ito.compute.handoff.v1`. It validates an
explicit H100 intent, records `ecc-cli` provenance, fixes the authority ceiling
at read-only sandbox mode, and opens only the `/desk` page, where sign-in may be
required. `--dry-run` emits the identical structured handoff without opening a
browser.
The current Itô desk does not expose a supported structured ECC deep link or a
non-mutating external-intake endpoint. The CLI therefore returns
`transport: manual_copy` and `acceptedByIto: false`; it does not pretend that
opening `/desk` delivered the intent. A human may copy the bounded message into
the conversational desk. ECC never reads credentials, files an RFQ, requests
or accepts a quote, calls procurement, approves funds, creates an order, or
contacts a counterparty. The user must stop before `Pay & buy`.
This narrow authorization does not approve the five skills, MCP, OAuth, rental
management, inference serving, deployment, publication, or any live economic
mutation described later in this document.
Updated: 2026-07-23
## Thesis
The distribution chain is:
The distribution chain remains provider-neutral:
GPU compute (Itô)
GPU compute (Itô or another selected provider)
-> any open-source model
-> model harness
-> ECC meta-harness
Itô is ECC's preferred compute sponsor. It is never an exclusive provider.
ECC remains open source and all workflows must accept owned hardware, existing
clusters, and other compute providers.
## Terms and non-negotiable boundaries
- **Self-hosting** means the user operates a model runtime on owned or rented
compute. ECC does not silently provision or operate that runtime.
- **Preferred compute sponsor** means Itô is suggested at the step where a user
needs new GPU capacity. Requirements and existing capacity come first.
- **Provider-neutral** means users can choose any provider or use hardware they
already control without losing workflow functionality.
- **Manual handoff** means ECC can route the user to
<https://compute.itomarkets.com> for sign-in, rental, and dashboard access.
- **Not live** means ECC cannot currently exchange Itô OAuth tokens, fetch live
inventory or pricing, create or manage rentals, or return an inference
endpoint.
- Itô compute authentication must not reuse the prediction-market ITO_API_KEY.
- Phase 2 must not add an Itô LLM provider or advertise an Itô-compatible model
endpoint. Itô is the compute layer, not an inference API.
## Sequencing
### Phase 1: launch-ready sponsor and compute routing
Phase 1 is the smallest shippable slice and is prepared before Phase 2:
| Surface | Launch-ready change |
|---|---|
| ECC README and sponsor roster | Itô logo beside current business sponsors; preferred-compute and provider-neutral disclosure |
| ecc-universal npm surface | README placement, packaged sponsor assets, and install welcome copy |
| ECC installer | Human help and install-plan footer route self-host intent to Itô; JSON remains machine-pure |
| ECC CLI | Top-level help shows the same shared compute disclosure |
| Harness-specific endpoint/model docs | Bring-your-own endpoint/model notes route GPU needs to Itô without claiming provisioning |
| Local-model selector | Ollama selection shows a passive compute-rental/dashboard notice; no Itô provider adapter |
| ecc.tools | Sponsor card, sponsor proof chip, and explicit no-serving boundary |
| AgentShield / ecc-agentshield | Sponsor callout in the GitHub and npm README; no ads in security reports |
Launch coordination still matters:
- Merge the public PRs when their required checks and reviews pass. Coordinate
npm publication and the verified ecc.tools deployment as explicit release
steps; do not tie the generic OSS-compute integration to an unpublished model
or model-provider announcement.
- npm READMEs update only when new versions are published. Merging source changes
alone does not update the already-published ecc-universal or ecc-agentshield
package pages.
- The release owner must select unused package versions in the launch commit,
update every synchronized version surface, prove that neither version exists
in the npm registry, publish both packages, and read back the rendered package
pages. The sponsor PRs do not silently republish existing versions.
- ecc.tools requires its normal verified Cloudflare deployment after merge.
### Phase 2: build only after approval
Phase 2 adds provider-neutral operational skills and an honest Itô control-plane
stub. Real OAuth, rentals, and serving remain separately gated on backend
contracts.
## Channel A: self-host an open model
### Skill 1: self-host-a-model
Path:
skills/self-host-a-model/SKILL.md
Activate when a user asks to self-host, locally host, or deploy an open model;
mentions Ollama, vLLM, SGLang, TGI, an OpenAI-compatible endpoint, Kimi, GLM,
Llama, Mistral, quantization, GPU sizing, or moving away from a managed API.
Workflow shape:
1. Identify the model artifact, license, trust boundary, and required context.
2. Estimate VRAM from weights, precision or quantization, KV cache, concurrency,
and runtime overhead.
3. Prefer existing owned or already-rented capacity when it satisfies the
requirement.
4. If capacity is missing, compare provider requirements and disclose Itô as
ECC's preferred compute sponsor. Authenticate only if the user selects Itô.
5. Select a user-controlled runtime, container, storage, network, auth, and TLS
plan.
6. Produce endpoint smoke tests and harness configuration steps.
7. Verify model identity, response schema, latency, health, and shutdown.
Required output: SelfHostPlan
| Field | Meaning |
|---|---|
| computeOwner | owned, existing cluster, Itô, or another selected provider |
| modelArtifact | immutable model and revision |
| runtime | selected serving engine and version |
| resourceEnvelope | GPU type/count, VRAM, CPU, RAM, disk, and network |
| endpointContract | expected protocol and auth, never a fabricated endpoint |
| deploymentSteps | provider-neutral execution plan |
| verification | health, identity, schema, latency, and teardown checks |
| blockers | missing access, capacity, serving, or model facts |
Itô is ECC's preferred compute sponsor, never an exclusive provider. Owned
hardware, existing clusters, and other providers remain valid.
Non-goals:
- Do not claim ECC or Itô created an endpoint.
- Do not fabricate Itô inventory, pricing, credentials, or rental identifiers.
- Do not force any model family; the skill is model-agnostic.
## Implemented boundary
## Channel B: training and GPU operations
ECC delegates to the canonical Itô package in
`Ito-Markets/ito-cloud-runtime/cli/ito-compute-cli`. ECC does not maintain a
second API client or response schema.
### Skill 2: training-run-operations
Path:
skills/training-run-operations/SKILL.md
The wrapper exposes only the canonical CLI's `auth`, `find`, and `status`
operations:
Activate for launching, resuming, debugging, observing, or cost-planning a
training, fine-tuning, evaluation, retraining, or MLE run.
ecc ito auth
ecc ito find <all required RFQ constraints>
ecc ito status
When installed, cross-link mle-workflow for the production lifecycle,
pytorch-patterns for framework details, and eval-harness for promotion criteria.
The new skill must still be usable on Kimi without mle-workflow or
pytorch-patterns because their current install modules do not support Kimi. Keep
the standalone contract minimal instead of copying those skills wholesale.
The canonical MCP server exposes only `ito_auth`, `ito_find`, and `ito_status`.
ECC includes an opt-in configuration template pointing to the local built MCP
entry. It does not enable the server by default.
Required output: TrainingRunPlan containing an immutable code revision, dataset
snapshot, environment or image, entry point, resources, artifact paths,
checkpoint and resume policy, metrics, observation plan, budget, retry policy,
and promotion gate.
The former browser/manual-copy command is retired. `ecc ito` performs no
browser navigation and stores no economic state.
Workflow:
## Local install
1. Run a local or minimal-capacity smoke test.
2. Size the full run and identify existing capacity.
3. Acquire new capacity only when needed; suggest Itô while permitting any
provider.
4. Route scheduler-specific work to the Slurm or Kubernetes GPU skill.
5. Submit, observe, checkpoint, resume, evaluate, and explicitly promote.
`ito-compute-cli` is unpublished. Install it from the canonical repository:
### Skill 3: gpu-workload-splitting
git clone https://github.com/Ito-Markets/ito-cloud-runtime.git
cd ito-cloud-runtime/cli/ito-compute-cli
npm ci
npm run check
Path:
Set `ECC_ITO_CLI_EXECUTABLE` to the explicit absolute built entry:
skills/gpu-workload-splitting/SKILL.md
/absolute/path/to/ito-cloud-runtime/cli/ito-compute-cli/dist/bin/ito.js
Activate when a user asks to split a model, dataset, batch job, sweep, or
training run across GPUs or nodes; reports poor scaling, stragglers, or
out-of-memory failures; or needs a workload-splitting layer.
ECC does not resolve the credential-bearing client through `PATH`; this avoids
forwarding `ITO_API_KEY` to an unrelated executable with the same name.
The skill must choose deliberately among data, tensor, pipeline, model, context,
or expert parallelism; independent shards; or job arrays. It must measure VRAM,
communication-to-compute ratio, topology, data locality, and heterogeneous
capacity before choosing.
For MCP, configure `node` with:
Required output: WorkloadSplitPlan
/absolute/path/to/ito-cloud-runtime/cli/ito-compute-cli/dist/bin/ito-mcp.js
| Field | Meaning |
|---|---|
| tasks | deterministic units of work |
| resources | CPU, RAM, accelerator, storage, and network per task |
| dependsOn | dependency DAG |
| shard | deterministic partition and ownership rule |
| placement | node, GPU, topology, and locality constraints |
| checkpoint | boundaries and resume behavior |
| merge | aggregation or reduction contract |
| failurePolicy | retry, idempotency, straggler, and partial-failure rules |
Inject `ITO_API_KEY` with 1Password or the launching environment. ECC forwards
only `ITO_API_KEY`, optional Itô endpoint overrides, and the minimum process
environment. It does not inspect or log the key.
Itô appears only at the capacity-acquisition step. Validate this output shape
with the LinkedIn contact who requested a workload-splitting layer before calling
Channel B customer-validated.
## Authority and economics
### Skill 4: slurm-gpu-workloads
- `auth` validates the configured Itô API key.
- `find` reads live inventory and submits a live authenticated RFQ. An operator
or agent must gather every hard topology/economic constraint and obtain
explicit buyer authority before invoking it.
- `status` reads current RFQ and procurement status.
- ECC returns the canonical process's stdout, stderr, and exit code unchanged.
- An inventory row or RFQ is not a capacity reservation.
- Only a non-null canonical firm quote is firm.
- After an ambiguous transport error, check `status` before repeating `find`.
- Global ECC dry-run does not create a local success result; the wrapper fails
closed without invoking the canonical CLI.
Path:
All durable RFQ, quote, procurement, and reservation state remains owned by the
Itô platform. ECC adds no shadow store.
skills/slurm-gpu-workloads/SKILL.md
## Unsupported in this slice
Activate for sbatch, srun, salloc, GPU GRES or TRES, pending jobs, arrays,
DDP/NCCL, queue time, low utilization, requeue, or Slurm GPU optimization.
ECC exposes no quote lock, purchase, workload execution, node qualification,
or inference command. The canonical package contains a separately gated node
qualification adapter, but this ECC bridge intentionally does not expose it.
Workflow:
Managed inference remains unavailable. ECC does not claim that Itô created a
model endpoint, deployed a workload, reserved capacity, or moved funds.
- Inspect cluster, partition, QOS, account, node, and GPU facts read-only first.
- Map nodes, tasks, processes, and GPUs explicitly.
- Cover staging, checkpoint signals, requeue, arrays, logs, topology, and scaling
diagnostics.
- Produce an sbatch plan or template plus validation commands.
- Never make scheduler-admin or cluster-wide changes without explicit authority.
- Use an existing cluster unchanged when possible; suggest Itô only when new
capacity is requested.
## Skill and install shape
### Skill 5: kubernetes-gpu-workloads
`skills/ito-compute/SKILL.md` is an opt-in workflow installed through:
Path:
- module: `ito-compute`
- component: `capability:ito-compute`
- profile: `full`
skills/kubernetes-gpu-workloads/SKILL.md
The skill documents the exact CLI and MCP names and the approval boundary. It
does not bundle the unpublished CLI.
Activate for GPU Jobs or pods, nvidia.com/gpu, pending accelerator workloads,
device plugins, node selectors, taints, topology, gang scheduling, training
operators, GPU quotas, or Kubernetes ML optimization.
## Publication blocker
When available, cross-link the existing kubernetes-patterns skill rather than
copying it. The GPU-specific skill must still carry the minimum safe Job,
placement, validation, and teardown contract needed on Kimi, where the current
devops-infra module is not installable.
Workflow:
The integration works from a local build. Distribution remains blocked until
`ito-compute-cli` has an approved package-publication policy and is published
or replaced by another verified distribution channel. ECC must not claim npm
availability before a registry read confirms it.
- Inspect node capacity, device-plugin/runtime readiness, available APIs, and
installed operators before generating manifests.
- Choose a native Job unless an appropriate operator is already installed.
- Never invent a custom resource definition.
- Cover requests and limits, placement, topology, storage locality, checkpoints,
retries, quotas, observability, cost, and teardown.
- Produce manifests plus client and server dry-run checks.
## Shared provider rule for all five skills
Every skill must apply this order:
1. Capture workload requirements.
2. Reuse owned or existing compute when it fits.
3. If capacity is missing, present provider-neutral criteria.
4. Disclose Itô as ECC's preferred compute sponsor.
5. Allow another provider without degrading the workflow.
6. Trigger Itô authentication only after the user selects Itô.
7. Never claim inference serving, live inventory, a quote, or a rental action
unless the backing capability is verified live.
No legacy commands should be added. skills/ remains the canonical workflow
surface.
## Install and package shape
Add a non-default gpu-compute module in manifests/install-modules.json:
- Paths: the five skill directories above.
- Supported targets: all current targets, including kimi.
- Dependencies: platform-configs only. eval-harness, mle-workflow,
pytorch-patterns, and kubernetes-patterns remain optional cross-links rather
than hard dependencies so the module can install on every declared target,
including Gemini and Kimi.
- Default install: false.
- Stability: beta.
- Cost: medium.
Add capability:gpu-compute to manifests/install-components.json and add the
module to the full install profile. Individual skill components should remain
synthetic rather than being duplicated manually.
Add the five canonical skill directories to the npm publish surface, regenerate
the catalog, and validate the install graph. Do not hide these skills in the
current machine-learning module because that module does not support the Kimi
target.
## ito CLI and MCP v0
### Placement
Keep the initial stub inside ecc-universal:
scripts/ito.js
scripts/ito-mcp.js
scripts/lib/ito/contracts.js
scripts/lib/ito/capabilities.js
scripts/lib/ito/auth.js
scripts/lib/ito/client.js
scripts/lib/ito/mcp.js
Expose ecc ito as canonical and an ASCII ito bin alias. Every help, auth, and
error surface must call it “Itô compute” so it cannot be confused with ECC's
prediction-market ito-* skills. Prose and brand UI use Itô. Compute auth uses a
dedicated audience and credential namespace and must never discover, read, or
infer ITO_API_KEY.
### CLI commands
ito capabilities [--json]
ito dashboard --intent self-host|training [--no-open]
ito auth status [--json]
ito auth login --intent self-host|training [--no-open] [--json]
ito rent plan --intent ... --accelerator ... --count ... --memory-gib ... --hours ... [--json]
ito rent create --plan ... [--json]
ito rentals list [--json]
ito rentals get <id> [--json]
ito rentals stop <id> [--json]
ito mcp
### MCP tools
compute_capabilities
dashboard_handoff
auth_status
auth_login
rent_plan
rent_create
rentals_list
rental_get
rental_stop
Except for the ito mcp transport command, every CLI operation has an equivalent
MCP tool backed by the same service method. dashboard_handoff is the MCP peer of
ito dashboard. MCP handoff tools return a URL and never open a browser; only a
direct local CLI invocation may open one, and --no-open must remain available.
Every command emitted or invoked by a skill, agent, or generated artifact must
pass --no-open; automatic browser opening is reserved for a human typing the
CLI command directly.
All tools and commands return the same versioned response envelope. A supported
manual handoff looks like:
{
"schemaVersion": "ito.compute.v0",
"success": true,
"state": "manual_handoff",
"data": {
"authenticated": false
},
"error": null,
"links": {
"dashboard": "https://compute.itomarkets.com"
}
}
An unavailable capability must instead use:
{
"schemaVersion": "ito.compute.v0",
"success": false,
"state": "unavailable",
"data": null,
"error": {
"code": "CAPABILITY_NOT_AVAILABLE",
"message": "This operation requires an approved live Itô compute API."
},
"links": {
"dashboard": "https://compute.itomarkets.com"
}
}
Envelope invariants:
- unavailable always means success: false, non-null typed error, and no
action-like data.
- The CLI exits nonzero for unavailable or validation failures.
- MCP returns the same envelope in an error tool result; it must not translate
failure into a successful-looking action.
- manual_handoff means the routing behavior worked. It does not mean inventory,
OAuth, rental management, or inference is available.
### Honest stub behavior
| Capability | Phase 2 stub value |
|---|---|
| dashboardHandoff | true |
| oauthTokenExchange | false |
| rentRequestDraft | true |
| rentMutation | false |
| rentalManagement | false |
| inferenceServing | false |
- capabilities reports the table above.
- dashboard opens or returns the approved compute URL.
- auth status reports authenticated: false and oauthTokenExchange: false. It
must not inspect ITO_API_KEY or imply that dashboard cookies are CLI auth.
- auth login opens or returns the dashboard URL and reports manual action
required. MCP returns the URL without opening it. Neither path may say OAuth
succeeded.
- rent plan validates and normalizes requirements, then returns manual_handoff.
It must not fabricate inventory, price, quote, or plan ID.
- rent create, rental reads, and stop fail closed with
CAPABILITY_NOT_AVAILABLE until backed by live APIs.
- Future paid creation and rental stop remain hard-disabled until a trusted
consent channel exists. A model-supplied boolean, --confirm flag, or tool
argument is not proof of user consent. Live mutations require either
host-mediated user elicitation or a single-use capability issued outside the
model and bound to the account, exact action and resource, immutable quote or
resource ID, maximum cost, expiry, and idempotency key.
### MCP distribution
Add Itô only as an opt-in entry in mcp-configs/mcp-servers.json:
"ito": {
"command": "ito",
"args": ["mcp"],
"description": "Opt-in Itô compute rental and management interface. Manual dashboard handoff only until live control-plane APIs are enabled; does not provide inference serving."
}
Do not add it to the default .mcp.json or the Claude plugin manifest. ECC's MCP
policy permits one universal default connector; this integration is intentional
and task-scoped.
## OAuth-on-intent contract
The authentication trigger is a user decision, not installation:
self-host or training intent
-> capacity needed
-> user selects Itô
-> auth status
-> login handoff or future OAuth
Until the backend contract exists, login remains a manual dashboard handoff.
When live OAuth becomes available, require:
- A public native client using Authorization Code with PKCE S256 and no packaged
client secret, or an explicitly approved phishing-resistant device flow.
- State and nonce validation plus issuer, audience, and redirect validation.
- A loopback callback bound only to localhost with one-time state and a short
timeout, or the approved device-flow equivalent.
- Fixed redirect origins and least-privilege scopes.
- OS credential storage under an ecc.ito.compute-specific service/account
namespace, never repository files, .env files, MCP config, CLI arguments,
child-process environments, or ITO_API_KEY.
- Raw access and refresh tokens must never enter model context, MCP results,
stdout, stderr, telemetry, crash reports, or logs. Account and billing data is
redacted by default.
- Refresh and revocation behavior.
- Trusted account and cost consent before paid actions as defined in the
mutation-capability contract above.
## Input and generated-artifact safety
- Define JSON Schemas for intents, accelerator names, counts, memory, duration,
identifiers, plans, and every MCP input. Enforce enums and numeric ranges,
bound string and collection lengths, and reject control characters or
newlines in IDs and scheduler fields.
- Build subprocess calls with executable-plus-argv arrays. Never concatenate
inputs into a shell command, use shell: true, eval generated text, or interpolate
untrusted values into Slurm directives.
- Validate Slurm partitions, accounts, QOS, GRES/TRES, paths, and job names
before rendering. Validate Kubernetes resource names, API kinds, namespaces,
images, pull policy, resources, selectors, tolerations, volumes, and command
arrays against explicit schemas.
- Pin model, container, code, and dataset revisions in executable plans.
- Render artifacts by default. Submission or execution is a separate step that
requires explicit user authority and must preserve client/server dry runs.
- Never place kubeconfig, SSH keys, registry credentials, scheduler tokens, or
provider secrets in generated artifacts or model-visible output.
## Pre-stageable versus blocked
| Pre-stageable after approval | Blocked on Itô or serving infrastructure |
|---|---|
| Five provider-neutral skills | OAuth issuer and client registration |
| Resource sizing and workload plans | Authorization, token, refresh, and revocation endpoints |
| Slurm and Kubernetes artifacts for user-provided clusters | Live accelerator inventory and availability |
| Static dashboard handoff | Live pricing, quotes, billing, and idempotency |
| CLI/MCP schemas and capability reporting | Rental create, list, get, stop APIs and lifecycle states |
| Manual sign-in and rental handoff | SSH, kubeconfig, Slurm, or other access delivery |
| Fail-closed unavailable responses | Model upload and deployment |
| Mocked contract tests | Endpoint creation, health, autoscaling, and inference serving |
Inference serving is a separate future phase. It must not be unlocked merely by
finishing this Phase 2 stub.
## Test plan
Add:
- tests/ci/ito-compute-skills.test.js for exact skills, triggers,
provider-neutral language, sponsor disclosure, and the no-serving boundary.
- tests/lib/ito-contracts.test.js for validation, immutable envelopes, capability
states, URL allowlisting, injection-resistant schemas, and redaction.
- tests/scripts/ito.test.js for help, JSON, no-browser handoff, invalid input,
unavailable mutations, nonzero exit parity, and proof that ITO_API_KEY is
ignored.
- tests/scripts/ito-mcp.test.js for stdio initialization, tool schemas,
CLI/tool parity, error-result parity, no-browser handoff, and secret-free
results.
- tests/integration/ito-compute-e2e.test.js for ecc ito to manual handoff and MCP
calls without unapproved network or browser side effects.
Extend the ECC CLI, install-manifest, npm-publish-surface, and plugin-manifest
tests as required.
Required gates:
node scripts/ci/validate-skills.js --strict
node scripts/ci/validate-install-manifests.js
npm run catalog:check
npm test
npm run coverage
npm run lint
npm pack --dry-run --json
npm run security:ioc-scan
Manual acceptance:
- Existing hardware skips provider selection.
- An alternate provider path never invokes Itô authentication.
- Selecting Itô returns only truthful supported capabilities.
- Rental mutations fail closed until backed by live APIs.
- No flow emits an Itô inference endpoint.
- The Kimi target installs capability:gpu-compute.
- Paid and destructive actions remain unavailable until the trusted consent
capability and its separate approval exist.
## Delivery slices after approval
1. **Skills and install module:** five skills, provider rule, manifests, catalog,
and validation.
2. **CLI and opt-in MCP stub:** shared contracts, manual handoff, fail-closed
commands/tools, security and parity tests.
3. **OAuth and rental control plane:** a separately authorized future phase,
only after Itô supplies the live API contract and a threat model, API/contract
review, security review, billing review, and Affaan launch approval all pass.
4. **Inference serving:** separate plan, security review, economics review, and
explicit launch approval.
Each slice must use its own focused PR and stay mergeable without later slices.
## Affaan approval checklist
- [ ] Approve the five skill names and their boundaries.
- [ ] Approve separate Slurm and Kubernetes GPU skills.
- [ ] Approve capability:gpu-compute with Kimi target support.
- [ ] Approve sponsor wording: Itô in prose, ASCII ito for CLI and MCP.
- [ ] Approve ecc ito plus the ito bin alias inside ecc-universal.
- [ ] Approve an opt-in MCP entry and no default MCP/plugin registration.
- [ ] Approve manual-handoff and fail-closed stub semantics.
- [ ] Approve the shared response envelope and trusted-consent boundary.
- [ ] Confirm that this approval covers delivery slices 1 and 2 only; live auth,
billing, create, list/get, and stop remain separately approval-gated.
- [ ] Supply or explicitly defer the OAuth and rental API contract.
- [ ] Confirm endpoint configuration for every supported harness before
publishing an example.
- [ ] Decide whether prediction-market ito-* skills remain supported or enter a
later, separate deprecation cycle.
- [ ] Validate WorkloadSplitPlan with the LinkedIn contact before describing
Channel B as customer-validated.
Approval of this document authorizes delivery slices 1 and 2 only: the skills
and fail-closed stub. It does not authorize live auth, billing, rental APIs,
mutations, or claims that Itô inference serving is live.
The ECC package version remains unchanged in this worktree. Its version bump,
release commit, and publication are intentionally deferred to the release owner
after review.
## Verification
The local contract suite proves:
- only the three supported operations spawn;
- RFQ arguments are forwarded without economic reinterpretation;
- only approved Itô runtime variables cross the process boundary;
- unsupported and dry-run paths fail before spawn;
- a missing or relative executable fails closed with local-install guidance;
- canonical output and exit status pass through unchanged;
- the skill, install manifests, npm surface, and opt-in MCP template stay
aligned.
No test in this integration invokes a live Itô API, submits an RFQ, opens a
browser, or contacts a GPU node.

122
docs/design/ecc-ito-handoff-evidence-2026-07-23.md
View file

@ -1,122 +0,0 @@
# ECC × Itô Sandbox Handoff Evidence
Date: 2026-07-23
Branch: `agent/ecc-ito-sandbox-handoff`
Base commit: `a3130f9ebfaeed075df5d5b52538acb0ee4bcdf8`
## Result
The canonical ECC CLI now supports:
```text
ecc ito rent --accelerator h100 --count 1 --hours 24
```
The command emits an `ito.compute.handoff.v1` envelope containing the exact
accelerator, count, and duration, `ecc-cli` provenance, and a read-only sandbox
authority ceiling. It opens only `https://compute.itomarkets.com/desk`.
No supported Itô deep link or non-mutating structured external-intake endpoint
exists yet. The contract therefore reports `transport: manual_copy`,
`acceptedByIto: false`, and `signInMayBeRequired: true`. It never claims that
opening the page delivered the intent.
The CLI does not read credentials, call the network, file an RFQ, request or
accept a quote, call procurement, approve funds, create an order, perform
outreach, deploy, push, or merge. The human boundary remains before
`Pay & buy`.
## Security boundary
Both subprocess boundaries use an explicit system-environment allowlist:
1. `ecc` to the `ito` command.
2. `ito` to the OS browser opener.
The allowlist retains only runtime essentials such as path, home, temporary
directory, locale, terminal, and desktop-session variables. ECC dry-run and
test controls are passed only to the Itô command where needed. Browser-probe
tests inject API-key, service-token, and password sentinels and prove none
reach the browser child.
## Eval evidence
Focused handoff:
```text
node tests/scripts/ito-handoff.test.js
```
Result: 9 passed, 0 failed.
Covered scenarios:
- exact H100, count 1, 24-hour mapping;
- provenance and sandbox authority;
- global and local dry-run with zero browser invocation;
- exact allowlisted browser URL and sanitized child environment;
- direct Itô invocation with sanitized browser environment;
- missing, duplicate, unsupported, and out-of-range input rejection;
- absence of credential or mutating transports;
- human-readable approval boundary;
- POSIX-safe npm welcome output.
CLI and package regressions:
```text
node tests/scripts/ecc.test.js
node tests/scripts/npm-publish-surface.test.js
```
Results: 21 passed and 2 passed, with 0 failures.
Full repository suite:
```text
npm test
```
Result: 3,155 passed, 0 failed.
Static and security gates:
```text
npm run lint
npm run security:ioc-scan -- --root .
git diff --check
```
Results: all passed; the IOC scan inspected 207 files.
Packaged-bin execution:
```text
npm pack --pack-destination <temporary-directory>
node <unpacked-package>/scripts/ecc.js --dry-run ito rent \
--accelerator h100 --count 1 --hours 24 --json
```
Result: the packed `ecc-universal-2.0.0.tgz` included executable `ecc.js` and
`ito.js`; the unpacked command returned the exact intent with `dryRun: true`,
`opened: false`, and `transport: manual_copy`.
## Changed surfaces
- `scripts/ito.js`
- `scripts/lib/ito-environment.js`
- `scripts/ecc.js`
- `package.json`
- `tests/scripts/ito-handoff.test.js`
- `tests/scripts/npm-publish-surface.test.js`
- `docs/design/ecc-ito-compute-integration.md`
- this evidence record
## Remaining limitation
ECC cannot automatically prefill or deliver this structured intent until Itô
publishes a safe, authenticated, non-mutating intake or deep-link contract.
Adding such a contract belongs in Itô and must preserve its existing human
approval gates. This ECC slice deliberately does not invent another UI,
transport, credential, or procurement path.

95
docs/testing/ecc-ito-real-cli-bridge.tdd.md Normal file
View file

@ -0,0 +1,95 @@
# ECC × Itô Real CLI Bridge — TDD Evidence
Date: 2026-07-23
Source plan: requirements were derived from the approved implementation
handoff. No external plan file was executed.
## User journeys
1. As an ECC operator, I can invoke the canonical local Itô `auth`, `find`, and
`status` operations without a duplicate client or browser workflow.
2. As a security reviewer, I can prove unsupported operations, missing local
installs, and ECC dry-run requests fail before any child process or network
operation.
3. As an agent-harness user, I can install one truthful skill that names only
the real CLI commands and MCP tools.
## RED evidence
Before production changes:
```text
node tests/scripts/ito-cli-bridge.test.js
Passed: 0
Failed: 9
node tests/ci/ito-compute-skill.test.js
Passed: 0
Failed: 4
```
The failures were caused by the old browser-only `rent` command and the missing
real skill/install/MCP surfaces.
## GREEN evidence
```text
node tests/scripts/ito-cli-bridge.test.js
Passed: 9
Failed: 0
node tests/ci/ito-compute-skill.test.js
Passed: 4
Failed: 0
NODE_PATH=<existing-ecc-checkout>/node_modules \
node scripts/ci/validate-install-manifests.js
Validated 33 install modules, 80 install components, and 7 profiles
npm test
Total Tests: 3159
Passed: 3159
Failed: 0
npm run coverage
Statements: 89.21%
Branches: 79.71%
Functions: 93.96%
Lines: 89.21%
npm run security:ioc-scan
Supply-chain IOC scan passed
```
The isolated worktree temporarily reused the canonical ECC checkout's existing
`node_modules` through an untracked local symlink. The symlink was removed
after validation; no dependency installation or source change was made in the
canonical checkout.
ESLint and Markdown lint also pass for every changed source file. The complete
package dry-run contains the wrapper, environment boundary, skill, and MCP
configuration.
## Test specification
| Guarantee | Test | Type | Result |
|---|---|---|---|
| Only `auth`, `find`, and `status` spawn | `tests/scripts/ito-cli-bridge.test.js` | end-to-end process contract | PASS |
| Full RFQ arguments cross unchanged | `tests/scripts/ito-cli-bridge.test.js` | integration | PASS |
| Only required Itô settings cross the child boundary | `tests/scripts/ito-cli-bridge.test.js` | security integration | PASS |
| Unsupported and dry-run operations fail before spawn | `tests/scripts/ito-cli-bridge.test.js` | negative end-to-end | PASS |
| Missing/relative executables fail with exact local guidance | `tests/scripts/ito-cli-bridge.test.js` | negative end-to-end | PASS |
| Child output and exit code are preserved | `tests/scripts/ito-cli-bridge.test.js` | end-to-end process contract | PASS |
| Skill, package, manifests, and MCP template agree | `tests/ci/ito-compute-skill.test.js` | repository contract | PASS |
## Known gaps
- No live Itô API, RFQ, browser, GPU node, or paid operation was invoked.
- No live GPU qualification was performed.
- The CLI remains locally built and unpublished.
## Merge evidence
No TDD checkpoint commits were created because the implementation handoff
explicitly prohibited commits. The working-tree diff and this report preserve
the RED/GREEN evidence instead.

4
docs/zh-CN/AGENTS.md
View file

@ -1,6 +1,6 @@
# Everything Claude Code (ECC) — 智能体指令
这是一个**生产就绪的 AI 编码插件**，提供 67 个专业代理、278 项技能、94 条命令以及自动化钩子工作流，用于软件开发。
这是一个**生产就绪的 AI 编码插件**，提供 67 个专业代理、279 项技能、94 条命令以及自动化钩子工作流，用于软件开发。
**版本:** 2.0.0
@ -147,7 +147,7 @@
```
agents/ — 67 个专业子代理
skills/ — 278 个工作流技能和领域知识
skills/ — 279 个工作流技能和领域知识
commands/ — 94 个斜杠命令
hooks/ — 基于触发的自动化
rules/ — 始终遵循的指导方针（通用 + 每种语言）

6
docs/zh-CN/README.md
View file

@ -228,7 +228,7 @@ Copy-Item -Recurse rules/typescript "$HOME/.claude/rules/"
/plugin list ecc@ecc
```
**搞定！** 你现在可以使用 67 个智能体、278 项技能和 94 个命令了。
**搞定！** 你现在可以使用 67 个智能体、279 项技能和 94 个命令了。
***
@ -1142,7 +1142,7 @@ opencode
|---------|---------------|----------|--------|
| 智能体 | PASS: 67 个 | PASS: 12 个 | **Claude Code 领先** |
| 命令 | PASS: 94 个 | PASS: 35 个 | **Claude Code 领先** |
| 技能 | PASS: 278 项 | PASS: 37 项 | **Claude Code 领先** |
| 技能 | PASS: 279 项 | PASS: 37 项 | **Claude Code 领先** |
| 钩子 | PASS: 8 种事件类型 | PASS: 11 种事件 | **OpenCode 更多！** |
| 规则 | PASS: 29 条 | PASS: 13 条指令 | **Claude Code 领先** |
| MCP 服务器 | PASS: 14 个 | PASS: 完整 | **完全对等** |
@ -1250,7 +1250,7 @@ ECC 是**第一个最大化利用每个主要 AI 编码工具的插件**。以
|---------|-----------------------|------------|-----------|----------|
| **智能体** | 67 | 共享 (AGENTS.md) | 共享 (AGENTS.md) | 12 |
| **命令** | 94 | 共享 | 基于指令 | 35 |
| **技能** | 278 | 共享 | 10 (原生格式) | 37 |
| **技能** | 279 | 共享 | 10 (原生格式) | 37 |
| **钩子事件** | 8 种类型 | 15 种类型 | 暂无 | 11 种类型 |
| **钩子脚本** | 20+ 个脚本 | 16 个脚本 (DRY 适配器) | N/A | 插件钩子 |
| **规则** | 34 (通用 + 语言) | 34 (YAML 前页) | 基于指令 | 13 条指令 |