The shape
In the reviewed source, CI health workflow generation is unavailable:
- Review the Phantom Cloud boundary: unattended pull is unsupported by Phantom Secrets 0.7.9.
-
Inspect
stack ci init. The admitted source refuses workflow generation with exit code1; it does not write a workflow. - Optionally collect a JSON source-drift report separately. It is not a credentialed health check or working CI bootstrap.
Unattended Cloud pull is unsupported with Phantom Secrets 0.7.9. Cloud pull requires stdin, stdout and stderr on a trusted terminal; --force only declares overwrites and does not bypass that requirement. PHANTOM_CLOUD_TOKEN is not a supported Cloud bearer-token input, and the local vault passphrase is not the separate Cloud encryption key. Adding those GitHub secrets does not enable unattended Cloud pull.
Check workflow availability
# Inspect the installed command interface
stack ci init --help
# Reviewed source refuses generation with exit 1
stack ci init
# Compatibility flag: still refuses; does not overwrite
stack ci init --force
# Bare `stack ci` gives the same refusal; --json prints {"error": "..."}
stack ci --json
The source first checks whether .stack.toml exists; this is not TOML validation. If .github/workflows/stack-ci.yml already exists and --force is absent, it reports that the file was not changed. Otherwise it reports generation unavailable. All these command-body refusal paths exit 1 before any workflow directory creation or file write. --force only changes which refusal is reached; it is not an overwrite override.
Refusal output
CI health workflow unavailable: Phantom Cloud pull requires trusted-terminal approval. No workflow was written. Instead, run `stack doctor` from a trusted terminal, or `stack doctor --reconcile --json` in CI for a credential-free source-drift report. Cloud prerequisites
These names appeared in the former Cloud recipe. Adding them in Settings → Secrets and variables → Actions does not enable unattended Cloud pull with Phantom Secrets 0.7.9:
| Secret | Where it comes from |
|---|---|
PHANTOM_VAULT_PASSPHRASE | A local-vault passphrase is not Phantom Secrets 0.7.9’s separate Cloud encryption key. It does not enable unattended Cloud pull. |
PHANTOM_CLOUD_TOKEN |
Phantom Secrets 0.7.9 reads its Cloud bearer token from its credential store, not this environment variable. Check phantom --help; this environment variable is not supported Cloud authentication.
|
Exit-code behaviour
# Illustrative source refusal; no workflow write
$ stack ci init
CI health workflow unavailable: Phantom Cloud pull requires trusted-terminal approval. No workflow was written. Instead, run `stack doctor` from a trusted terminal, or `stack doctor --reconcile --json` in CI for a credential-free source-drift report.
$ echo $?
1 The existing config and file guards also refuse with exit 1. Running a GitHub job manually does not supply the trusted-terminal ceremony required by Phantom Secrets 0.7.9. The producer does not emit a Cloud workflow, and no unattended health integration is established here.
Optional source-drift report
{
"configured": ["supabase"],
"detected": [],
"orphans": ["supabase"],
"untracked": []
}
The JSON above illustrates stack doctor --reconcile --json: configured and detected record config services and source detections; orphans and untracked record their differences. This branch returns before Phantom and health checks and returns 0 on detected drift. Tooling must inspect the fields; scanner or I/O errors can still fail. It is not credential or provider-health acceptance.
Other CI systems
stack ci init does not generate a health workflow for GitHub Actions or another CI system. An optional source-drift report can be collected separately:
# Optional local source-drift report; drift itself returns 0
stack doctor --reconcile --json > stack-source-drift.json A supported unattended credentialed health integration remains separate work. Open an issue on GitHub if you want yours prioritised.
stack scan in CI — existing repos
If you're adopting Stack in a repo that already has services wired up
manually (environment variables set, packages installed), use stack scan to detect them without interactive prompts:
# Report detected services without adding them
stack scan --json --confidence medium | Flag | Behaviour |
|---|---|
--json | Emit a machine-readable JSON report and exit 0. No prompts, and nothing is added even with --yes. Suitable for parsing in downstream steps. |
--yes | Without --json, implies --auto and enables add attempts at or above the confidence tier without confirmation. With --json, scan reports hits and returns before adding services. Without either flag, a non-TTY run prints the read-only report; --auto without --yes exits 1. |
--confidence <low|medium|high> | Filter by the named tier. The default is medium, or high with --yes; the example explicitly selects medium. |
Illustrative JSON output shape:
{
"hits": [
{ "provider": "resend", "confidence": "high", "sources": ["package.json:resend"] },
{ "provider": "supabase", "confidence": "high", "sources": ["package.json:@supabase/supabase-js"] }
]
}
Combine with stack doctor --reconcile to also detect drift
between .stack.toml and source imports. See Maintenance for details.
Rotating secrets from CI
stack login <provider> runs the provider login path, but cached credentials and create-only storage can prevent replacement. Verify the resulting slot and your separately qualified CI credential delivery before relying on it.