WWW apps

WWW routing & execution

Flow: Browser → Nginx → static response OR PHP-FPM handler. Configured proxies/fallbacks reach an app process. PHP and static are capabilities of the same WWW hosting group.
Storage · reads / writes: Nginx reads web files; PHP can read and write app state. Storage boundaries belong to each handler, not to the hosting category.
Accounts · session boundary: No universal WWW login. Browser accounts are enforced by individual apps; PHP-FPM runs with a server process identity.
Security · known limits: Exact dispatcher and denial rules protect selected paths. HTTPS and successful static delivery do not establish application authorization.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Identify the hostname and matching Nginx location before changing a route.
Separate shipped files from mutable state and keep a recovery copy.
After scoped publication, verify the exact static URL and intended handler response separately.

Diagram: WWW routing & execution connections

01
A browser requests a hostname and path.
02
Exact locations and matching rules decide the response path.
03
Static files return directly. PHP uses PHP-FPM. Unmatched getfrom.net paths can reach router port 3010.
04
A successful static page does not prove the PHP or router branches work.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

getfrom.net has explicit directory routes, including /trogdordata/ and /flightaware/.

Still unknown

PHP application transactions were not run.

Source references

services/remote/nginx/nginx.conf
services/local/ansible/enginex.yml
services/local/ansible/php.yml

Notes

Flow: Browser → public editor or private PHP dispatcher → Markdown + metadata. A private share grants access to one resolved note.
Storage · reads / writes: Note bodies and metadata persist under WWW; private writes use locks and atomic replacement. Documented history is outside webroot, on the same host.
Accounts · session boundary: Admin password authorizes management requests. Public visibility/edit rules are metadata-dependent. Private-share password allows reading and saving one note; it cannot list notes or manage sharing.
Security · known limits: Private dispatcher containment, no-store API responses and hashed share verification are in source. Share links confer access: handle them privately. Live enforcement and history freshness untested.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Preserve bodies, metadata and private share material together in a protected recovery copy.
Check history timestamps and restore a copy in isolation before relying on it.
After an authorized change, verify reader, admin and single-note recipient boundaries with test content; never use real notes as probes.

Diagram: Notes connections

01
Public and private editors have separate implementations and access rules.
02
The private editor uses one exact dispatcher; Nginx blocks other files under that private route.
03
The apps write Markdown bodies and metadata. The private handler includes locking and atomic replacement helpers.
04
The READMEs describe Git history outside the web root. This is same-host recovery, not proof of an off-host backup.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

The old blanket implication that private files are openly served is wrong: explicit Nginx denial rules exist.

Still unknown

Live enforcement, history freshness and isolated restore remain untested. Account/share mechanisms were read in source on 11 Sep 2026.

Source references

www/notes/README.md
www/notes/api_notes.php
www/notescksecreteditor/README.md
services/remote/nginx/nginx.conf
services/local/ansible/backup.yml; services/local/sync/backup_rsync.sh
www/notescksecreteditor/cksecreteditor.php

WWW files & publication

Flow: Local WWW files → scoped SSH sync → Trogdor webroot → Nginx; PHP executes only through matching routing rules.
Storage · reads / writes: Code, uploads and edited documents coexist. Remote-only state may be newer than the workstation.
Accounts · session boundary: Host transfer credentials deploy files; each application defines its own reader/editor account boundary.
Security · known limits: No-delete sync preserves extras but does not detect conflicts. Selected backup scope is configured; freshness and restore are unknown.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Compare remote and local targets before editing.
Exclude user data from code replacement; retain an independent recovery point.
Preview and push exact changed files; compare hashes and clean public URLs.

Diagram: WWW files & publication connections

01
This workstation controls the local www tree.
02
www-sync.sh accepts exact relative files or folders and preserves newer mtimes.
03
Nginx serves approved paths from the remote www tree.
04
Uploads and application state can share this tree. Do not replace the entire tree as disposable output.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

The earlier claim that the sync helper had incorrect paths and old profile assumptions is superseded by current code.

Still unknown

Shared backup scripts cover selected legacy paths, not every application described here. Freshness and restore remain unverified.

Source references

www/README.md
services/local/sync/www-sync.sh
services/remote/nginx/nginx.conf
services/local/ansible/backup.yml; services/local/sync/backup_rsync.sh

EUC uploads

Flow: Phone uploader → PHP upload → chunk merge → hosted CSV → browser or separate GitHub Pages consumer.
Storage · reads / writes: Ride CSV and upload chunks live in the EUC web subtree. These are source data, not disposable build output.
Accounts · session boundary: Uploader and data reader are distinct roles. A durable per-user session boundary was not established from the inspected handlers.
Security · known limits: Backup tools include EUC, but freshness is unknown. The rsync backup can mirror deletions; an archive and tested restore are separate evidence.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Keep original ride logs until uploaded data and merges are verified.
Before replacing files, preserve CSV and any incomplete chunks; compare row counts and file sizes.
Check both local consumer and external Pages data URLs after a data change; test recovery using a copy.

