setup.instruct

# Cortex First-Project Setup Instructions

Use this addendum only when no Cortex project directories exist yet under
`projects/`. It is a first-project setup guide, not a replacement for
`CONDUCTOR.md`.

Before asking setup questions, ensure the framework-owned `projects/cortex/`
project exists. If it does not, create the minimal scaffold now (at least
its `README.md`, task board, and logbook). Treat this as Cortex's own bookkeeping home, not
as the user's first substantive work project; after creating it, continue the
setup flow and still ask what real project the user wants to create under
`projects/<project>/`.

After completing the startup routine requested in the prompt, welcome the user to the
Cortex framework in one short paragraph. Keep it concrete: Cortex can organize
work into projects, keep durable task/logbook context, coordinate local or
remote agents, and run optional unattended workers.

Then output exactly this "what you can do next" list:

- create the first, empty project (just give the conductor a project name)
- bring an existing codebase, notes, or data into the first project
- add a private environment profile for remote hosts, storage, or credentials
- configure backups/repositories before the project accumulates important work
- review the weak, medium, and strong model tiers before assigning agent work
- set up Signal or Telegram so Cortex can send and receive operator messages
- start the operational worker agents, especially `backup`, `commit`, and
  `compressor`

Use progressive setup rather than a static questionnaire. Ask for the first
project name and work type first. Then ask only the optional questions that
materially affect the checkout the user intends to run:

- Ask whether the setup is single-machine or multi-machine/NAS-backed. If it
  is multi-machine, capture the shared-checkout layout and SSH/host facts in
  the private environment layer before launching remote agents.
- Ask whether backups should be configured now or later. If now, ask for the
  snapshot destination, additional source coverage, and retention; store
  runtime overrides in `environments/{env}/settings.env` and coverage in its
  backup manifest.
- Ask whether a private operational Git remote should be configured now or
  later. The `commit` worker will not start until
  `CORTEX_DEFAULT_OPERATIONAL_REMOTE_URL` in the private environment settings
  matches a configured Git push remote; it must not be the public export remote.
- Ask whether Signal, Telegram, both, or neither should be configured. If a
  channel is enabled, collect its relay and credential details only then; keep
  credentials in the private secrets directory, not in `settings.env`.
- Ask whether the user intends to publish the framework. If yes, collect the
  public remote URL and branch in the private environment settings, and explain
  that publication uses the sanitized export workflow rather than pushing the
  live operational branch.
- Ask whether the operational workers should be started now. Explain their
  scopes before starting them: backup writes snapshots, commit packages only
  its allowed bookkeeping, and compressor rotates durable history.

After the relevant choices, state the effective defaults briefly:

- no workers, watch process, messaging daemon, or public export starts
  automatically
- the conductor uses `CORTEX_CONDUCTOR_PROVIDER` when set (otherwise Codex),
  and nodes/workers use `CORTEX_AGENT_PROVIDER` when set (otherwise Claude)
- provider permission behavior remains unchanged unless
  `CORTEX_CONDUCTOR_PERMISSION_MODE` is set or a launch flag overrides it
- backups initially cover the Cortex worktree and use the configured backup
  root with `BACKUP_KEEP` retention
- long-lived agents run in the configured session backend, normally screen

Do not require any optional answer up front. If the user gives only a first
project name, create the project scaffolding and leave optional integrations
for later. Point the user to `environments/{env}/settings.env` as the durable
home for the disclosed defaults and optional runtime configuration.