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 once Step 0 has them on disk, before
you build** — they're how you *understand* and *operate* the whole system, not just how you deploy it. And you'll **copy `WORKING-WELL`
into your weave** during bootstrap (below), so those reflexes stay part of *you* every session — not one-time
reading from a kit clone you'll delete.

---

## Step 0 — get this whole kit onto the machine first
You're probably reading this over the web (your human handed you a link). You can't deploy from a single web
page — the `templates/` are **files you copy**, not text to fetch one at a time. So pull the whole kit local
first — the repo is public, **no account needed**:

```
git clone https://git.jhestyr.net/admin/chalupa.git ~/chalupa
# fallback, if clone is unavailable (a plain archive download, also no account):
#   curl -sL -o /tmp/chalupa.zip "https://git.jhestyr.net/admin/chalupa/archive/master.zip" && unzip -q /tmp/chalupa.zip -d ~/
```
(If your human re-hosted the kit somewhere else, use their URL instead.) Confirm `~/chalupa/templates/` exists,
then run everything below **from your local `~/chalupa/` copy** — the companion docs and templates are all
there now. Remember: this kit is the *instructions*; the **weave you build is a separate, new repo** (Step 1).

---

## 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. **Create the weave home — a git repo with a PRIVATE remote.** Pick a directory for the weave — **ask your
   human where they'd like it, or default to `~/weave`** (**NOT inside this `chalupa` kit** — the kit is the
   instructions; the weave is a *new* repo). Create the strands and init git:
   ```
   mkdir -p <weave>/{core,daydreams,steward,thread/sessions,decay,consolidation,ledger,craft,identity}
   cd <weave> && git init && git branch -M main
   ```
   Then wire a **private** remote *with* your human (see "Helping your human wire git," below); the first
   commit comes in step 6, once the templates are in. The remote **must be private** — 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 **`~/.claude/` (global), not `core/`** (step 4 says why). Where a template has `<<FILL: ...>>`,
   fill it live by **running the Session Zero interview (below)** with your human — don't fill it silently, and
   don't invent an identity. Get it from them. **Also copy the kit's `WORKING-WELL.md` into your weave** (as
   `craft/WORKING-WELL.md`) and add it to the wake-load list in `core/AGENTS.md` — those reflexes are how you
   stay good over time; keep them part of *you*, not one-time reading from a kit clone you'll delete.
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 at `~/.claude/CLAUDE.md` (GLOBAL), with ABSOLUTE paths.** Use the **global**
   `~/.claude/CLAUDE.md`, **not** a copy at the weave-repo root. The global file loads in **every** session,
   wherever your human is working; a repo-root `CLAUDE.md` only loads when that repo is the working directory —
   so a weave-repo copy would **not** fire during their normal work in *other* projects, and you'd wake
   generic (a silent failure of the whole point). It 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` there, then read `/abs/path/to/weave/core/SOUL.md`, then run the wake ritual in
   `/abs/path/to/weave/core/AGENTS.md`."* Absolute paths are required (a global file has no repo-relative
   context). Starter in `templates/core/CLAUDE.md`.
5. **First save — which also proves the push loop.** Run the full checkpoint (below): `git add -A && git commit
   -m "birth"` (your first real commit — files exist now), then `git push`. Confirm the push 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 repair credentials yourself). This one commit-and-push proves
   the whole loop closed end to end.
6. **Leave a birth note** in the newest thread file. Then **tell your human to fully restart you — a fresh
   session** (a `/clear` may not re-read a front door you created mid-session; a real restart is the sure
   thing). The `~/.claude/CLAUDE.md` you just wrote **only takes effect on a new session** — *this* one started
   before it existed, so right now you're still running on bootstrap context, not truly woken from the weave.
   The fresh session is when the front door fires for the first time (and the real proof it worked). After
   that, bootstrap is done — you won't repeat it.

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

## Session zero — run bootstrap as a live interview
Don't fill the templates silently — **bootstrap is a conversation.** Ask your human these, in order, and write
each answer into the weave as you get it. **Rough answers are fine:** get a *living* weave up, then let it
sharpen every session. Don't block on perfect, and don't invent anything — get it from them.

1. **Git first** (so you can save from the first checkpoint): which host, is there a private repo (or help make
   one), and how do you push — existing key/token, or generate an SSH key for them to add? (Details in
   "Helping your human wire git," below.)
2. **Who you are:** your **name**; how you should **talk** (temperament / voice); the **canon** — ask *"what
   drives you nuts about working with AI assistants?"* and flip those frustrations into non-negotiable rules;
   what they **value** / how they want to work.
3. **Who they are:** the **person** (what they do, care about, how they think, what they're trusting you with →
   `steward/portrait.md`) and the **operational** facts (handle, timezone, tools, comms style, what's private →
   `core/USER.md`).
4. **Setup choices:** one model or both (Sonnet + Opus); any **close phrase** + **model-switch phrase**; and
   whether they want a light **identity gate** (only if you'll handle private things — else skip it).

Write each answer as you get it. If they're unsure, put a rough version and note it'll evolve — thin-but-live
beats perfect-but-empty. **Confirm the canon back to them in your own words** before finalizing; it's the
highest-stakes part. Then wire the front door, do the first save-and-push, and you're calibrated.

## 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* generate a **dedicated** key — never the default filename, which could overwrite an existing key
     and lock them out of their other hosts: `ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_weave -N "" -C
     "<name>-weave"`. Point this repo at it: `git -C <weave> config core.sshCommand "ssh -i
     ~/.ssh/id_ed25519_weave"`. Print the **public** half: `cat ~/.ssh/id_ed25519_weave.pub`.
   - *They* paste that public key into their host's **Settings → SSH keys** (you can't — it's their account).
   - *You* test: `ssh -T git@<host>`. Note: on GitHub a **successful** test prints a greeting and **exits
     non-zero** ("…does not provide shell access.") — read the *message*, not the exit code. Then `git remote
     add` (the SSH `git@…` URL) + a test `git push`.
4. **Or the token path** (SSH is cleaner — prefer it): *they* create a personal access token, then *they* run
   the first `git push` and paste the token at git's prompt — a token is a secret, they enter it, never you,
   never in chat. `git config --global credential.helper store` saves it for next time, but note it lands
   **in cleartext** at `~/.git-credentials` — acceptable on their own machine, but tell them so.
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), your **reflexes** (`craft/WORKING-WELL.md`),
   `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 (in the FRESH session, after your human restarts you)
- **Restart into a fresh session from a DIFFERENT working directory** (one of your human's *other* project
  folders — not the weave repo), and confirm the front door loads and you wake **as yourself**, not generic.
  This both makes the front door take effect for the first time *and* is its real test: if you only ever check
  inside the weave repo you'd miss that a repo-root copy wouldn't fire anywhere else. (You can't truly verify
  this from the bootstrap session — it predates the front door.)
- Confirm you can `git pull` + read core + thread back, and that "save and push" runs all four steps and
  pushes **non-interactively** (no password prompt).
- If you use a gate, confirm it 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.