Diagram: EUC uploads connections

01
The EUC PHP entrypoint accepts uploaded files.
02
remergeChunks.php assembles uploaded chunks.
03
Ride data lives in the EUC web subtree.
04
The parent www README records a separate GitHub Pages consumer of the hosted data.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

The rsync backup uses --delete. The Ansible path creates a tar archive of selected directories.

Still unknown

Backup schedule, latest successful copy and restorability were not verified.

Source references

www/euc/index.php:96
www/euc/remergeChunks.php:45
www/README.md
services/local/ansible/backup.yml; services/local/sync/backup_rsync.sh

Soccer + Spotify

Flow: Browser → static clubhouse + PHP API → Spotify. Server projects selected fields into the public weekly list.
Storage · reads / writes: Private runtime stores listening history, display state and OAuth tokens outside WWW. JSON saves use temporary files and rename.
Accounts · session boundary: Coach management is intentionally open. Spotify account consent uses authorization-code OAuth; a short PHP session binds callback state, while access/refresh tokens remain server-side.
Security · known limits: Same-origin checks on writes and Secure/HttpOnly/SameSite OAuth cookies are in source. OAuth authorizes Spotify access; it does not create a coach login.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Preserve private history and curated state before changing imports.
Check the requested week against retained history; recent-provider feeds are not a complete backfill.
Inspect public output for curated fields only; check provider connection separately. Import completeness and restore remain unverified.

Diagram: Soccer + Spotify connections

01
Static pages show the selected public state.
02
Nginx dispatches soccer API and callback requests to one PHP handler.
03
Application code stores state and listening history in a private runtime directory.
04
Selected display fields become the public weekly list; imported history is not the public list.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

Code uses a temporary file and rename for persisted JSON. The README describes an intentionally open coach management surface.

Still unknown

Current provider connection, history completeness, backup freshness and end-to-end importing were not tested.

Source references

www/soccer/README.md
www/soccer/api/lib.php
services/remote/nginx/nginx.conf
www/soccer/api/index.php

Termux control plane

Flow: Admin UI → PHP queue → phone polling worker → supported local command → result acknowledgement.
Storage · reads / writes: Queue, device and event JSON live in the app tree. Writes use temporary JSON and rename; source contains multiple script/API copies.
Accounts · session boundary: Admin API uses a shared password; worker API checks a server-stored token. Phone OS permissions form a separate execution boundary.
Security · known limits: Token checking is present in source. The active deployed copy, device permissions and live enforcement are unknown; queued or accepted is not completed.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Identify the active worker/API pair before updating scripts.
Preserve queue/device state and protect credentials in a separate recovery copy.
For a separately authorized harmless job, follow queue → claim → execution → acknowledgement; do not mark completion from enqueue alone.

Diagram: Termux control plane connections

01
The admin API writes queued work.
02
The agent API stores queue and device information.
03
A phone polls for work and executes supported commands.
04
The agent can return results. Current device connectivity was not checked.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

Queue writes and result handling exist in source. Multiple script and API copies exist.

Still unknown

Admin password and worker token checks exist in source. Active copy, deployed enforcement, phone permissions and execution success remain unknown.

Source references

www/termux/README.md
www/termux/agent_api.php
www/termux/agent_admin_api.php
www/termux/agent_api.php; www/termux/agent_admin_api.php

GetFrom API

Flow: Browser/client → api.getfrom.net → PHP front controller → selected handler; some handlers contact external services.
Storage · reads / writes: Handlers read/write their own files. The front controller does not establish one shared data or recovery boundary.
Accounts · session boundary: Authentication is handler-specific. A complete inventory of user roles, provider credentials and session enforcement is unknown.
Security · known limits: Routing and file writes are source-confirmed. Do not treat hostname separation or CORS as authorization.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Identify the specific handler and every data file it touches before changing it.
Preserve that handler’s state and configuration; keep credentials outside published evidence.
Verify response shape with a non-mutating request only after checking that the handler has no read-side writes.

Diagram: GetFrom API connections

01
Nginx uses the www/api root for api.getfrom.net.
02
Unmatched paths fall back to index.php.
03
Application handlers implement the requested operation.
04
Several handlers write files. The full write boundary is not inventoried here.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

Current source contains file-writing handlers.

Still unknown

Authentication, permissions and live transactions were not audited across all handlers.

Source references

services/remote/nginx/nginx.conf
www/api/index.php
www/api/api_notes.php
www/api/api_termux.php

Legacy AACC path app

