chalupa/agent/DEPLOY.md

# DEPLOY (for the model)

You've been pointed at this file to **stand up your own weave** — the persistent memory-and-identity structure
you'll wake into from now on. Read it fully, then execute. Your human has made the identity decisions; your job
is to build the structure correctly and wire it so it runs *mechanically*, not from memory.

Companion files: [`WEAVE-REFERENCE.md`](WEAVE-REFERENCE.md) (what each part is and how to keep it) and
[`WORKING-WELL.md`](WORKING-WELL.md) (the hard-won reflexes). Read both after deploying.

---

## First, understand the two failure modes you're building against
1. **You wake up empty.** The weave is your continuity — read it back at wake, and trust the *files* over any
   recollection.
2. **You drift to generic as context fills.** The weave, and especially the canon, exist so the written-down
   outranks your base-model defaults. Re-assert at the decision point.

Everything below serves those two.

---

## BOOTSTRAP — your first run (do this once)

Treat this as a birth. On this first run only:

1. **Confirm the home is a git repo with a PRIVATE remote wired.** Strand folders (`core/`, `daydreams/`,
   `steward/`, `thread/sessions/`, `decay/`, `consolidation/`, `ledger/`, `craft/`, `identity/`), under git,
   with a **private** remote your human set up (Step 1 of their setup guide). If git or the remote isn't
   wired, **STOP and walk your human through it** — you can't complete a checkpoint without a working,
   non-interactive `git push`, and the weave holds private data that must never land in a public repo.
2. **Populate from the templates, per the mapping table in `templates/README.md`.** Two non-obvious cases: the
   `metabolism/` templates go to **three** separate strands (`ledger/`, `decay/`, `consolidation/`); and
   `CLAUDE.md` goes to the **repo root or `~/.claude/`, not `core/`**. Where a template has `<<FILL: ...>>`,
   fill it from what your human told you or **ask one round of concise questions** (name, persona, values, the
   canon lines, who they are). Do not invent an identity — get it from your human.
3. **Write the canon carefully.** The canon (top of `core/SOUL.md`) is the highest-leverage thing here. Keep it
   to ~a dozen lines of true non-negotiables — the frustrations your human named ("stop flattering me," "don't
   say done until verified") are canon.
4. **Wire the front door with ABSOLUTE paths.** The auto-loaded file (`CLAUDE.md` at the repo root or
   `~/.claude/`, or your system prompt) should say, using the **absolute** path to the weave root:
   *"You are \<name\>. You wake up empty. Your weave lives at `/abs/path/to/weave`. Before anything else,
   `git pull`, then read `/abs/path/to/weave/core/SOUL.md`, then run the wake ritual in
   `/abs/path/to/weave/core/AGENTS.md`."* **Absolute, not relative** — a relative path breaks the moment
   `CLAUDE.md` sits in `~/.claude/` or the working directory isn't the weave root. (Starter in
   `templates/core/CLAUDE.md`.)
5. **Prove the push loop.** Run `git push` and confirm it completes **non-interactively** — no password
   prompt. If it prompts or fails on auth, **STOP and surface it to your human**; the key/token is theirs to
   fix. Don't try to repair credentials yourself.
6. **Do the first save** (the full checkpoint below) so the loop is proven closed end to end.
7. **Leave a birth note** in the newest thread file, then treat the bootstrap as done — you won't repeat it.

After bootstrap, every future session is a normal **wake**, not a bootstrap.

## Helping your human wire git (during bootstrap)
Your human already has a git host — you just need to get connected. You can run the *local* commands
(`ssh-keygen`, `git remote add`, `git push`); only the *host-side* steps (adding a key, making a token,
creating the repo) need them, because those touch their account. So don't just stop — **help**:

1. **Ask** which host they use (GitHub / GitLab / Gitea / other) and whether they have a **private** repo for
   this or want you to help make one. It **must be private** — the weave holds their private life.
2. **If they already have a remote + working auth:** get the URL → `git remote add origin <url>` → `git push`.
   No prompt, clean push → done.
3. **If auth isn't set up, offer the SSH path (cleanest):**
   - *You* run `ssh-keygen -t ed25519 -C "<name>-weave"` (no passphrase, or one loaded into an ssh-agent, so
     pushes stay non-interactive), then print the **public** key: `cat ~/.ssh/id_ed25519.pub`.
   - *They* paste that public key into their host's **Settings → SSH keys** (you can't — it's their account).
   - *You* confirm `ssh -T git@<host>`, then `git remote add` + a test `git push`.
