Skip to content

Latest commit

 

History

History
136 lines (116 loc) · 8.73 KB

File metadata and controls

136 lines (116 loc) · 8.73 KB

Phantom documentation

This is the canonical map for Phantom's repository documentation. Start with the shortest guide that matches your task, then use the security and architecture material when evaluating trust boundaries.

Release-state snapshot verified on 2026-09-05: the immutable GitHub release v0.7.8 resolves to source commit f065b13462f9eaf27e0443f8911f021575b7c409. Its exact 19-asset set, all six native release rows, checksums, archive-specific SPDX SBOMs, and GitHub provenance and SPDX attestations are bound to that immutable release by workflow 33952398697. Exact public registry endpoints were requeried on 2026-09-05. Homebrew independently publishes reviewed v0.7.8; npm latest remains 0.6.0, and both npm 0.7.4 wrappers remain only under the failed release-candidate track. The GitHub receipt alone does not establish 0.7.8 publication on npm, crates.io, or MCP Registry, or any hosted-service commissioning, provider activation, certification, or customer acceptance.

Start here

Goal Guide
Protect a project for the first time Getting started
Delegate one bounded task to an AI coding client Safe delegation quickstart
Plan a team or enterprise pilot Enterprise adoption
Understand open-source rights and paid evaluation paths Commercial offerings
Plan a public-sector evaluation Government evaluation
Review the shipped security boundary Security evaluation
Understand commercial support boundaries Commercial support
Use the project name or logo accurately Project name and logo use
Diagnose an install, vault, proxy, or cloud problem Troubleshooting
Understand the provider-grant design and 0.7.8 universal hard denial Provider grants
Understand components, trust boundaries, and activation status Architecture
Review the Rama-derived network engineering standard and adoption gates Rama design standard
Understand supported operating systems, architectures, and current validation Platform support
Prepare or audit a release candidate Release and readiness
Review the current unsigned boundary and future signing gates Signing and notarization readiness
Assemble a security or third-party review Security and audit index
Report a vulnerability Security policy
Evaluate Phantom's security assumptions and known gaps Threat model
Find contribution, support, or project-decision routes Community and project health

Agent and editor integrations

These guides cover installation, MCP setup, the value-blind tool model, and daily workflows:

The small conversation facade and the advanced MCP compatibility catalog are separate contracts. phantom_do is proposal-only and does not execute an action. phantom_setup_workspace can propose, create a bearerless request, or report status; applying that request requires a separate attached trusted terminal. Effectful advanced tools are disabled by default; PHANTOM_MCP_EFFECTS=trusted-terminal may enable their confirmation and one-use approval gates only when configured outside agent authority. Approval requires attached stdin/stderr, an informed value-blind summary, and a fresh typed challenge. A same-user shell or agent-controlled PTY can defeat the ceremony, so the approval command and storage must also be outside agent authority.

Provider issuance is not active in 0.7.8: every live enrollment exchange, issuance, refresh, renewal, rotation, and revocation path is hard-denied before provider credential or network access. A provider grant is design-era lifecycle metadata; an authority grant is the inactive execution-kernel authority type. Neither confers Locus authority, broker leases, or execution permission. Exact cfg(test) mocks are local transaction evidence only. The grant specification records the design-era target. The root issuance contract is the original design contract and retains historical design-status language.

Operations

Architecture and project development

The authority, Locus-contract, broker, runtime, session, and evidence crates are fail-closed foundations, not activated production authority or execution. The architecture and threat model record the current activation boundary and non-mitigations. A source implementation or passing test does not by itself prove packaged, installed, native, provider, or production acceptance.

Community and project health

  • Contributing — setup, repository map, security rules, test tiers, and pull-request expectations
  • Support — discussions, public issues, private security reports, and commercial-evaluation routing
  • Governance — maintainer-led decisions, roles, release authority, and commercial boundaries
  • Code of Conduct — participation and enforcement
  • Security policy — private reporting, scope, safe harbor, response targets, and known limitations
  • Roadmap — staged, gated, and exploratory milestones without delivery-date or activation claims
  • Citation metadata — cite the reviewed v0.7.8 release, or include the exact commit SHA when discussing later unreleased source

No donation or sponsorship program is represented by repository metadata at this time. Hosted pilots, enterprise scope, and support terms require separate commissioning and written agreement.

Machine-readable and publishing surfaces

  • llms.txt and llms-full.txt mirror public product guidance for language-model consumers.
  • index.html and related assets are legacy static-site sources. The standalone pricing.html and waitlist.html files are legacy snapshots, not redirects or an independent product or entitlement contract. The active product surface is the Next.js /pricing route; the legacy pages are excluded from the static sitemap.
  • blog-launch.md, blog-devto.md, and hn-submission.md are launch/publishing drafts, not normative technical specifications.

When behavior conflicts with prose, treat code, closed schemas, tests, and release automation as authoritative and open a documentation issue. Avoid copying capability counts or platform promises into new documents unless an automated check enforces them.