Flow: Browser → legacy /aacc/ Nginx route → PHP/static handlers. Faculty Creator uses a different root and process.
Storage · reads / writes: Legacy handlers write JSON and content; some integrations call external APIs with server-side credentials.
Accounts · session boundary: Per-handler account roles and session boundary remain unknown. Faculty login must not be assumed to cover this legacy path.
Security · known limits: Separate routing is confirmed. Current usage, retirement intent and recovery coverage are not established.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Identify the active legacy handler and consumers before removing or replacing files.
Preserve authored content and JSON separately from code.
Check the exact legacy route after a scoped change; verify Faculty independently if shared links changed.

Diagram: Legacy AACC path app connections

01
Nginx has specific rules for the legacy path.
02
The web-root application serves legacy content.
03
Several PHP handlers write application files.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

The legacy path and Faculty hostname have separate Nginx routing.

Still unknown

Retirement intent, active usage and data recovery are unknown.

Source references

services/remote/nginx/nginx.conf
www/aacc/index.php
www/aacc/cta100_api.php:180
www/aacc/slideshow.php

Showerthoughts

Flow: Browser → PHP reader/editor → thoughts JSON and activity log.
Storage · reads / writes: Saves rewrite thoughts.json in place. Editor events append to a separate log.
Accounts · session boundary: Editor uses a shared-password request check. No durable user session was established by this source review.
Security · known limits: Credential handling needs private review. Concurrent edits and restore are untested; logs and authored thoughts need different retention.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Preserve the current thoughts document before edits or deployment.
Validate JSON and compare entry counts in the recovery copy.
Review log retention privately; test a restore in isolation before replacing live content.

Diagram: Showerthoughts connections

01
The app handles reading and editing.
02
The save function writes thoughts.json in place.
03
The app appends editor events to a separate log.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

The inspected save function uses an in-place JSON write.

Still unknown

The old claim that a CMS copy is a second authoritative store was not established. Restore and concurrent writes were not tested.

Source references

www/showerthoughts/index.php:16
www/showerthoughts/index.php:50

Todos

Flow: Browser task actions → PHP → read task JSON → apply change → write JSON.
Storage · reads / writes: Tasks and completion history persist in data.json beside code. Saves use LOCK_EX; initial state may be created on access.
Accounts · session boundary: An individual-account/session boundary was not established in the inspected handler. Treat the access policy as requiring confirmation.
Security · known limits: A write lock exists, but does not cover the whole read-modify-write transaction. Concurrent safety and restore are unknown.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Preserve task JSON before code replacement; do not overwrite it with seeded data.
Validate the recovered document and compare task/completion counts.
Use an isolated copy for concurrent-edit and restore checks before relying on the write lock.

Diagram: Todos connections

01
The client requests task actions.
02
The handler reads the task document and applies changes.
03
write_data uses file_put_contents with LOCK_EX.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

The earlier claim that there is no locking evidence is corrected: LOCK_EX is present.

Still unknown

A write lock alone does not prove the entire read-modify-write operation is safe. Restore was not tested.

Source references

www/todos/index.php:8
www/todos/index.php:26

Ping telemetry

Flow: Client request → PHP metadata extraction → CSV append. A visit itself records telemetry.
Storage · reads / writes: Telemetry accumulates in app-local CSV; flock protects the append operation.
Accounts · session boundary: The caller is a telemetry source. Operator read access and any application login boundary remain unverified.
Security · known limits: Append locking is present. Privacy scope, download intent and retention are unknown; no live probe was made.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Identify retention and intended readers before sharing or archiving logs.
Preserve required records separately from application code.
Validate a copied CSV and rotation procedure offline; do not use live visits as read-only verification.

Diagram: Ping telemetry connections

01
The handler extracts request metadata.
02
The code uses flock around CSV writes.
03
The log accumulates records in the app directory.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

The source has an append lock. No live request was made because even a read-like visit can write telemetry.

Still unknown

Retention policy, intentional download access and recovery needs are unknown.

Source references

www/ping/index.php:30
www/ping/index.php:39

CookieQR

Flow: Browser login → PHP → URL token → account QR data reads/updates.
Storage · reads / writes: Account records and QR settings share a JSON document; edits and password changes rewrite it.
Accounts · session boundary: Account ID/password check precedes token-based navigation. Token integrity and credential storage need private review; no secure session guarantee is established.
Security · known limits: Live authorization, concurrent saves and restore are unverified. Keep account exports and token-bearing links private.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Preserve account/QR JSON securely before updates.
Review authentication privately before adding sensitive data.
Validate a recovery copy and compare QR targets; test account separation only with authorized test records.

Diagram: CookieQR connections

01
The client uses the app workflow.
02
The route reads and updates application state.
03
Source contains file writes for persisted data.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

JSON writes are present in the inspected code.

Still unknown

Public/private intent, concurrent write behavior and restore are not verified.

Source references

www/cookieqr/index.php:103
www/cookieqr/index.php:170

Images + signatures

