1
Package the relay
Create the standalone project and platform-neutral skill source.
- Publisher and verifier scripts
- Public-content warning in skill instructions
The short version
At a glance
Outcome
A stable HTTPS hub at plans.weatherboysuper.com, with one folder per plan, title and timestamp cards, and a direct link returned only after live verification.
Why now
The fairgrounds week creates a phone-only review window. The existing T3 Code connection keeps agents reachable, but local HTML files are stranded on the laptop without this relay.
Decision made
Use a dedicated subdomain backed by the existing VPS: Hostinger DNS points plans to 145.79.2.154; Nginx serves a static docroot; Certbot supplies HTTPS; SSH/SCP publishes each plan. Public hosting means secrets and sensitive personal data must be excluded.
Boundaries
Scope
Included
- Shared `plan-relay` skill for Codex and OpenCode.
- Self-contained HTML validation and public-safety guardrails.
- SSH/SCP upload, index regeneration, SHA-256 comparison, and HTTP checks.
- Responsive hub with title, timestamp, and direct plan links.
Not included
- Private authentication or per-plan access control.
- Automatic upload of every HTML file without agent intent.
- Changes to GFC, T3 Code, unrelated Nginx sites, or DNS beyond this subdomain.
- Publishing content that contains credentials or private data.
The path
Phases and deliverables
2
Install agent behavior
Make the same workflow discoverable globally in Codex and OpenCode.
- Codex skill copy
- OpenCode skill copy
3
Prepare the VPS
Separate the plan hub from existing sites and put it behind the intended host name.
- Nginx docroot and server block
- Hostinger A record and Let’s Encrypt certificate
4
Publish the first artifact
Upload this plan, regenerate the index, and prove the public path works.
- Direct plan URL
- Hub listing with title and UTC timestamp
5
Use during the week
Every future human-facing plan ends with the same publish-and-verify handoff.
- Return exact `PLAN_URL`
- Keep local copies as the source of truth
Reasoning
Decisions and assumptions
Why a subdomain
It gives the plan hub a memorable, separate phone entry point without changing the existing weatherboysuper.com site or requiring a path-specific reverse proxy.
Why static files
Static HTML keeps the VPS surface small: no database, runtime, login service, or background process is required for reading plans.
What remains public
Anyone who has the URL can read the hub and plans. The skill treats this as a public share and blocks common placeholder/secret mistakes, but it cannot infer every sensitive detail.
What could change the plan
Risks and dependencies
Risks
- Public disclosure: a plan may include more repository detail than intended.
- Stale browser DNS: a local resolver may lag behind Hostinger; authoritative checks are useful during setup.
- SSH drift: a changed key or VPS path would stop publishing rather than produce a false link.
Dependencies
- Existing SSH access to root on 145.79.2.154.
- Hostinger DNS for weatherboysuper.com.
- Nginx and Certbot on the VPS.
- A self-contained HTML artifact that passes plan validation.
Proof of completion
Verification
| Checkpoint | Evidence | Status |
|---|---|---|
| VPS docroot | Nginx serves `/var/www/plans.weatherboysuper.com` through a dedicated server block. | Complete |
| DNS | Hostinger A record: `plans` → `145.79.2.154`. | Complete |
| HTTPS | Certbot certificate issued for `plans.weatherboysuper.com`. | Complete |
| First plan | Publisher returned HTTP 200 for hub + plan and a matching SHA-256 hash. | Complete |
Critique checklist
- Can the hub be opened quickly from a phone and scanned with one thumb?
- Does each link make its timestamp and title obvious?
- Is the public-content warning visible before a plan is published?
- Does the agent report a verified link instead of a guessed path?