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.
| 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 |
These guides cover installation, MCP setup, the value-blind tool model, and daily workflows:
- Safe delegation quickstart for the common cross-client workflow
- Hub status contract for value-free local-orchestrator inspection (post-v0.7.8 source)
- Installed-runtime smoke for disposable CLI and MCP checks
- Claude Code
- Codex
- Cursor
- Windsurf
- Copyable agent policy, task brief, and pilot templates
- Examples index, including status and safety notes
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.
- Enterprise adoption and evidence
- Commercial offerings around the MIT core
- Commercial support boundary
- Government evaluation
- Security evaluation
- Cloud login
- Vercel and Railway sync
- CI/CD integration
- Shell prompt integration
- npm publication
- MCP Registry publication
- Current-state architecture and trust boundaries
- Rama-derived network engineering standard
- Release and readiness guide
- Signing and notarization readiness
- Security and audit index
- Platform support and native acceptance matrix
- Design-era provider-grant lifecycle specification
- Original provider-issuance design contract
- Contributing guide
- Roadmap and milestone gates
- Project governance
- Changelog
- Code of Conduct
- MIT License
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.
- 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.8release, 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.
llms.txtandllms-full.txtmirror public product guidance for language-model consumers.index.htmland related assets are legacy static-site sources. The standalonepricing.htmlandwaitlist.htmlfiles are legacy snapshots, not redirects or an independent product or entitlement contract. The active product surface is the Next.js/pricingroute; the legacy pages are excluded from the static sitemap.blog-launch.md,blog-devto.md, andhn-submission.mdare 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.