Delete the Apple remote CI planning document
Intent: Remove the canonical living plan for Apple-host `pikaci` execution from the repository. This document governed the phased rollout of remote Apple CI — covering architecture decisions, lane ordering, safety constraints, network isolation requirements, and a planner/implementer contract. Its deletion cleans the `todos/` directory of this specification.
Affected files: todos/pikaci-apple-remote-plan.md
@@ -1,342 +0,0 @@
-## Spec
-
-This is the canonical living plan for Apple-host `pikaci` execution on owned hardware, with GitHub kept as a temporary outer trigger rather than the long-term CI platform.
@@ -1,342 +0,0 @@
-## Current Phase (2026-03-15)
-
-1. The current target architecture should be:
- - GitHub-hosted Linux runner as temporary trigger only
- - checked-in Apple remote wrapper script as the execution entrypoint
- - Mac mini or rented Apple host does the real work over SSH/Tailscale
- - the Apple host is not treated as a self-hosted GitHub runner
@@ -1,342 +0,0 @@
-## Phase 1: Thin Apple Remote Wrapper
-...
-## Phase 7: Reduce GitHub To A Replaceable Shell
The entire file todos/pikaci-apple-remote-plan.md is deleted (342 lines, deleted file mode 100644).
What the document contained
The plan defined:
- Architecture — GitHub-hosted Linux runner as a temporary trigger; a checked-in Apple remote wrapper script as the real entrypoint; Mac mini or rented Apple host doing actual work over SSH/Tailscale; the Apple host explicitly not a self-hosted GitHub runner.
- Lane ordering — Blocking:
pre-merge-pikachat-apple-followup; advisory:ios-ui-test; later advisory:ios-ui-e2e-local; Tart intentionally deferred. - Safety constraints — No reliance on same-LAN trust; network separation or relocation required before treating the Mac as an active CI host; preference for checked-in CLI/script contracts over GitHub YAML as source of truth.
- Eight phases — Phase 0 (scope lock & safety gate) through Phase 7 (reduce GitHub to a replaceable shell), each with explicit scope, acceptance criteria, review focus, and land-to-master guidance.
- Planner/implementer contract — A coordination model where a planning agent maintains the document and an implementation agent takes one narrow slice at a time, with review cycles after each slice.
Why this matters
Removing this document means the branch no longer carries the planning artifact. Downstream consumers that referenced this file for architectural guidance, lane ordering, or safety requirements will need to consult whatever has replaced it — whether that is implemented code, a different planning document, or institutional knowledge.
Key deleted sections at a glance
| Section | Purpose |
|---|---|
| Spec / Working assumptions | Architectural principles and constraints |
| Current Phase (2026-03-15) | Snapshot of active decisions and policy biases |
| Target Outcome | Definition of the first steady state |
| Phases 0–7 | Incremental delivery plan with acceptance criteria |
| Suggested First Implementation Slice | Concrete next-action guidance |
| Review Notes | Initial review state and identified risks |