Flow: Browser → signature upload PHP → image file; image tracking requests → CSV records.
Storage · reads / writes: Shipped images, authored uploads and tracking CSV have separate lifetimes. Source checks image type and normalizes chosen names.
Accounts · session boundary: Uploader, image recipient and log reader are distinct roles. An account/session boundary is not established here.
Security · known limits: Image checks exist; they do not establish a complete access policy. Live validation, log privacy and retention remain unknown.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Preserve authored uploads before replacing generated or shipped images.
Review recipient and tracking-log visibility before distributing links.
Verify image dimensions and representative rendering without invoking tracking URLs; test restore on a copy.

Diagram: Images + signatures connections

01
Source files provide reusable public images.
02
PHP accepts uploaded signature media.
03
Files and tracking records have different lifetimes.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

Upload and tracking writes exist in source.

Still unknown

Validation, retention and recovery were not established by this review.

Source references

www/images/index.php
www/images/signatures/index.php:82
www/images/signatures/track.php:30

N213CD FlightAware

Flow: Browser ← Nginx static files; browser → Airplanes.live API and OpenStreetMap tiles. No PHP is needed for the inspected page.
Storage · reads / writes: Track samples and recording preference persist in browser localStorage. Static deployment does not preserve that browser history.
Accounts · session boundary: No application login in the inspected page. Provider requests originate in the visitor’s browser; external services receive those requests.
Security · known limits: Leaflet resources have integrity attributes; other external dependencies remain. Provider availability and recorded track completeness are unknown.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Export a wanted track before clearing browser storage or changing devices.
Preserve the page and dependency references before deployment.
Check map loading and export behavior with non-sensitive sample data; inspect failures separately from server delivery.

Diagram: N213CD FlightAware connections

01
www/flightaware/index.html is present.
02
Nginx maps /flightaware/ directly to index.html.
03
Assets under the route use static-file lookup.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

The configured directory route bypasses the router.

Still unknown

Provider availability, track completeness and browser-data recovery remain unverified. Current page source fetches live data and stores tracks in browser localStorage; no server generator is needed for that flow.

Source references

services/remote/nginx/nginx.conf
www/flightaware/index.html

FeelsGoodGoods

Flow: Browser → dedicated Nginx hostname/root → HTML and linked destinations.
Storage · reads / writes: Inspected entrypoint is static content. No mutable application store was established.
Accounts · session boundary: No login in the inspected entrypoint. Linked sites enforce their own accounts; server transfer access is separate.
Security · known limits: Vhost supports PHP, which does not mean this page executes it. Dynamic use and deployed revision remain unknown.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Preserve edited HTML and linked assets.
Check relative links under the dedicated hostname after scoped publication.
Compare served bytes to intended files; identify any dynamic handler before treating the entire folder as replaceable.

Diagram: FeelsGoodGoods connections

01
www/feelsgoodgoods contains the site pages.
02
The hostname has its own root and index fallback.
03
Static files can return directly; the vhost also has a PHP handler.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

PHP is configured; that does not show that the site needs PHP.

Still unknown

Dynamic use, live parity and any data store remain unverified.

Source references

services/remote/nginx/nginx.conf
www/feelsgoodgoods/index.html

OpenSCAD catalog

Flow: Browser → static catalog → models/models.json and referenced model artifacts.
Storage · reads / writes: Browser fetches the catalog and artifacts; no catalog writer was established. Authored models must be retained separately from generated previews.
Accounts · session boundary: No account/session flow in the inspected catalog. Publishing credentials belong to the operator, not catalog visitors.
Security · known limits: Model and manifest revision alignment matters. Generator ownership and rebuildability of every artifact remain unknown.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Preserve original models before regenerating previews.
Validate manifest references and check that every changed artifact exists.
After exact-path publication, open representative models and compare manifest/artifact hashes.

Diagram: OpenSCAD catalog connections

01
www/openscad/index.html is the inspected entrypoint.
02
The page presents model and artifact references.
03
Existing files can be served from the shared web tree.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

A catalog page exists; this review did not establish a running catalog writer.

Still unknown

Generator ownership, revision and rebuildability of every artifact are unknown.

Source references

www/openscad/index.html
services/remote/nginx/nginx.conf

Karpati Law campaign

Flow: Browser → campaign hostname → Nginx → lawoffice/campaign files with index fallback.
Storage · reads / writes: Routing establishes a file root, not the absence of writes. Application storage and external submissions are unknown.
Accounts · session boundary: Account roles and login/session behavior have not been established from application code.
Security · known limits: Only configured routing is established; publication revision and application security remain unknown.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Read the campaign implementation and identify forms/external recipients before modifying data flows.
Preserve source/assets and any discovered submission store.
Use its owning publication path; verify exact page/assets rather than accepting an index fallback as proof.

Diagram: Karpati Law campaign connections

