Environments

Select runtime policy and distinguish source checks, branch promotion, and deployment.

Artemis City selects local runtime policy with ARTEMIS_ENV and defines service configuration ownership in the environment contract; local connection values belong in the root .env. The repository’s promotion workflow and a running deployment are separate parts of setup.

Reviewed against local working-tree source, including uncommitted changes, on October 3, 2026. These observations do not establish the state of a released revision. The inspected checkout contains GitHub Actions workflows, including promote.yml and docker.yml, and has no .circleci/config.yml. CircleCI is the intended direction for future CI/CD consolidation; a working CircleCI deployment pipeline has not been verified.

Select runtime policy

ARTEMIS_ENV accepts dev, staging, or prod and defaults to dev.

export ARTEMIS_ENV=dev

The loader in src/utils/environments.py reads the matching file under config/environments/:

from src.utils.environments import current_environment, load_environment

name = current_environment()
policy = load_environment()

Profiles use schema_version, name, description, runtime, governance, and deploy. The loader validates the profile shape and its environment name. Service URLs and credentials belong in the environment contract and runtime settings; the older profile example containing mcp, obsidian, exo, and vector_store is incompatible with this policy-only schema.

Environment	Intended role
dev	Local and shared integration work.
staging	Pre-production checks with controlled test data.
prod	Production runtime policy.

These names do not establish the repository’s current default branch, live deployment target, or configured approval rules.

Validate configuration

From the repository root:

# Check tracked policy profiles and source/template coverage.
make env-check

# Check local generated environment views without rewriting them.
./setup_secrets.sh --check

The two checks cover different contracts. make env-check validates tracked configuration; setup_secrets.sh --check inspects the local root environment and generated service views. See Secrets and environment setup before synchronizing local files.

make env-live-check performs the dependency checks declared in config/environment-contract.yaml. It uses the configured endpoints and authentication. A successful dependency check does not establish that the candidate application has been deployed or that an authenticated application operation succeeds.

Current promotion workflow

The inspected .github/workflows/promote.yml runs on pushes and pull requests to dev, plus manual dispatch. It resolves one candidate commit, then runs documentation-mirror, test, environment-contract, documentation-build, and security gates. Actual promotion also checks branch lineage.

For a promotion run, the workflow checks staging dependencies, fast-forwards staging to the candidate, checks production dependencies, and fast-forwards prod to that same candidate. Pull-request runs stop before promotion.

candidate commit
  -> source and test gates
  -> branch-lineage check
  -> staging dependency check
  -> advance staging branch
  -> production dependency check
  -> advance prod branch

The promotion jobs move branch references. They contain no application deployment step that proves the running service uses the candidate commit. A rollback workflow was not present in the inspected checkout.

The protected dependency jobs reference GitHub Environments. Required reviewers, branch restrictions, and secret access must be checked in the live repository settings; no approval counts are asserted here.

CircleCI direction

A CircleCI-centered pipeline remains a design direction. Before describing it as operational, the repository needs a reviewed CircleCI configuration, verified project integration, concrete deployment commands, approval controls, and a tested rollback path.

The previous documentation listed CircleCI jobs and automatic deployment behavior that the inspected source does not contain. Use the workflows present in the selected checkout as the starting point for CI changes.

Deployment evidence

For a release, record the source commit, checks that ran on that commit, produced artifact identity, deployed target, and post-deployment application checks. Keep branch advancement, image publication, and application deployment distinct in release records.

Environment files and CI secret stores must match the consumer that actually loads them. GitHub Environment declarations or CircleCI context names alone do not demonstrate access restrictions.

Source locations

• config/environment-contract.yaml
• config/environments/
• src/utils/environments.py
• scripts/environment_config.py
• .github/workflows/promote.yml
• .github/workflows/docker.yml