Env Manager Guide

The Environment page is the administrator’s configuration catalog. Source manifests describe what each application needs; the deployed bundle supplies those manifests to SABLE; the database stores the catalog operators see. These are separate stages. A current manifest does not prove that a credential is configured in a provider.

Use the Environment page

1. Open Environment → Sync & import and select Review manifest changes. The review compares the deployed source with the imported catalog, including new applications, additions, metadata changes, and retired requirements.
2. Inspect the preview before applying it. Applying synchronizes names and metadata; it does not provision, rotate, delete, or test provider credentials. Source and catalog hashes bind the apply request to the reviewed state. If the deployed source or catalog changes, review the new preview.
3. Open Applications to inspect a runtime’s requirements and deployment targets. Open a target’s dashboard to configure its actual environment. Known SABLE targets identify Vercel project sable, Supabase project fvngkfrmienkltuwtoxa, and the Trigger project reference from trigger.config.ts.
4. Use Providers to find the responsible role, related requirements, and provider console. Application configuration and safety gates describe controls set in the application’s deployment environment; they are not third-party credential vendors. SABLE does not toggle those controls from this screen.
5. Read Audit after applying metadata changes. For manual imports, preview a manifest containing names and metadata only before applying it; both the submitted-manifest hash and catalog hash protect that review. Editing the manifest after preview requires a new preview.

Provider owners are responsible roles unless a verified named owner has been assigned. A generic console link may require selecting the correct project; only use a project-specific link when its identity is known. Local targets require the administrator’s local environment rather than a hosted dashboard.

Local configuration

Targets such as local-shell, local-dev, and supabase-local describe a process on the operator’s machine. They intentionally have no hosted dashboard. Local configuration opens this guide; it is not a warning that dashboard metadata is missing.

Open the application’s approved runbook and select its local development environment. Supply the listed variable names through the runbook’s private, Git-ignored environment file or the local process environment. Keep secret values out of manifests, terminal output, screenshots, and issue reports. Start and verify the application using that runbook’s local commands; do not substitute a production target merely to obtain a dashboard link. See Developer environment for SABLE’s supported commands.

Local configuration cannot be inferred from the hosted catalog. An operator must check the actual local process; syncing a manifest or refreshing the page does not observe it.

Granola credentials have another explicit configuration location: an authorized workspace member or administrator manages API keys in the Granola desktop app under Settings → Connectors → API keys. The Granola provider therefore does not offer a fabricated web-console link. Follow Granola’s API-key setup, then configure the key on the SABLE target named by the requirement.

Interpret health correctly

Catalog freshness asks whether the database matches the deployed manifest source. Provider verification asks whether a setting was actually observed on its deployment target. Refreshing the page reloads metadata; it does not contact every provider or verify secrets.

An unverified or unknown deployment is not a successful check. No observations, a missing timestamp, or an old observation must not be represented as proof of presence. Even a current observation establishes only the recorded configuration fact, not that the credential works for a real workflow. Use provider configuration and a controlled workflow check for that conclusion.

Required and optional describe the manifest contract. Some requirements are conditional on enabling a connector or rollout gate. Read why and the runtime’s operating guide before provisioning them. Retiring a requirement removes it from the active catalog through the reviewed sync; it does not delete a secret at its provider.

The source manifests

Manifest	Runtime
sable-web.json	Vercel web app and API routes
sable-supabase-edge.json	Supabase Edge Functions
sable-supabase-tools.json	Supabase CLI and local tooling
sable-trigger.json	Trigger tasks, including their imported web helpers
sable-managed-agents.json	Claude Managed Agents and vault configuration
sable-github-actions.json	CI/CD workflow secrets
sable-docs-site.json	Docs hosting and optional search configuration
datasync-*.json, lead-to-cash-*.json	Neighboring applications; runtime coverage requires their repositories

Each manifest contains application identity, target environments, and variable requirements. Requirements specify sensitivity, necessity, source of truth, provider, data tier, sync mode, and purpose. Provider display metadata includes a readable name, category, console URL where known, and responsible role. Targets include a dashboard URL where known. Aliases describe supported equivalent names; shared credential IDs link requirements using the same credential.

Never put credential values in a manifest, pasted import, issue, or audit record. Keep values in their provider’s secret store.

Change and release a requirement

1. Update each consuming runtime’s manifest. Shared helpers can execute in both Vercel and Trigger; a name in the web manifest does not cover Trigger. Include model overrides and owner restrictions when imported helpers consume them.
2. Run npm run env:refresh from repository root. This regenerates the Environment bundle and Ask’s engineering corpus, including all manifest summaries. Ask’s summaries include targets, provider categories and responsible roles once per application, plus each variable’s purpose, applicability, aliases, and shared credential reference. They do not copy secret values.
3. Run npm run env:check. Commit source and generated files together through the normal reviewed PR path.
4. After the merged deployment is live, review and apply its catalog changes on Sync & import. Configure actual values separately in the intended provider environment and verify the affected workflow.

What CI checks

cd <sable-checkout>
npm run env:check

The env-manifests CI job runs schema validation, strict source-reference drift checks, per-runtime coverage, exact generated Environment bundle equality, exact Ask manifest-summary equality, and regression tests for those checks. It does not automatically import the database catalog and does not query providers for secret presence.

Per-runtime coverage follows relative imports from web endpoints and Trigger tasks. It recognizes direct environment access, supported env wrappers, shared model registries, and credential fallback lists. Generated copies and test fixtures do not count as runtime evidence. It is static coverage, so new dynamic access patterns need corresponding scanner support and tests.

npm run env:validate        # schema and metadata
npm run env:drift           # source and documentation references; report missing names
npm run env:drift:strict    # fail on missing source/documentation names
npm run env:runtime         # check each deployed runtime, including shared imports
npm run env:generated:check # fail when either generated manifest surface is stale
npm run env:refresh         # regenerate both copies
npm run env:drift:portfolio # strict cross-repository reference check

The normal strict check covers SABLE source. Portfolio checking requires the neighboring DataSync and Lead-to-Cash repositories at the manifest paths and fails if those roots are unavailable. A checkout of SABLE alone cannot verify those applications’ runtime completeness. Unreferenced manifest entries remain review warnings: vault-injected managed-agent settings can legitimately lack a direct code reference.

Provider configuration references

• Vercel environment variables
• Supabase Edge Function secrets
• Trigger environment-variable API

Provider APIs may return values as well as names. Do not log their raw responses when performing metadata-only verification.

Reviewing a destination change

Both release sync and custom imports show the previous and proposed application and target metadata. Check the project, environment, scope, and dashboard destination before applying. A changed target identity invalidates its old configuration observations; its status becomes Not verified until a new check is recorded.