feat(env): surface .env compatibility and explicit backend/trust-model UX - #27
feat(env): surface .env compatibility and explicit backend/trust-model UX#27roodboi wants to merge 4 commits into
Conversation
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ca25dfcb2e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| }, | ||
| compatibility_mode: { | ||
| plaintext_target: input.storage.localPlaintext.path, | ||
| secret_backend: input.storage.localSecrets.backend, |
There was a problem hiding this comment.
Surface shim storage in compatibility_mode.secret_backend
When controlPlane.secrets.backend is "cloud", this new field is serialized as "cloud" even though resolveSecretStore() still routes those values through createCloudShimAdapter() and persists them in the local encrypted-file shim. Any caller that relies on the new compatibility_mode block to explain where secrets materialize or whether they are portable will therefore misclassify cloud-shim projects as remotely backed instead of machine-local, which defeats the trust-model UX this change is trying to add.
Useful? React with 👍 / 👎.
…compatibility-whil
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4bc30cf515
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const backendStatus = describeBackendTrustStatus({ | ||
| backend: secretsConfig.backend, | ||
| provider: secretsConfig.cloud.provider ?? null, |
There was a problem hiding this comment.
Flag cloud backends with no provider as invalid
If controlPlane.secrets.backend is already "cloud" but cloud.provider is unset — a state older hack env backend use cloud invocations could leave behind, or a manual config edit can create — env backend status now builds a normal-looking status block and exits 0. That is misleading because createCloudSecretStore() in src/lib/secret-store.ts throws on this exact configuration, so hack env list and secret writes still fail immediately. The new trust-model UX should surface this as invalid instead of reporting a provider-targeted shim.
Useful? React with 👍 / 👎.
…compatibility-whil
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ce503ca7db
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const backendStatus = describeBackendTrustStatus({ | ||
| backend: secretsConfig.backend, | ||
| provider: secretsConfig.cloud.provider ?? null, |
There was a problem hiding this comment.
Reject cloud status when provider is unset
If controlPlane.secrets.backend is cloud but controlPlane.secrets.cloud.provider is missing (possible from older configs or manual edits), env backend status still emits a normal status block and exits successfully. That state is not actually usable: secret-store resolution throws (createCloudSecretStore() in src/lib/secret-store.ts requires a provider), so hack env list and secret writes fail immediately. This makes the new status output unsafe for readiness checks because it reports a healthy cloud backend that cannot be used.
Useful? React with 👍 / 👎.
…compatibility-whil
Motivation
.env-style local workflows while making backend and trust-model implications explicit inhack envoutput.Description
hack env listhuman and JSON output by exposing committed contract metadata,.hack/.envplaintext compatibility status, ambientprocess.envfallback, local secret backend descriptor, compatibility materialization rules, and portable-state message (changes insrc/commands/env.ts).hack env backend statusto includestorage_mode,trust_model,portability, and explicit.envcompatibility guidance in both JSON and human-readable panels (changes insrc/commands/env.ts).src/commands/env.ts).docs/env.mdanddocs/cli.md, and add a focused design note atdocs/plans/2026-03-23-env-compatibility-and-trust-model-ux-design.md.tests/env-backend-command.test.ts.T-JC89E7C801to mirror these compatibility and trust-model messages in the macOS UI.Testing
bun test tests/env-backend-command.test.tswhich executed 6 tests (6 pass / 0 fail) covering backend status, backend selection/provisioning, secret storage, and the new JSON compatibility fields, and all tests passed.bunx ultracite check(issues were fixed where safe), and checks passed after fixes.hack tickets createto track desktop UI follow-up (T-JC89E7C801).Codex Task