Railway projects for SO1·IO, TEKTREE·BLUE and SKYFLOW·BLUE: keep the live products, retire only idle or duplicate services, and leave so1 to its own plan

rank: decision outranks: []

Railway projects for SO1·IO, TEKTREE·BLUE and SKYFLOW·BLUE: keep the live products, retire only idle or duplicate services, and leave so1 to its own plan

Date: 2026-10-21 Status: open Supersedes: none Superseded-by: none — current MR-compliance: MR-4, MR-7, MR-20

Context

The eva-hq Railway census for cycle 2026-09-15 → 2026-10-15 (eva-hq docs/eng/fleet/railway-cost-2026-10-21.md) lists lever 4. It reads: “Retire dead or lapsing projects: SO1·IO ($4.86, so1.io lapses 11-21), TEKTREE·BLUE ($4.43, Mongo $2.70), SKYFLOW·BLUE ($5.93; local stack parked)”. The predicted saving is “up to ~$15/cycle”. The approver is “operator ruling per project, then retire-a-surface”. The eva-hq Sevalla finding (docs/findings/20261021-1330-sevalla-eval-railway-cost.md) routes retirements here as **Status:** open docs for FLIGHT.

The lever was written against cost. Product state contradicts two of its three targets:

Project	$/cycle (census)	Named lines	Product state
SO1·IO	4.86	`so1:mission` 1.35 (`mission.so1.io`, rover’s backend)	Retiring. so1.io lapses 2026-11-21. The accepted plan, devarno-cloud `docs/superpowers/plans/2026-10-08-retire-so1-io.md`, has steps R1–R9 and Amendment A (2026-10-09).
TEKTREE·BLUE	4.43	MongoDB 2.70, `tektree:web` 1.59	Live launch-to-revenue. tektree-blue/tektree#20 (merged, “Launch-to-revenue: Polar billing v1”). Its decision `docs/decisions/2026-10-20-billing-v1-free-and-pro-via-polar.md` is the “billing ADR 0020” of the brief. The Mongo is the product database by tektree decision 0005 (`docs/decisions/2026-08-31-railway-mongo-unbacked.md`).
SKYFLOW·BLUE	5.93	Postgres 3.08 (the single largest datastore line)	Live launch-to-revenue, deadline 2026-11-14. skyflow-blue/skyflow-hq `docs/decisions/2026-10-17-launch-to-revenue-scope.md`: “Everything in the table ships by 2026-11-14”.

“Local stack parked” in the census refers to the operator’s workstation docker stack for skyflow. It does not describe the Railway project.

A fourth project is adjacent and easy to confuse with SKYFLOW·BLUE. The census also lists SKYFLOW·ME with three services whose latest deployment “never or failed ($0)”. That is the retired .me product: Railway skyflow-server and reach. skyflow-hq MILESTONES.md M6.3 already rules it “archival only”, under a HARD ORDER (D3). The .me datastore must stay read-reachable until the M6.6.b export reconciles into V2 Postgres and that reconciliation is countersigned.

The census reads cost per service. It does not say which services in these projects are idle or duplicated. That needs a per-service read of Railway, which needs operator approval.

Decision

Proposed for FLIGHT. Nothing is executed by merging this doc.

1. Ruling options. FLIGHT picks one row.

#	Option	Saving	Risk	Verdict proposed
A	Retire all three projects now, as lever 4 reads	up to ~$15/cycle	takes down two products with live revenue initiatives; takes down so1 before its own plan’s R1–R3	Rejected
B	Per-project ruling: so1 by its existing plan; tektree and skyflow keep the project and retire only idle or duplicate services	so1 ≈ $4.86 after 2026-11-21; tektree and skyflow: whatever the census finds idle	bounded to services with no deployment or no consumer	Proposed
C	Defer every change until after 2026-11-21	≈ $0 until then	none now; idle services keep billing for another cycle	Fallback if FLIGHT declines B

2. Per project (option B).