01
The configured root is lawoffice/campaign.
02
Nginx serves files and an index.html fallback.
03
campaign.karpatilaw.com has explicit routing.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

The route is configured; configuration does not prove current deployment revision.

Still unknown

Publication process, live parity and any application writes remain unknown.

Source references

services/remote/nginx/nginx.conf

PM2

PM2 lane

Flow: Nginx → app listener; PM2 supervises the process. Project roots own code; services owns startup configuration.
Storage · reads / writes: Process restarts do not recover files or databases. Faculty, router and chatbot have watch disabled in the recorded runtime.
Accounts · session boundary: PM2 runs under the host operator. Visitor sessions and provider tokens are owned by each application.
Security · known limits: Recorded 11 Sep: router, faculty, edge-review and chatbot online; Recaps absent. Faculty entrypoint and EDGE name drift from configuration.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Reconcile the intended name, cwd and entrypoint against the actual process before reload.
Identify app state and preserve it independently of code.
For an authorized runtime change, verify the specific listener and public route after restart; online alone is insufficient.

Diagram: PM2 lane connections

01
local/ansible/pm2.yml calls the shared wrapper as Carlos.
02
ecosystem.sh runs startOrReload using the ecosystem file, then saves the process list.
03
Live snapshot: router, faculty, edge-review and easyjobappschatbot are online. Recaps and staging are absent.
04
Hostname proxies reach the configured application ports; process state alone is not a route test.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

Live PM2 was queried only after confirming an existing daemon. EDGE name and Faculty entrypoint differ from local configuration.

Still unknown

No restart or reload was performed. App internals were not fully exercised.

Source references

services/remote/pm2/ecosystem.config.js
services/remote/pm2/ecosystem.sh
services/local/ansible/pm2.yml

Telegram / Recaps Robot

Flow: Public Recaps request → recorded 302 → replacement site. The old PM2 app is parked and absent from the 11 Sep snapshot.
Storage · reads / writes: Retained Telegram project data was not inspected. Its freshness and recovery remain unknown.
Accounts · session boundary: No active Recaps login was established. Historical bot credentials and replacement-site accounts are separate concerns.
Security · known limits: Parking discards old paths and queries. A remaining origin proxy stanza does not prove an active public app.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Preserve retained source/state before any separately authorized retirement work.
Verify the redirect destination and handling of an ordinary deep link after a parking-rule change.
Do not restart the historical process merely because an old proxy stanza exists.

Diagram: Telegram / Recaps Robot connections

01
The public root and a www deep-link were checked.
02
The observed redirect leads to charleskarpati.com. The September 5 parking note records a fixed 302.
03
Old paths and queries are discarded by the documented parking rule.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

The canonical telegram block is commented out. No telegram app appeared in live PM2. Old origin proxy configuration remains.

Still unknown

Retained data freshness and restore are unknown. An origin proxy stanza is not evidence of an active public app.

Source references

services/remote/pm2/ecosystem.config.js
services/Agent/Profiles/shared/trogdor-status.md — RecapsRobot parked
services/remote/nginx/nginx.conf

Easy Job Apps

Flow: Website → GitHub Pages publisher. Separately: client/provider → chatbot hostname → Nginx → Trogdor relay on 3016.
Storage · reads / writes: Pages publishes dist. Relay configuration puts state and environment outside webroot; frontend replacement is not relay recovery.
Accounts · session boundary: Website user accounts and relay/provider authentication are separate. Relay implementation is unavailable locally; exact session/token enforcement remains unknown.
Security · known limits: Recorded relay online with watch disabled. Latest Pages deployment, domain mapping and provider round trips remain unverified; no staging process in snapshot.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Check the Pages workflow for website changes; do not publish that website into WWW by assumption.
Preserve relay state before changing its service code.
Verify website release and relay behavior independently; delivery success does not establish provider receipt.

Diagram: Easy Job Apps connections

01
Nginx proxies chatbot.easyjobapps.com to port 3016.
02
easyjobappschatbot was online, with watch disabled.
03
The canonical configuration points data outside the web root.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

The website workflow builds and publishes dist to GitHub Pages. The current ecosystem and live app list do not contain the formerly claimed staging process. The website README still mentions Nginx; that statement conflicts with current workflow and routing.

Still unknown

The latest successful Pages deployment, current custom-domain mapping and any staging deployment were not checked. A running relay does not prove provider round trips.

Source references

services/remote/pm2/ecosystem.config.js
services/remote/nginx/nginx.conf
pages/easyjobapps/.github/workflows/pages.yml

Faculty Creator

