AP127 Flight-Training Ecosystem

01Bird's-eye overview

Two independent data domains — Operations (what is flying, when, with whom) and Progress (how far each student has advanced) — are merged only at the presentation layer. Every site is a static front-end; all "backend" work is GitHub Actions cron jobs that commit data files into repos, plus four tiny Cloudflare Workers.

02The twelve websites

All reachable as of 2026-07-27 (DryRun answers 401 by design — it is password-gated). Plus one experimental optimizer (flight-scheduler) that is local-only and not part of the deployed set.

flight-scheduler — experimental optimizer (not deployed)

03Cloudflare Workers — 4 services

All free-tier, all in account ae38e04e56d0ae52d3ec47ad29977587.

ap127-data-api worker source

export default {
  async fetch(request, env) {
    const allowedOrigin = env.ALLOWED_ORIGIN || '*';
    if (request.method === 'OPTIONS') return new Response(null, { headers: {
      'Access-Control-Allow-Origin': allowedOrigin,
      'Access-Control-Allow-Methods': 'GET', 'Access-Control-Max-Age': '86400' }});
    if (request.method !== 'GET') return new Response('Method not allowed', { status: 405 });
    const data = await env.KV.get('ap127_slice', 'json');
    if (!data) return new Response(JSON.stringify({ error: 'No data' }), { status: 503,
      headers: { 'Content-Type': 'application/json' }});
    return new Response(JSON.stringify(data), { headers: {
      'Content-Type': 'application/json', 'Cache-Control': 'no-store',
      'Access-Control-Allow-Origin': allowedOrigin }});
  },
};

04Data sources & feeds

Operations feed → flight-data.js

A Google Apps Script web-app renders the academy Flight Operations Portal. The schedule lives in a JS object flightCache inside a sandboxed cross-origin iframe — so a headless Playwright browser is needed, not a plain GET.

Progress feed → cache.json

Google Sheets published as per-batch CSV, read through a second Apps Script relay (CORS bridge = the RELAY_URL secret).

const CSV_URLS = {
  AP124: "docs.google.com/spreadsheets/d/e/2PACX-1vRQK_to…/pub?gid=416854743&output=csv",
  AP126: "docs.google.com/spreadsheets/d/e/2PACX-1vQB8PiZ…/pub?gid=416854743&output=csv",
  AP127: "docs.google.com/spreadsheets/d/e/2PACX-1vQNxzCi…/pub?gid=416854743&output=csv",
};
function doGet(e){
  const url = CSV_URLS[(e.parameter.batch||"").toUpperCase()];
  if(!url) return json({error:"Unknown batch"});
  return ContentService.createTextOutput(UrlFetchApp.fetch(url).getContentText("UTF-8"))
           .setMimeType(ContentService.MimeType.TEXT);
}

runScheduler — greedy capacity simulator (not a fetch)

After parsing the CSVs, update-cache.js projects every student's future lessons forward to compute planned[] · finish · monthly.

05Auto-fetching mechanism

Pi-primary since 2026-09-02. The Orange Pi Zero 2W does the scraping; Cloudflare + GitHub Actions are the automatic fallback. Before that the roles were reversed.

The thresholds

Reliability features

Known gap — the Pi is not a full peer

The Pi runs the CMD_CTR scrape only. It has no equivalent for DB001's update-cache.js / build-student.js / push-to-kv.js, so the progress pipeline is still 100% cloud-dependent. A full Cloudflare/GitHub outage stops progress data even though flight data keeps flowing.

5.4  The Pi is shared hardware — it is also the house AirPrint server

Added 2026-09-03. The Zero 2W is not AP127-dedicated: it also runs CUPS, sharing a USB-attached Canon PIXMA E410 to every Apple device on the LAN as an AirPrint printer. This is deliberately the opposite of the 3D-printer rule (one board per printer) — a print queue is idle almost all the time, where Klipper is realtime.

Two CUPS settings that must stay set: IdleExitTimeout 0 — Debian's 60 s default lets socket-activated cupsd exit, which silently drops the Bonjour advert (the classic "AirPrint worked yesterday" failure); and systemctl enable cups for the service, not just the socket. Sharing itself is cupsctl --remote-admin --share-printers — note --remote-printers is not a valid cupsctl option and passing it aborts the whole command.

usblp0: removed / re-added pairs in dmesg bracketing a print job are normal — the CUPS usb backend claims the interface and releases it afterwards. Not a flapping cable.

06Telegram notification system — Watchdog

The Telegram system is entirely the ap127-watchdog Cloudflare Worker (repo CMDV2/watchdog/). No Telegram code exists anywhere else in the repos. It fetches AP-127 flights, diffs vs the previous snapshot, and sends one Telegram message per change to the affected student. Since 2026-09-06: cron */2 (was */5) plus a POST /notify push endpoint the Pi + CI call after a data publish, so a change reaches Telegram in seconds rather than on the next cron tick. It reads flight-data-recent.js straight from raw.githubusercontent.com (NOT the ap127-data Worker — a Worker cannot fetch a same-account *.workers.dev URL, CF 1042).

Message format (src/telegram.js)

✈️ New flight scheduled
SP: @username
📅 10 Jun 2026  08:00–09:30
📖 Lesson: CDGL 04
🛩 HS-NGT  |  FI: ITTIPOL P.

07Deployment

Sites — confirmed live (all 4 main = CF Pages Git build on push to main)

Workers

Confirmed Cloudflare ids & URLs

08Secrets & environment inventory

Values are never stored — this is where each secret lives and what it does.

GitHub Actions — DB001

GitHub Actions — CMD_CTR

Cloudflare Worker secrets/vars

09Reproduce from scratch

Order matters — later steps depend on earlier IDs/URLs.