> ## Documentation Index > Fetch the complete documentation index at: https://docs.bijection.com/llms.txt > Use this file to discover all available pages before exploring further. # eclipse > Manage Eclipse lifecycle and author product code without live-world authority. `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 ```bash theme={null} go install ./cmd/eclipse go run ./cmd/eclipse commands --query environment --compact --json ``` 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`. ```python theme={null} from eclipse import EclipseClient, EclipseAccountClient authoring = EclipseClient(base_url="https://eclipse.example") account = EclipseAccountClient(access_token, base_url="https://account.eclipse.example") ``` ## Environments and deployments ```bash theme={null} eclipse login eclipse whoami --json eclipse environment catalog --json eclipse environment list --json eclipse environment create --name oversight --provider gcp \ --region europe-west9 --plan production --json eclipse environment get --json eclipse repository clone # Or connect an existing checkout: eclipse repository connect --repository . --json eclipse deployment create --product-release-id --json eclipse environment suspend --json eclipse logout ``` 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 ``, 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 ```bash theme={null} eclipse model check eclipse draft create --repository eclipse draft inspect --repository eclipse draft submit --repository --message "describe the change" # Add --acknowledge-authority-expansion only after reviewing newly reachable paths. ``` 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 ```bash theme={null} eclipse authz graph --json eclipse authz graph --from duty=medical_reviewer --to action:RaiseFinding --mermaid eclipse authz check --grants /path/to/grants.json --json eclipse authz check --check BIJECTION_AUTHZ_CROSS_MECHANISM_LEAK eclipse explain access --action RaiseFinding --attribute duty=oversight_lead --json ``` 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. ## Product graph conformance ```bash theme={null} eclipse model check \ --graph-baseline --json make model-graph-check ``` 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 ```bash theme={null} eclipse connector authorize ``` 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 ```bash theme={null} eclipse repository trust set ``` 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. ```bash theme={null} eclipse repository reviews list --json # Use the returned draft_prefix for ordinary Git authoring. eclipse repository reviews open eclipse repository reviews get eclipse repository reviews approve eclipse repository reviews publish ``` 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.