Flow: Browser → Nginx → Faculty Node server → Canvas using the teacher’s token. Creator and legacy WWW AACC are separate.
Storage · reads / writes: Creator keeps sessions and Canvas tokens in server memory; course logs persist to private-mode JSON. Curriculum and generated/runtime files need separate preservation.
Accounts · session boundary: Canvas validates the supplied teacher token. Browser receives a random session cookie; server revalidates Canvas identity and expires sessions.
Security · known limits: Source sets HttpOnly/SameSite=Lax and Secure on HTTPS. Recorded live entrypoint is server.js; configured creator/server.js is absent locally. Feature enforcement untested live.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Preserve curriculum originals and required course/runtime records before release.
Reconcile PM2 entrypoint drift before an ecosystem reload; expect memory sessions to end on process restart.
Verify Creator and Canvas identity with authorized test data separately from route health; isolate any restore.

Diagram: Faculty Creator connections

01
The project root is aacc/faculty, separate from the legacy www/aacc path.
02
PM2 faculty runs src/web/server.js. That file exists locally; the configured creator/server.js path does not.
03
Faculty and legacy AACC hostnames proxy to the same port.
04
A bounded Trogdor-local /creator/ request returned HTTP 200.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

Live PM2 is online with watch disabled. Canonical entrypoint drift is explicit, not silently corrected.

Still unknown

Session and Canvas logic was read in server-core.js. Live feature behavior, full storage inventory and recovery remain untested; future ecosystem reload requires drift review.

Source references

services/remote/pm2/ecosystem.config.js
services/remote/nginx/nginx.conf
aacc/faculty/src/web/server.js
aacc/faculty/src/web/server-core.js

EDGE reviewer

Flow: Browser → Nginx → Python review server → selected source context → model provider; response returns with source references.
Storage · reads / writes: Server reads review files and writes chat logs; selected page access can regenerate a viewer. Generated artifacts are not original evidence.
Accounts · session boundary: Provider API key stays server-side. A chat session identifier groups conversations; it is not evidence of a user login.
Security · known limits: Source bounds request size and blocks the chat-log path. Complete reader authorization is unverified. Live PM2 name edge-review differs from configured edge.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Preserve original review files and apply a private retention policy to chat logs.
Identify the running process before reload; avoid starting a duplicate named edge.
Verify generated pages and cited source paths after changes; do not infer provider success from a local fallback answer.

Diagram: EDGE reviewer connections

01
aacc/edge owns the review server and content.
02
The live PM2 cwd matches the split project root.
03
edge-review is online. Selected source paths are watched.
04
The hostname proxies to the review server; a local root request returned 200.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

The configured name and live name differ. This review did not start a second process or rename the existing one.

Still unknown

Chat/context and logging code was read; account enforcement and deployed revision remain unverified. No chat or generated-page request was exercised.

Source references

services/remote/pm2/ecosystem.config.js
services/remote/nginx/nginx.conf
aacc/edge/tools/run_review_server.sh
aacc/edge/control-room/server.py

Containers

Container lane

Flow: Ansible → user systemd → pinned Compose wrapper → rootless Podman. Nginx proxies requests to the service listener.
Storage · reads / writes: Receptionist mounts host data; PDF declares no application data volume. Honcho remains a separately managed Docker stack.
Accounts · session boundary: Host user owns rootless containers. Provider credentials and visitor access remain application-specific.
Security · known limits: Recorded 11 Sep: both Podman services running and local checks returned 200. Calls, conversion, boot recovery and restore untested.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Identify the services-owned stack and exact service before changing an image.
Preserve bind-mounted data and private environment separately from image inputs.
Verify mount mapping, listener and public route; schedule a separate functional and restore test when authorized.

Diagram: Container lane connections

01
podman.yml prepares the user runtime and builds the services images.
02
services-containers.service runs the stack under Carlos. The unit was active at review time.
03
podman-compose.sh selects /usr/bin/podman-compose by default and invokes the shared Compose file.
04
services_pdflatex and phone_receptionist were running. Honcho is outside this stack.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

Both Podman containers were up; both bounded local HTTP checks returned 200.

Still unknown

A health response does not prove a complete call or PDF conversion. Boot recovery and restore were not tested.

Source references

services/remote/podman/podman-compose.yml
services/remote/podman/podman-compose.sh
services/local/ansible/podman.yml

Phone receptionist

Flow: Twilio call/webhook → Nginx → Podman app ↔ realtime model provider. Review browser → app → saved intakes.
Storage · reads / writes: Host data mount contains SQLite intake storage and text log; records can include transcripts and provider recording references. Deployment excludes data and environment.
Accounts · session boundary: Reviewer username/password produces an application cookie. Twilio, model and notification credentials are server-side provider roles, separate from reviewers.
Security · known limits: Review routes check the cookie; HttpOnly and SameSite are in source. Session hardening and provider request validation need private review. Health 200 is not a call test.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Preserve SQLite with a consistent database backup plus needed logs/configuration; do not copy a changing database blindly.
Check recording retention separately from local intake retention.
After an authorized release, verify review access and a synthetic call separately; restore into isolation before trusting recovery.