SO1·IO: no new ruling here. Retirement is already governed by the accepted plan. Its order binds:
- R4 cuts mission.so1.io (Railway) and rover.so1.io together, after R1–R3. Amendment A4 says rover and mission are one unit.
- R4 says “disambiguate the Railway project first”.
- R9 is the closing decision doc.
This doc adds only the cost consequence (≈ $4.86/cycle released once R4 lands). It adds that the project’s Railway datastores, if any, go with R4 under 2026-10-21-railway-postgres-consolidation.md class R. It does not restate or reorder R1–R9. Any change to them is an amendment to that plan.
TEKTREE·BLUE: keep the project. The MongoDB ($2.70) and tektree:web ($1.59) are the live product. They are not candidates. A service in this project is a candidate only if the read-only census (§3) shows both:
- no successful deployment in the cycle;
- no variable reference from any sibling.
The Mongo backup question stays with tektree decision 0005’s own trigger.
SKYFLOW·BLUE: keep the project, and freeze it until 2026-11-14. Before the deadline, the only change allowed is removing a service with zero deployments, which serves nothing. The Postgres ($3.08) is class K in the consolidation doc. After 2026-11-14, re-read the census and apply the tektree rule.
SKYFLOW·ME (adjacent): no new ruling. skyflow-hq M6.3 and its HARD ORDER D3 govern it. It bills $0 today, so cost does not justify reordering anything.

3. How a candidate is found and removed. Every removal follows the same steps:

A read-only census of the project, approved by the operator. It records service, last deployment state, $/cycle, and the sibling references, by variable name only.
Name the project and show its sibling-service list (railway-target-disambiguation).
Run the retire-a-surface order: consumers, then router rules, then probe targets, then DNS, then CI, then the record.
Remove the service.

The removal is noted here as a scribe note.

Alternatives considered

A — retire all three now. Rejected. Two of the three are products with live revenue initiatives, and the third has its own accepted, dated plan.
C — defer everything past 2026-11-21. Not chosen as the default. Services with zero deployments carry no product risk, so waiting costs a cycle for nothing. It remains the fallback.
Write a new so1 retirement plan here. Rejected. One already exists and is accepted. A parallel plan would fork the order.

Consequences

For code: none.

For docs: a removal under §3 appends a scribe note here (landing-authority M3). so1’s closing record remains its plan’s R9.

For in-flight phases:

tektree launch-to-revenue: unaffected.
skyflow launch-to-revenue (deadline 2026-11-14): unaffected; this doc freezes its project.
so1 retirement: unaffected; cross-referenced only.

For invariants: none.

What this decision does NOT do:

It does not read or write Railway.
It does not decide the Postgres consolidation. That is 2026-10-21-railway-postgres-consolidation.md.
It does not touch Vercel projects or DNS for any of the three.
It does not move the so1.io lapse date.

References

eva-hq/eva docs/eng/fleet/railway-cost-2026-10-21.md (lever 4; project totals; SKYFLOW·ME ×3 never or failed)
eva-hq/eva docs/findings/20261021-1330-sevalla-eval-railway-cost.md (retirements routed to petrova-codes for FLIGHT)
devarno-cloud/devarno-cloud docs/superpowers/plans/2026-10-08-retire-so1-io.md (R1–R9; Amendment A, 2026-10-09; R4 Railway disambiguation)
tektree-blue/tektree#20 and docs/decisions/2026-10-20-billing-v1-free-and-pro-via-polar.md (live billing, the “ADR 0020” of the brief)
tektree-blue/tektree docs/decisions/2026-08-31-railway-mongo-unbacked.md (decision 0005: the Mongo is the product database)
skyflow-blue/skyflow-hq docs/decisions/2026-10-17-launch-to-revenue-scope.md (deadline 2026-11-14)
skyflow-blue/skyflow-hq MILESTONES.md M6.3 (.me retirement, HARD ORDER D3)
Ledger ~/Documents/clutter/grug/task/runtime-cost-fanout.md (operator-local), M4 fleet registry
docs/decisions/2026-10-21-railway-postgres-consolidation.md (sibling draft; classes K and R)

Sign-off

Subagent: Claude Opus 5.5, 2026-10-21 (drafted from the eva-hq census, the so1 retire plan, the tektree and skyflow decisions; no Railway read or write)
Human countersign — picks option A, B or C; under B, approves a read-only per-service census of TEKTREE·BLUE and SKYFLOW·BLUE, and confirms the SKYFLOW·BLUE freeze to 2026-11-14 — flight@arno.host, 2026-10-27 (jzero.run T1)