[TRACKING] Epic #26 — single ownership of the Appwrite environment

[Polichinel]

Tracking checklist for #26 — [EPIC] Establish single ownership of the Appwrite environment.

Cross items off as they land. The order below is the implementation order; dependencies are noted where they constrain it.

Checklist

• views-appwrite#27 · S1 — Contract states the single-writer rule · needs-decision
  No dependencies. Blocks S3 and S5. Amends the contract directly rather than convening a þing — the operator can override that call, in which case the epic waits.
• views-models#308 · S2 — Registry resolution must fail loud (C-47)
  No dependencies. Do this first among implementation items — the relative sibling hop is the single thing most likely to break the next machine set up.
• views-pipeline-core#377 · S4 — model_path.py:371, the surviving library dotenv load · needs-decision
  Independent. A genuine judgment call, filed as one: self.root/".env" may be a legitimate entry point. What must not happen is that it survives because nobody looked — which is how it survived #346.
• views-appwrite#28 · S6 — Prove the two registry_to_env.py copies agree (C-50)
  Independent. Does not challenge the two-copies decision — that is WET-before-DRY correctly applied. Adds the missing check.
• views-models#310 · S7 — Make the 131 generated run.sh explicit as clones
  Independent. Not deduplication — they do not touch Appwrite, and CRP says leave them apart. One header line so the duplication is visible.
• views-models#309 · S3 — tools/platform_env.sh: one writer (C-48)
  Depends on S1 + S2. The centre of the epic. The extraction is not the point; the contents are — it must not source .env for coordinates.
• views-faoapi#349 · S5 — Resolve the 7 coordinates from the registry
  Depends on S1. Reduces this repo's .env to one secret.
• views-models#311 · S8 — bootstrap.sh, CI-tested without credentials
  Depends on S2 + S3. The epic's real test. Hard constraint: if it needs arguments or a companion document, the structure underneath is still wrong.
• S9 — The onboarding guide's [Internal Tech Guide] link is empty docs#82 · S9 — The onboarding guide's [Internal Tech Guide] link is empty
  Depends on S8. Documentation last, deliberately — by then the setup path is a program that must work.
• views-faoapi#350 · S10 — views-crafdapi adopts the pattern at birth
  Depends on S5. Filed in views-faoapi because the clone has no tracker yet; move it when it gets one.

Completion criteria

The epic is done when all ten boxes are ticked and:

• Exactly one writer per class of value — registry owns coordinates, operator owns the secret; a second writer errors rather than losing silently
• No importable library loads a .env anywhere on the platform
• Registry resolution failure exits non-zero; no warn-and-continue
• views-faoapi's .env requires one variable
• bootstrap.sh green in CI with no real credentials — and followed end-to-end on a machine that had never run the platform, with every failure recorded rather than worked around
• The onboarding guide's technical pointer resolves
• views-crafdapi never acquires a second .env habit
• Both registry_to_env.py copies proven to emit identical output

Not this epic — cross-linked, not re-scoped

views-faoapi#337	Extract the credential/partition contract to views-appwrite. Gated on þing-01 D8, which is views-appwrite#23. Those two are the same decision from opposite sides. views-crafdapi existing now satisfies one of #337's two trigger conditions; #23 is the other
views-pipeline-core#339	The Appwrite eviction epic, Phases 0–2
views-models#298 / #299	Liveness .env; .gitignore gaps
views-postprocessing#187	Registry drift detection

Already shipped — verified against current HEADs, not assumed

views-pipeline-core#346 (find_dotenv deleted, preflight everywhere, AppwriteConfig frozen) · views-faoapi#322 and #323 (both in v1.4.0) · views-appwrite#13 (conformance vector).

The finding this epic rests on

Two mechanisms write coordinates into the process environment. The registry wins because it runs second. Against Rust's stated definition of a data race — two or more pointers to the same data, at least one writing, no synchronising mechanism — all three conditions hold.

That reclassified the problem from tidiness to correctness, and it is why the system was hard to hold in your head: its ownership is genuinely undefined. The seam contract §2 already mandates the fix; the shell layer structurally cannot express it, having no parameter passing to child processes — only the global environment.

[Polichinel]

Closing as a stale tracking twin of #26 — the relationship #74 had to epic #66, closed on the same reasoning two days ago.

A checklist that mirrors an epic goes stale the moment the epic moves, and this one has: every box on it is wrong. Verified by opening each linked issue rather than reading the list.

Story	Issue	Actual state
S1 — contract states the single-writer rule	views-appwrite#27	CLOSED 2026-08-02 as unnecessary — the rule is §4; PR #30 withdrawn
S2 — registry resolution fails loud	views-models#308	CLOSED
S3 — platform_env.sh, one writer	views-models#309	CLOSED
S4 — the model_path.py dotenv load	views-pipeline-core#377	CLOSED
S5 — faoapi resolves coordinates from the registry	views-faoapi#349	OPEN, but the work shipped — deployment/bootstrap.sh writes .env.faoapi as registry coordinates + one operator secret
S6 — the two readers agree	views-appwrite#28	CLOSED
S7 — mark the generated run.sh as clones	views-models#310	OPEN — genuinely outstanding
S8 — bootstrap.sh CI-testable	views-models#311	CLOSED
S9 — the empty [Internal Tech Guide] link	views-platform/docs#82	OPEN — fix the target before the link

9 of 10 shipped. Two issues remain open in other repos, one of which (S5) appears to be finished and simply not closed.

Why this is closed rather than updated

This checklist cost something. I audited it instead of the issues it links, and concluded S1 was undone — then added a contract clause that had been withdrawn eleven days earlier, and raised an obligation floor on it. Both struck the next day (appwrite-seam-v1.7.1).

A tracking issue whose rows are stale is worse than no tracking issue, because it reads as evidence. The epic is the record; #26 carries the corrected table.

Tracking continues there.