eclipse is the public Eclipse-side product CLI and SDK. It requests account
deployment lifecycle through Eclipse, defines and validates products, sets
project secrets, connects local Git to the environment repository, and submits
one signed review commit. Code.Storage is the private repository backend;
Eclipse owns its credentials and exposes Git plus its native repository
resources. Eclipse never receives workspace, Terraform, Kubernetes, database,
or Mothership credentials.
Run repository and release commands only in the standalone product checkout.
The bijection GitHub checkout is the Eclipse, Atelier, and Axiom
application implementation, not a product repository or an Eclipse product
remote; Eclipse rejects that checkout before publishing a release.
The contract
Tagged CLI releases also ship signed-checksum archives and Linux deb, rpm,
and apk packages. SDK tags publish the Python and TypeScript distributions
with their generated contract tests and package provenance.
Automation uses --json. Diagnostics go to stderr.
The generated Go, Python, and TypeScript SDKs live under sdk/eclipse. They
contain typed authoring and Eclipse account resources from reviewed OpenAPI
contracts: api/eclipse.openapi.json for authoring and
api/eclipse-account.openapi.json for account lifecycle. These are two
authority-specific clients in one Eclipse SDK, not separate product systems;
they are not a Mothership or Atelier client. The Python distribution and import,
Go package, and TypeScript package are all named exactly eclipse.
Environments and deployments
These commands call only Eclipse’s account API. eclipse login uses browser
WorkOS authentication and loopback PKCE, then stores an eight-hour opaque
bearer in the operating-system credential vault. No browser cookie, token file,
or token command argument exists. Creating an environment is one idempotent
Eclipse request that also creates its Stripe-hosted checkout continuation. The
control-plane worker—not the CLI—owns provisioning credentials and converges
the requested state.
Environment creation, deployment, and restore carry one UUID as both
request_id and Idempotency-Key. The generated transport retries a keyed
mutation at most twice on transient network, 429, or 5xx failures and never
retries an unkeyed mutation. Eclipse errors have stable code, message, and
request_id fields; temporary regional exhaustion is
capacity_unavailable with HTTP 503.
An environment is the isolated installation and commercial lifecycle resource.
A deployment is one immutable product-release and platform-release selection
inside that environment. The CLI uses the generated Eclipse client directly;
the reviewed OpenAPI contract is the only transport implementation.
The repository checkout receipt contains the standard Eclipse Git remote,
repository_api_base_url for a native Code.Storage client’s apiBaseUrl, and
repository_api_v1_url for raw HTTP. Git’s hidden credential helper supplies
only the Eclipse login. Below <repository_api_v1_url>, Code.Storage resource
paths and wire formats remain native; Code.Storage tokens, signing keys,
credential routes, and direct backend hosts never enter the CLI, SDK, browser,
or Git configuration.
Typical loop
Validation compiles the model directory and checks the full dependency graph.
Publishing produces one validated, signed review branch; merging it publishes the
product change. A human or explicitly delegated agent merges that branch in
Eclipse under its own review identity; the authoring processor never receives protected-branch
merge authority.
Authority-expanding semantic diffs are a separate signed decision: neither a
breaking-change override nor ordinary submission implies acknowledgment.
Authorization reachability
The graph is derived from the compiled product and code-owned capability
profiles. Exact mode evaluates the bounded closed authority space and represents
compound predicates as AND-gates; there is no authored graph file. The check
runs the closed seven invariants and exits with a policy refusal on any witness.
--from/--to renders the shortest existing authority, platform-ceiling, or
data-flow path and reports a why-not when none exists. authz check --check
narrows the human rendering while all seven invariants remain enforced.
explain access keeps platform-capability and model-policy proofs separate and
adds bounded context from the Product Catalog’s canonical lineage graph.
The structured model-check result includes eclipse.model_graph_check.v2: exact
model and catalog hashes, a canonical graph digest, node and edge counts, and
findings for panel fanout, orphan functions, duplicate typed read-sets,
unpresented objects, and unused authority attributes. Its summary separates
advisories, baselineable findings, accepted debt, and ratchet status. It is a projection of the
Product Catalog’s single typed dependency graph, not a separate authored graph.
Every shipped model has an explicit sibling baseline. The repository-wide gate
loads all shipped models and refuses missing baselines, load failures, new
baselineable orphan/duplicate/unused-attribute findings, and stale acceptances.
Panel fanout and unpresented objects remain visible review signals. For a
standalone Code.Storage product, the same ratchet lives in eclipse.toml [graph], is checked against the exact candidate tree, and its qualification is
covered by the signed review commit. Promotion independently re-derives the raw
graph, compares it with that signed qualification, and never reads the
authoring baseline.
Connectors
This is the one interactive OAuth installation rail. It performs a single
loopback PKCE authorization-code flow, sends the client secret only to the
declared token endpoint, stores client ID, client secret, and refresh token as
immutable secret versions, and atomically changes their three lock references so
the change is reviewed as ordinary Git.
It creates no runtime connection store and no mutable credential registry.
Declaring one connection field disables environment-variable fallback for the
undeclared ones. A partially declared connection is a configuration error, not a
hybrid.
Repository trust
Sets the public release trust the deployment verifies against. mothership
never sees the authoring worktree or Eclipse’s private repository identity — it
fetches the exact signed release through the deployment-internal read lane.
Product source ownership lives in policy/ownership.json at the repository
root. Its version is eclipse.product_ownership.v1; each area declares paths,
authors, reviewers, and the number of independent approvals required. The
current main policy governs a change, including changes to ownership itself.
Atelier Project membership does not grant definition-authoring rights.
The candidate must be a validated signed commit on current main. A separate
declared reviewer approves its exact revision. Changed source, a moved base,
withdrawn approval, or revoked membership prevents publication. revoke
withdraws the caller’s approval and retains its history. eclipse rollback
submits a historical tree as a draft for this same review path; only the initial
empty-repository bootstrap writes main directly.