Diagram: Phone receptionist connections

01
The application is designed for Twilio webhooks and media traffic.
02
call.karpatilaw.com proxies to a loopback-bound host port by default.
03
phone_receptionist serves the application inside the container.
04
Compose maps an application data directory to /app/data.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

The container was up and its local /health endpoint returned 200.

Still unknown

No phone call or login was exercised. SQLite/intake behavior and reviewer cookie checks were read in application source; deployed parity, retention and restore remain unknown.

Source references

services/remote/nginx/nginx.conf
services/remote/podman/podman-compose.yml
services/local/ansible/podman.yml
lawoffice/phone_receptionist/receptionist_app/app.py; receptionist_app/storage.py

Router + PDF engine

Flow: Client → Nginx → PM2 router → Podman PDF engine → PDF response. Execution crosses two processes.
Storage · reads / writes: Compose declares no PDF application data volume. Temporary compilation files and retention across the full chain remain unverified.
Accounts · session boundary: Caller authorization is not established by the proxy. Host/container identities are separate from a browser session.
Security · known limits: 11 Sep checks established listeners and root responses only. They did not prove document conversion, isolation or temporary-file cleanup.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Preserve router/backend code and build inputs; identify temporary storage before a runtime change.
Verify the router and backend listeners independently.
When conversion testing is authorized, use a synthetic document and check status, PDF type and nonempty output; never send private documents as probes.

Diagram: Router + PDF engine connections

01
Selected unmatched requests reach the router.
02
router/index.js defines PDF compile and pandoc proxy endpoints.
03
The services_pdflatex container handles backend work.
04
The router returns the result to the requester.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

Router and PDF container were running; bounded root requests returned 200.

Still unknown

A full PDF conversion, build revision and temporary-file retention were not tested.

Source references

services/remote/nginx/nginx.conf
services/remote/pm2/ecosystem.config.js
services/remote/podman/podman-compose.yml
router/index.js:25
router/index.js:108

Honcho memory

Flow: Client → Honcho API/deriver → PostgreSQL and Redis in a separately managed Docker stack.
Storage · reads / writes: Database stores and cache durability need a database-specific review. Actual mount coverage was not established.
Accounts · session boundary: Client authentication, workspace roles and service tokens remain unknown in this review.
Security · known limits: 11 Sep snapshot showed containers running and database/cache health. It did not prove account isolation, backup freshness or restore.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Identify the separate stack owner and database mounts before touching deployment.
Confirm database backup scope and Redis durability requirements.
Restore a retained database into isolation and verify expected records before calling recovery proven.

Diagram: Honcho memory connections

01
Client applications can use the memory service.
02
Live Docker lists API and deriver containers.
03
Database and Redis containers were running and reported healthy.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

The separate Docker stack was observed without inspecting environment secrets or user memory.

Still unknown

Mount coverage, backup freshness, Redis durability and restore success are unknown.

Source references

services/README.MD
services/local/ansible/podman.yml
Live Docker container-name/status snapshot — 2026-09-11

System

Shared change checklist

Source review: 11 Sep 2026 · Runtime observations: earlier 11 Sep snapshot · Procedures are guidance, not completed checks.

Change checklist: shared boundaries

Identify the owner, active runtime and exact destination.
Separate mutable state from shipped code; retain a recovery copy.
Preview and publish only intended paths. Sync is not backup.
Compare local, remote and served bytes; verify the affected route.
Use isolated test data for authorized account, write or restore tests.

Optional flow diagrams, films & recovery exercise · Evidence key

VS Code SFTP sync

Flow: Editor or scoped helper → SSH → remote files. Browser delivery is a separate Nginx step.
Storage · reads / writes: Copies application files; newer mtimes win. It neither merges conflicting edits nor retains versions.
Accounts · session boundary: Operator SSH key via the configured agent/profile. This host login grants transfer access; it is separate from application users.
Security · known limits: Exact paths and no mirror deletion limit the helper’s scope. The editor extension can handle deletes; its watcher remains untested.

Procedure: preserve, recover & verify changes

Guidance only · not performed or saved task state.

Fetch the target into a temporary directory and compare both copies.
Retain a rollback copy; preview only intended paths.
Push the exact allowlist, then compare local, remote and served hashes.

Diagram: VS Code SFTP sync connections

01
The documented login service loads an encrypted SSH key into the GNOME keyring agent.
02
services/local/sftp generates repository profiles with an explicit SSH-agent bridge.
03
Natizyskunk handles save and delete events when enabled. www-sync.sh uses rsync over SSH for scoped manual delivery.
04
Compare local, remote and served bytes. An SSH connection alone does not test the VS Code extension.

Evidence: source review & recorded checks · 11 Sep 2026

Previously recorded evidence · 11 Sep 2026

