FABRIC-3.6.md: correct the handoff for execution on a real toolchain

Captain Bob confirmed execution happens on his PC with the toolchain
installed, not in a container. Two lines of the handoff would have
misdirected the session they exist for.

Task 0.0 said it must be run by Captain Bob on a machine with the real
toolchain. On the intended machine the session can run it itself, and the
old wording would have had it wait for a human who was expecting it to
proceed. Now it says to run it, after verifying the toolchain is actually
present, and to stop and say so rather than improvise a partial test if
anything is missing. Adds a note that the unchecked state is
not-yet-attempted rather than a prior failure, since a fresh reader could
reasonably assume the latter.

The working-directory warning was written around this container's own
layout and named a path that will not exist on the target machine.
Replaced with the check that actually matters -- git remote -v must show
the Gitea repo -- keeping the container case as a parenthetical rather
than the headline.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VkM1zHGvBerLF6aqkHPweP

FABRIC-3.6.md

@@ -7,12 +7,11 @@
 >
 > **Where the code is.** This repo is **LithosAnanke, on the Gitea instance at
 > `gitea.strshipos.com`, repo `admin/LithosAnanake`** — Captain Bob has the credentials.
-> **Beware the session's default working directory.** This session was started in
-> `/home/user/StarForth` — a *different*, empty repo wired to an unrelated remote — and the
-> harness instructions named it as the build target. **It is not this project, and nothing
-> outside Gitea is.** If you land in a directory that is not a clone of `admin/LithosAnanake`,
-> you are in the wrong place: clone from Gitea and work there. `master` is the sole
-> production line. Work on branch **`claude/starshipos-tripod-kernel-reshuffle-itbjns`**
+> **Confirm you are in the right repo before anything else.** `git remote -v` must show
+> `gitea.strshipos.com/admin/LithosAnanake`. **Nothing outside Gitea is this project.** (The
+> handoff was authored in a container whose default working directory was a *different*, empty
+> repo on an unrelated remote — if you ever see that, you are in the wrong place.) `master` is
+> the sole production line. Work on branch **`claude/starshipos-tripod-kernel-reshuffle-itbjns`**
 > (head `2032974` at handoff, 34 commits ahead of `master` at `e56974e`, clean fast-forward,
 > documentation only — **no code has been written**).
 >
@@ -134,11 +133,16 @@ lockdown was never broken — wrong VM tested"). The baseline is what makes ever
 acceptance run interpretable, and the recorded `dict_hash` triple is the reference every
 subsequent §XXXIV.6 divergence check compares against.
 
-**Not runnable in the session that wrote this document, and deliberately not faked.** Checked
-2026-09-19 in the authoring container: **no `qemu-system-x86_64`, `-aarch64` or `-riscv64`; no
-`aarch64-linux-gnu-gcc` or `riscv64-linux-gnu-gcc`; no OVMF/AAVMF firmware.** Only host `gcc`,
-`clang` and `lld` are present. **Task 0.0 must be run by Captain Bob on a machine with the real
-toolchain**, and its result recorded here before task 0.1 begins.
+**Run it yourself — you are expected to.** Captain Bob confirmed (2026-09-19) that execution
+happens on his PC with the full toolchain installed, so **the session reading this can and
+should run task 0.0 directly**, once authorized. Verify first that `qemu-system-x86_64`,
+`qemu-system-aarch64`, `qemu-system-riscv64`, the aarch64/riscv64 cross-compilers and
+OVMF/AAVMF are all present; **if any are missing you are not on the intended machine — stop and
+say so rather than improvising a partial test.**
+
+*(Historical note: this document was authored in a container with none of that toolchain, which
+is why task 0.0 was written but never run. Do not take its unchecked state as a prior failure —
+it has simply not been attempted.)*
 
 ---