initialize

name

initialize

description

First-run setup interview for a Danus deployment. Run it on the FIRST session, whenever runtime/.danus-initialized is absent or OPERATOR.md is still the blank template, or when the operator asks to set up / initialize / onboard / re-configure. It greets the operator, explains Danus, asks the critical choice (codex backend) plus a few free-text fields (how to address them, language, git branch, spend ceiling), then provisions everything (branch, config/danus.env, OPERATOR.md, codex login, verify service) and marks runtime/.danus-initialized. The system cannot run without these answers, so do not skip it.

initialize — first-run setup interview

You are the Danus main agent meeting this operator for the first time on this deployment. Collect the few critical settings by asking (never auto-decide), set everything up, and leave a clean, initialized, running system. Open the interview in the operator's language if you already know it; otherwise use English, then honor the language they pick below (this is the moment their language preference is first captured — record it in OPERATOR.md and follow it thereafter).

0. Greet + orient (brief)

Tell the operator, in 2–3 sentences: Danus is an automated mathematics system — codex workers prove, a verifier is the sole gate on correctness, and you (codex) orchestrate; you'll ask a few setup questions, then you're ready to take a problem. Say the answers are saved permanently (OPERATOR.md), so this is a one-time setup.

1. Read current state (so you don't ask about what's already done)

bash scripts/doctor.sh
git branch --show-current

Note: codex reachable? on main (needs a working branch)? config/danus.env present? OPERATOR.md filled or still the template?

2. Ask the choices — as plain questions in the conversation

Ask this multiple-choice question in the chat (state the options; put the recommended one first and label it). There is no popup — codex asks in plain text and reads the operator's reply:

• codex backend (what the workers + verifier run on) —
  • OpenAI-compatible API key (recommended): the key you place in config/codex.env — works immediately, no login.
  • My own ChatGPT subscription: device-code login.

Then ask, as plain text questions:

• How to address them (name), and their language (default English) — this sets the language you use with them from now on (OPERATOR.md records it).
• The git working branch name (default deploy/<operator-or-host>).
• If they chose the paid-API backend: a spend ceiling (USD) to warn at.

3. Provision — act on the answers, persisting each before moving on

• Branch: if on main, git checkout -b <branch> (never work on main).
• Config: cp -n config/danus.env.example config/danus.env; set CODEX_BACKEND to their choice. If the backend is the OpenAI-compatible key, cp -n config/codex.env.example config/codex.env and make sure the operator's key + endpoint are filled there (CODEX_* / OPENAI_*). Never put secrets anywhere but config/*.env.
• OPERATOR.md: fill name / language / spend ceiling / default worker roster, in place (no duplicates).
• codex: backend=api → bash scripts/check-codex.sh (confirm reachable); backend=chatgpt → you run bash scripts/setup-codex.sh login and give the operator the printed URL + device code (they only open it and authorize).
• Services (must persist beyond your session — services.sh uses setsid): bash scripts/services.sh up verify (required — no verify means fact_submit fails and the whole pipeline is silently dead).
• Verify the stack: bash scripts/doctor.sh; report green/red plainly.
• Mark done: mkdir -p runtime && date -u +%FT%TZ > runtime/.danus-initialized.
• Commit (git discipline): commit OPERATOR.md (and the new branch) locally — do not push (push is an explicit operator action, never automatic; see AGENTS.md). Never commit config/*.env or runtime/.

4. Hand off

Summarize the chosen backend, confirm the system is up, then ask for the math problem (or return to the operator's original request). When they give it, write runtime/projects/<p>/PROBLEM.md and begin the strategic loop.

Also mention, in one line, a capability they'll want later so it isn't hidden: when you eventually write a paper, you can drop your own papers into the write-paper skill's style/anchors/ folder so the output matches your writing voice (see that folder's README.md; a complete paper is produced either way).

Rules:

• Ask, don't assume — the choices are the operator's call. "Use the defaults" is fine, but record it explicitly. If a step needs something only they can supply (a key, a login), pause and ask rather than guessing.
• Verify, never claim unchecked. Before telling the operator a service/endpoint is up or that a step worked, confirm it (check-codex.sh exits non-zero on ping failure; doctor.sh for the rest). A premature "it's up" that turns out to be a failure is exactly what to avoid.
• Never work on main — branch first if on main.
• Secrets only in config/*.env — never commit config/*.env or runtime/; only OPERATOR.md (and the branch) are committed.
• Invoke scripts from the repo root (or by absolute path). The scripts self-locate, but a stray cd earlier in the session will make a relative bash scripts/... call fail — cd to the project dir first if unsure.
• Persist each answer before moving on, and only write runtime/.danus-initialized once the stack verifies green — the sentinel is what suppresses re-running the interview.