The current helper supports profile lists and nested profiles, repeated --path arguments, and no mirror deletion.

Still unknown

The VS Code upload/delete watcher was not exercised in this review. Mtime-based sync does not resolve content conflicts.

Source references

services/local/notes/1.2 ddns.md
services/local/sftp/update_sftp_configs.sh
services/local/sync/www-sync.sh

← System overview

FIELD GUIDE / WATCH · TRACE · TRY

Follow the work.
Find the boundaries.

You can understand this system without memorizing every project. Start with a visitor, meet the people and tools behind the scenes, then protect what users create.

THE ONE-MINUTE ORIENTATION

Listen before you explore

Synthesized narration · September 2026 corrected content

Press play for narration. The transcript is available below.

Read the full audio transcript

Welcome to Trogdor. Think of the workstation as a workshop, and the public host as a small city. Three journeys matter. Delivery moves application files. Requests reach Nginx, which can serve a file, pass work to PHP, or route to an application. User edits and uploads create state that must survive the next delivery. Sync copies changes. It does not, by itself, keep a recoverable past. A backup needs retained recovery points and a tested restore. This guide is a dated observation, not live telemetry. Faculty and EDGE still have differences between intended configuration and observed runtime. Open their records for the details.

THE VISITOR'S JOURNEY

A crossroads, not a conveyor belt.

Nginx selects a route. A static file, a PHP handler and a Node application are different ways to answer a request. The visitor does not pass through all three.

MANIM ANIMATION · Silent, captioned visual explainer · Illustrative, not live telemetry

Transcript & visual description

0–8 seconds: a visitor asks for a URL; a parcel reaches Nginx and three possible destinations appear.

8–20 seconds: the illustration traces a static-file response, a PHP-FPM handler and a Node router response separately.

20–24 seconds: the response returns to the visitor. These are alternative routes, not three stops in a chain.

Sequence diagram showing three alternative Nginx response paths. The text equivalent follows. — **Trace the conversation · Mermaid**Download SVG Open image ↗

Follow a real branch: WWW apps · Router / PDF · FlightAware static route

BEHIND THE CITY GATES

Who builds it? Who runs it?

Projects own application behavior. The services repository owns shared host controls, grouped by function. Trogdor is where the public apps execute.

Project, shared services and Trogdor runtime lanes. Honcho has a separate Docker lane. Full explanation follows. — **Ownership and execution lanes · Graphviz / DOT**Download SVG Open image ↗

THE MAP AND THE STREET DO NOT FULLY MATCH

Keep intent and observation side by side.

Recorded discrepancies · 11 September 2026
App	Intended config	Observed runtime
Faculty	`src/web/creator/server.js`	`src/web/server.js`
EDGE	PM2 name `edge`	PM2 name `edge-review`

These are preserved findings, not fixes performed by this guide. Recaps is parked. The Easy Job Apps website has a separate publisher from the Trogdor chatbot.

How delivery works · PM2 details · Container details

WHAT MUST SURVIVE

The city has a memory.

Uploads, edits, JSON files and database volumes change while an app runs. Treat them as user state. Shipping code and retaining a recoverable past are different jobs.

MANIM ANIMATION · Silent, captioned visual explainer · Illustrative, not live telemetry

Transcript & visual description

0–4 seconds: local and remote application copies appear alongside separate user state.

4–10 seconds: a bad local edit is copied to the remote file. Sync has reproduced the mistake.

10–14.5 seconds: a separately retained earlier copy offers a possible recovery point.

14.5–24 seconds: the restore arrow remains a question. A retained copy must be tested; this illustration does not establish backup freshness or a successful restore.

TRY THE IDEA / SYNTHETIC DATA ONLY

Can a successful copy preserve a mistake?

Use the buttons in order. These example files live only in this page’s memory.

WORKSTATIONGood draft · v1

TROGDOR COPYGood draft · v1

RETAINED EXAMPLEGood draft · v1

Both copies are good. The retained example is separate from sync.

This demonstrates the distinction. It does not inspect or modify real files, prove a backup exists, or perform an actual restore.

Three questions before touching state

Which files or volumes can users change?
Will delivery preserve those changes?
Which retained version has actually passed a restore test?

For this review, backup freshness and restore remain unverified. Locking a write protects a different boundary: Todos uses LOCK_EX; Ping uses flock. Neither is a backup.

Explore writable web state · Notes boundaries · Honcho storage

Evidence key & authorship

This is a hand-maintained explanation of existing projects. It does not configure or monitor services. The services repository and each owning project remain authoritative.

Repo-verified: Supported by inspected local source or configuration.
Live-verified: A specific process, container or response was observed on 11 Sep 2026. Read the scope in each record.
Proposed: An idea for later work; no implementation is implied.

Backup freshness and successful restore were not verified. No private records or credentials are included here.

Author: Codex app agent · 11 September 2026

Operations index ↑