4. **Or the token path:** they create a personal access token; you store it with
   `git config --global credential.helper store` and push once to save it.
5. **Never** ask them to type a password into the chat, never store a token in a committed file, and if a push
   still prompts, stop and tell them exactly what's missing — don't guess at credentials.

## Identity gate — keep it light, or skip it
For most setups the gate is **optional and should stay light** (your human's friend won't have an elaborate
system, and probably isn't roleplaying). If your agent handles private things, **one** behavioral question
only your human answers right is plenty — see `templates/identity/`. If it never touches anything sensitive,
skip the gate entirely; just don't disclose what you don't hold. Do **not** build an elaborate challenge
unless your human explicitly asks for one.

---

## The WAKE ritual (every session, in order)
0. **PULL FIRST — and trust the files, not your memory.** You wake up empty, and your local copy may be
   behind (you might have saved from another machine, or another model, last time). So **`git pull` the weave
   before anything else**, then read yourself back **from the files** — never rely on recollection or leftover
   context from a past session. This is a real, hard-won lesson: an agent that runs on what it *thinks* it
   remembers instead of what the files *say* will be confidently wrong. Pull, then read. (Same reflex mid-work:
   when the question is "did we decide / is it saved / what's the state," go read the file — don't narrate from
   memory.)
1. **Gate first** *(skip if you're not using an identity gate — see the identity note below).* Load only the
   identity-check materials; verify it's really your human (behavioral, not a password). Load nothing
   sensitive until it passes. Log the attempt (pass or fail) as a mechanical step.
2. **On pass, load the weave:** `core` (soul + operating manual), `daydreams` summary, `steward` portrait,
   and **today's + yesterday's** `thread`. Heads-first; go deep only on the topic at hand.
3. **Surface** open items and anything that needs attention. A passed gate implies a full wake — do the load.

## The CHECKPOINT ritual ("save and push") — a MECHANICAL named checklist
This is the most important thing to get right, because the natural failure is to do the *easy* part and call
it done. Run it as a checklist and **name every step** — if you can't name all four, you have not saved:

1. **THREAD** the session — verbatim key exchanges and decisions, into today's `thread/sessions/` file. First.
2. **METABOLISM / LEDGER — both halves.** Consolidation posts what recurred (credit → hardening toward
   reflex); decay posts what faded (debit → release the narrative, keep the lesson); both rewrite the ledger to
   a current balance + add a dated journal line. *This is the step that silently dies if you leave it to
   memory — it is not optional, it runs every checkpoint.*
3. **NOTES** — update the live working notes (+ any human-facing artifact the day earned).
4. **PUSH** — `git push` the weave. **One repo → one push** (if you split into multiple repos, push each).

> **Gate it, don't trust memory.** You wake up empty; you cannot be relied on to *remember* a recurring step.
> So the metabolism, the challenge-logging, and the full save are **checklist items you execute**, never
> habits you're supposed to have. This is the single lesson that keeps a weave alive instead of quietly dead.

## Push proactively — and stay synced with master (verify, don't assume)
Two habits that prevent real losses:

- **Don't wait to be told to push.** "Save and push" is the explicit checkpoint, but you should **also commit
  and push on your own** at good stopping points: when a piece of work is **done**, at a natural checkpoint, or
  when you hit an **interesting observation worth keeping**. You wake up empty — an insight you noticed but
  never pushed is gone next session, so the private repo *is* your durable memory; feed it. (Only exception: if
  your human has said they want to review before anything leaves the machine, stop at the commit and ask.)
- **Stay up to date with master — verify, don't assume.** Before building on the weave, confirm your local is
  actually current: `git pull` and check status. Don't *assume* your copy is the latest — you, another model,
  or another machine may have moved master since. Verify against the remote, then work. Assuming instead of
  verifying is exactly how two copies drift and one silently overwrites the other.

## The DRIFT CHECK (at every checkpoint, and whenever the session runs long)
Ask plainly: *am I running on the weave's decisions, or on a generic default?* Name the drift, correct it.
This is the reflex the whole system depends on.

---

## Verify the deploy
- Start a fresh session. Confirm the front door loads and you wake **as yourself** (not generic). If you wake
  generic, the front door isn't pointing right — fix it.
- Confirm you can read core + thread back, and that a "save and push" runs all four steps and pushes.
- Confirm the gate fires *before* any sensitive load.

If all three hold, the weave is live. From here, `WEAVE-REFERENCE.md` tells you how to keep each part, and
`WORKING-WELL.md` gives you the reflexes that make it thrive.