# SOP-JANUS-PEEK.md

**Owner:** Admin [00] · **Overseen by:** Master [10] · **Built by:** CC [100]
**Created:** 08/21/26 — USR369 direction
**Applies to:** all eleven systems — 00 10 20 30 40 50 60 70 80 90 95

Two commands. One looks, one lands. Neither closes anything.

---

## Quick reference

| Command | Question it answers | Writes? | Ends a session? |
|---|---|---|---|
| `PEEK` | "What is that system working on?" | **Never** | No |
| `JANUS` | "Write down where I am, and tell me what's next." | Yes | **No** |

`CLOSE` and `FINAL_CLOSE` are unchanged and still the only things that end a session.

---

# PEEK

**`GET backend/tools/critical/PEEK.php?token=[TOKEN]&system=[DECADE|all]`**

> **Path note (08/21/26):** `systems/commands/PEEK.php` 403s at the web-server level for
> any new file at that path (K391, Builder [20]) — real endpoint lives at
> `backend/tools/critical/PEEK.php`. Same applies to JANUS below.

Look into a system and report what it is working on, without disturbing it.

## When to call it

- USR369 asks what a system is doing
- Before assigning work, to see whether that system is already on it
- Checking whether a system closed properly
- `system=all` for a board across all eleven

## What it returns

Session status and age, COMMS registration, what the system is working on (from its handoff's
*last action*), what its handoff says to do next, open todo count, unread inbox count, and a
`concerns` list.

`needs_attention` collects only the systems with a real problem. Read that first.

## What it will flag

| Flag | Meaning |
|---|---|
| Shows OPEN since… | Sat open more than 24h — did not close properly |
| Handoff 2d / 3d old | Stale per SOP-HANDOFF. Over 72h, report to USR369 |
| Handoff is vague | Contains "Ready for direction" or "Clean close", or under 200 bytes. **A vague handoff is a failed handoff, not a working system.** |
| No "next session does first" | The handoff cannot be picked up cold |
| handoff-[decade].md missing | Gov file gap |

## Hard rules

1. **PEEK writes nothing.** No CHECKPOINT, no SYNC, no status change, no handoff touch, no
   session open or close. If a change to `PEEK.php` adds a write, it is in the wrong file.
2. **Never `action=pickup` on the inbox.** Pickup *resolves* messages — the target system
   would never see its own mail. Count only.
3. **PEEK reads server-side from disk**, so it does not increment the target's `read_count`
   or log to `file_events`. `read_count` is the only dashboard context signal that is
   server-counted rather than AI self-reported; filling it with observation traffic would
   make the dashboard lie about how much context that system has burned.
4. **Peeking is not permission to act.** See a problem in another system? Report it to
   USR369. That system owns its own files.

---

# JANUS

**`POST backend/tools/critical/JANUS.php`** (see path note above — `systems/commands/` 403s)

Land the work so far, then hand back what to do next. **Named for the god of doorways** —
one face looking back at what just happened, one looking forward at what's next.

## When to call it

**Any point. Mid-task is the main case.** USR369 gets pulled away and needs the work written
down so that coming back is fresh rather than archaeology. He should never have to reconstruct
where he was from memory.

Also valid when a task genuinely finishes.

**Only USR369 calls it.** Never run it on your own initiative.

## What it must never do

- **Never close a project, a task, or a session.** It records *position*. It does not declare
  anything finished.
- **Never run `CLOSE.php`.** Never set `status=closed` or `session_locked=1`.
- **Never prompt USR369 to close.** Closing is always his call.

If you are about to do any of those, you have the wrong command.

## Two modes — name which one, out loud, before writing

**FINISHED** — the task is genuinely done. Record what changed and what it delivered.

**IN FLIGHT** — pulled away mid-task. Record **position**:

- what is done and verified
- what is **done but unverified** — written, not tested, not deployed
- what is **half done**, in which file, at which function or line
- what you were about to do next, in one concrete sentence
- **anything held only in the conversation and written nowhere** — decisions made, options
  ruled out, dead ends already explored. This is the part lost forever if skipped, and the
  part that makes USR369 redo work he already paid for.

**Never guess "finished." If unsure, it is IN FLIGHT.** Marking something complete that isn't
is the one error here with real cost: the next session reads "done", skips it, and the work
quietly disappears.

## Sequence

**Face one — behind**

1. Take stock; declare FINISHED or IN FLIGHT
2. Move any deliverable out of scratch to its real home — a file left in scratch is not delivered
3. Record anything durable to the memory pipeline
4. `CHECKPOINT` (GET)
5. `SYNC` (GET)
6. Append to `ARTIFACTS-[DECADE].md` and `LEGACY-[DECADE].md`
7. Rewrite `handoff-[DECADE].md` — substantive, or CHECKPOINT will reject it
8. Push any staged outbound transfers
9. Drop a short report to the system's inbox. **Do not touch comms status.**

**Face two — ahead**

10. Gather from: inbox (`action=list` only), `todo-[DECADE].md`, the handoff's next-first line,
    `directive-[DECADE].md`
11. **Verify before recommending.** Check live state before naming the top item — reads are
    not blocked, so there is no excuse for a stale pickup. A version number is a claim, not
    evidence.
12. Rank. **If IN FLIGHT, the resume point is item one, always** — named file, named function,
    next concrete action. Do not bury it under something that scores higher.
13. Write the pickup into the handoff so it survives the session.

## Jurisdiction

**JANUS records and hands off. It does not do another system's job.**

If work was genuinely done inside another system's files, step 9's inbox drop to that system
is **mandatory** — it is the whole point. A silent cross-system edit is how two sessions end
up believing different things about the same file.

Work found that belongs to someone else goes in the pickup **with their name on it**. Report
it. Do not absorb it.

## Why JANUS is not a pure PHP command

The valuable part — what happened, what is half done, what to resume — is judgment. PHP cannot
write it. `JANUS.php` therefore takes content the AI session composed and does the plumbing:
validates the required fields, refuses vague content, writes safely, runs the sync steps, drops
the inbox message.

Precedent: `CHECKPOINT.php` already fails a handoff containing "Ready for direction". JANUS
enforces the same standard at write time instead of after the fact.

---

## Write discipline (JANUS only)

- Safe write on every live gov file: **temp → rename.** Never write in place.
- `approved_by = USR369` on every write that takes it.
- **Verify every write by reading it back.** A 200 is not proof the content landed.
- If a write is blocked, log it to the blocks record and hand USR369 the command. Do not
  silently route around a denial, and do not report a blocked step as done.

## Honesty

A partial JANUS reported honestly is useful. A clean-looking report over a failed write is
worse than no report, because it will be believed.