I did not ask Codex to “build my app.” I gave it a goal.

How two GPT‑5.6 Sol sessions, one Peter-style execution loop, and a phone helped me turn MatchDay into a verified production release

Try MatchDay: matchday-v3-fawn.vercel.app
Read the application source: mzidan000/matchday-v3
Use the exact Peter hybrid skill: peter-hybrid-autonomous-execution-loop

Both core build sessions used Codex CLI with the exact recorded configuration gpt-5.6-sol and reasoning effort set to max. During the build, I shortened that to “Codex 5.6 Sol Max.” It is simply my shorthand for that model-and-reasoning combination—not the name of a separate model.

The second, resumed goal existed for approximately 25 hours and 56 minutes of wall-clock time. Within that window, Codex’s /goal tracker recorded 72,506 seconds—20 hours, 8 minutes, and 26 seconds—against the goal before it reached VERIFIED. I am not claiming that the model generated continuously for 20 hours. The number is the tracker’s execution total across a long sequence of planning, implementation, tool calls, test runs, review cycles, deployment gates, and my steering between slices. I reviewed progress, corrected decisions, and let the loop continue only while it was producing new evidence toward the release gate.

For part of that work I was not sitting at my laptop. I connected to it from my phone through Tailscale and Termius, watched the Codex CLI, answered the important decisions, and monitored progress from wherever I was—watching FIFA games in fan zones, jogging with friends, walking by the marina, biking, or just doing normal daily things. Safe, pre-authorized work sometimes continued overnight while I slept; in the morning I checked the goal tracker, reviewed the evidence, and steered the next slice. That was my own remote setup, not an official Codex mobile feature. What mattered was that the work could survive a long run, an interrupted connection, and a new session without restarting from zero.

This is the story of how that worked—and also where it did not work until I corrected the process.

First, an honest boundary

MatchDay did not begin as a blank prompt in these two sessions. I had built earlier versions for previous hackathons. They proved the basic idea: one football fan should be able to plan a match trip without opening separate tabs for fixtures, flights, hotels, maps, weather, and stadium timing.

What I used Codex and GPT‑5.6 to build here was the much deeper MatchDay v3 transformation:

a persistent MemoryAgent that can learn from verified behavior across sessions without treating every chat message as permanent truth;
a durable Autopilot that can recover after interruption, invoke typed tools, detect conflicts, repair a plan, and independently verify the result;
evidence-gated provider and seller handoffs that do not call a generic or zero-result page “verified”;
an owner-isolated FastAPI/PostgreSQL backend on Alibaba Cloud behind a signed Vercel facade;
a coherent product experience with multi-turn chat, ranked packages, provenance, an interactive map, Stadium Lens, immutable trip versions, and safe sharing;
adversarial security remediation, cross-browser QA, real PostgreSQL concurrency tests, load checks, deployment, and production canaries.

The production travel agent uses Qwen Cloud at runtime. Codex with GPT‑5.6 was my engineering system: it read, planned, implemented, tested, attacked, reviewed, recovered, deployed, and proved the release. Those are different roles, and I do not want to blur them.

The prompt was not the important part. The loop was.

The skill I used was my hybrid version of a Peter-style autonomous execution loop. Its core is simple:

One goal. One persistent tracker. Small evidence-producing slices. Attack your own work. Fix what is real. Stop only when the defined proof passes.

But the real skill is more than a repeated prompt. While preparing this article, I had Codex reread all seven files—990 lines covering the main loop, verification gates, hardening gates, scenario patterns, recovery and parallelism rules, artifact templates, and agent metadata—and check this explanation against them. The exact version used for this build is now included in this repository, not merely summarized here: open the skill.

Here is what happens inside it.

1. Define the observable finish line

Before changing code, Codex converts my request into a behavioral contract. I called the final numbered release checklist Q11–Q24; in plain language, it covered the remaining product work, security remediation, full release QA, deployment, and production canaries. “Done” did not mean that a feature existed or that a unit test passed. It meant:

the remaining Q23 security remediations were closed;
the final clean-revision scan found no known validated in-scope finding;
Q24 backend, AI evaluation, memory, provider, PostgreSQL, browser, accessibility, security, load, recovery, migration, observability, build, and rollback gates had executed;
the exact verified revision was deployed;
production smoke tests and canaries passed;
the evidence matched the deployed revision.

That contract prevented an early “looks done” exit.

2. Keep a tracker that survives the conversation

The loop maintains a factual tracker with status, completed steps, blockers, next actions, and proof. A summary is treated as a claim, not as truth. On every resume, Codex checks the current repository, diff, tests, and runtime before trusting it.

That became critical when the first session was interrupted. It was not a Codex failure or a defect in MatchDay: the tmux/server connection used by my remote phone setup dropped. I opened a new Codex session, supplied the previous Session ID privately, and pointed it to the evidence handoff. The new session first rechecked the tracker, Git state, diff, and failing regression; only then did it resume from the exact unfinished boundary. The handoff did not merely say “continue Q23.” It recorded the delivered boundary, the uncommitted files, the failing regression, the clean and invalidated test results, the remote refs, and the next safe command.

3. Scale the work to uncertainty—not to how long the model can run

I repeated one instruction because it mattered to me:

If a task really takes five minutes, finish it in five minutes. If it needs an hour, use an hour. Do not turn a five-minute fix into three hours of ceremony.

The loop chooses the smallest complete slice that can produce trustworthy evidence. It avoids speculative frameworks and redundant reruns. A clean test is not repeated unless a relevant file, configuration, environment, or data boundary changed.

Long-running autonomy should not mean endless activity. It should mean persistent progress toward a stop condition.

4. Write the failure before the fix when possible

For a defect, Codex first tries to reproduce the user-visible failure. The expected result comes from the product contract, not from the implementation being tested.

This mattered when I showed it two concrete problems:

the UI displayed a saved home airport of YUL while chat claimed that no preference existed and continued planning from YVR;
a flight action could open a generic or blocked page instead of exact route/date results.

Codex did not just patch those screenshots. It expanded them into source-blind contracts for memory capture, persistence, retrieval, correction, deletion, cross-session reuse, trip replanning, exact route/date/party binding, stale evidence, redirects, corrupted history, and zero-result fallbacks.

5. Attack the result instead of proofreading it

This is the part of the Peter loop I value most. “Attack” does not mean attacking the product or writing dramatic criticism. It means trying to disprove your own completion claim:

Did I actually read every required file?
Does the test fail without the change?
Can a stale URL, duplicated query, malicious provider response, or wrong date still pass?
Did the browser really exercise the application, or did the harness fail before reaching it?
Is a claimed performance improvement measured, or only inferred from source?
Is the evidence current after the last material change?

During the flight-handoff slice, this phase found that public provider HTML could appear to certify itself, duplicate query parameters could drift, and a clicked July 19 flight could be rejected because the API used the trip’s July 18 start date. Each accepted finding became a regression and a smaller root fix.

6. Review a frozen revision, then review the successor—not a moving target

Non-trivial changes were frozen and independently reviewed. A finding was not accepted because a reviewer sounded confident; Codex reproduced it against the real path first. Verified findings were fixed, invalid findings were rejected with evidence, and affected gates ran again.

The bounded rule we eventually settled on was:

One independent review per frozen revision. If it finds a verified defect, fix it and review the new revision, up to three cycles. When clean, land it and continue.

That “eventually” matters. My first rule allowed exactly one review total. When the review found a real defect, the code was fixed—but the new revision could not be declared clean or landed. The goal kept colliding with its own authorization boundary.

I changed the rule. We kept review strict, but made it convergent. This was a human process decision, not something I wanted Codex to silently reinterpret.

7. Ship evidence, not reassurance

The loop ends with commands, runtime behavior, browser proof, review findings, hashes, or an explicit blocker. “Should work” is not a release verdict.

Reuse the exact skill

The repository includes the complete skill contract and its six companion reference/metadata files. To install it in Codex:

git clone https://huggingface.co/mzidan000/matchday-codex
mkdir -p ~/.codex/skills
cp -R matchday-codex/peter-hybrid-autonomous-execution-loop ~/.codex/skills/

Then invoke $peter-hybrid-autonomous-execution-loop for a bounded, non-trivial goal. The skill explicitly requires right-sized effort: it should finish a five-minute task in roughly five minutes, while allowing difficult release work to continue only as long as new evidence is moving toward the defined stop condition.

Two sessions, one recoverable goal

The first core session began on July 13. The final Q11–Q24 goal inside it started on July 17 and recorded 24h 4m 45s of goal execution before the remote tmux/server interruption forced me to move the work into a new Codex session. At that boundary:

Q11–Q22 were delivered;
Q23 remediations 1–2 were delivered;
remediation 3 still had a real unlanded regression;
remediations 4–17, the final scan, Q24, deployment, and canaries remained.

The session produced the detailed handoff instead of pretending the goal was complete.

The last turn was interrupted. Three minutes and 24.847 seconds later, Session 2 started. Its first useful work was not coding. It identified the prior session, loaded the handoff, compared it with the live tracker and Git state, and found that the temporary worktree had lost its .git pointer and 36 tracked paths while the four unfinished source files remained intact.

Codex restored the worktree metadata and missing paths from the delivered revision without rewriting the unfinished source. It then reran the current gates before continuing. That recovery is one of my favorite parts of the build because it shows why persistent execution needs more than a large context window.

I started the resumed /goal at 2026-07-19 07:32:25 UTC. It completed at 2026-07-20 09:28:34 UTC with 72,506 seconds—20h 8m 26s—of tracked goal time.

Across the two core intervals, the final branch contains 103 commits: 77 from Session 1’s interval and 26 from Session 2’s completion-goal interval. I do not use that number as a proxy for quality; small atomic commits were part of the review and rollback strategy. The more meaningful evidence is what those slices closed.

What Codex actually did during the long run

This was not one giant generation. It was a sequence of bounded loops.

Workstream	What Codex executed	What made it evidence rather than a claim
MemoryAgent	Repaired manual and autonomous memory source-of-truth behavior, current-message precedence, correction, deletion, disablement, bounded recall, cross-session reuse, and trip replanning	Source-blind memory and chat regressions, lifecycle evals, browser reload checks, tenant isolation, and production add/reload/delete/reload canary
Flight handoffs	Bound actions to the exact route, date, party, flight, seller, freshness, and safe URL; failed closed on generic, stale, blocked, corrupt, or zero-result pages	Valid/empty/mismatch/stale/redirect/corrupt contracts plus the real YUL→JFK browser path
Security	Completed all 17 queued remediations, then ran six independent review passes over the same 81-file deployed surface and fixed three additional verified findings	Reproduction, regression, smallest fix, affected/full gates, bounded independent review, final clean scan
Spatial experience	Repaired Stadium Lens and Explore Map loading, degraded states, keyboard parity, focus restoration, responsive behavior, animation controls, and factual fallbacks	Chromium, Firefox, WebKit, accessibility, console/network, repeated-open stability, and expected WebGL fallback evidence
Release QA	Ran backend, AI eval, provider, security, memory, PostgreSQL, three-browser, accessibility, load, build, dependency, migration, recovery, observability, and rollback gates	Exact pass/fail/skip counts saved against the frozen revision
Deployment	Backed up PostgreSQL, staged immutable backend/frontend revisions, verified identity and health, ran browser canaries, then promoted	No promotion after the first LCP reading exceeded budget; promotion followed repeat measurement and clean functional canaries

Session 2 recorded 20 successful worker starts, including parallel specialists for flight handoffs, 3D/map behavior, and infrastructure release QA. Parallelism was used for independent read-only audits and isolated slices—not to let multiple agents edit the same state blindly.

The final Q24 release evidence recorded:

1,438 backend tests passed;
8/8 real PostgreSQL concurrency and recovery tests passed;
73 Chromium, 72 Firefox, and 72 WebKit tests passed, with two expected Chromium-only WebGL skips across the non-Chromium engines;
800 bounded stress/soak requests completed with zero errors;
production memory add → reload → delete → reload non-resurrection passed;
Explore Map, mobile overflow, control sizing, console, network, and repeated-open stability passed;
final independent review converged clean in the allowed three cycles.

The deployment canary is a good example of the loop refusing to flatter itself. The first staged mobile LCP reading was 2.69 seconds, above the 2.5-second budget. Codex did not promote. It repeated the measurement and attacked the render path; the median was 2.006 seconds, the cache-ignored run was 1.991 seconds, CLS was zero, and the functional, console, and network checks remained clean. Only then did it promote the stable release.

What I decided, and what Codex owned

I do not think “the AI built everything” is an honest description. The division of work was more interesting.

My decisions	Codex’s execution responsibility
Memory must learn autonomously from grounded chats and verified trips—not exist only as a manual settings form	Trace the source-of-truth paths, reproduce contradictions, implement lifecycle semantics, and prove them across API, eval, database, and browser boundaries
A seller link is not useful if it opens a CAPTCHA, generic page, wrong date, or zero results	Design the exact handoff contract, implement fail-closed behavior, and test valid plus adversarial states
Keep the experience conversational: short corrections such as “cheaper,” “closer,” or “not Vancouver, Montreal” must preserve context	Build and test intent grounding, precedence, ambiguity, correction, and multi-turn continuation
Make the system impressive but honest: show Stadium Lens and maps without pretending illustrative geometry is ticket evidence	Build accessible immersive UI with factual labels and non-WebGL/degraded fallbacks
Do not spend paid credits, make bookings, publish, or cross irreversible boundaries without authority	Use fixtures, sandboxes, cached or approved read-only evidence; keep transaction and publication gates closed until authorized
Do not over-engineer; fix safe in-scope problems instead of handing them back to me	Choose the smallest complete fix, add the regression, rerun affected gates, and stop when evidence satisfies the contract
Replace the one-review deadlock with bounded review-per-revision cycles	Freeze each revision, verify findings, fix real defects, re-review up to three times, and land only clean slices

My job moved upward: product truth, priorities, risk, taste, authority, and acceptance. Codex took on the repetitive but demanding engineering loop beneath those decisions.

How the build system connects to the product

The build plane was my phone or laptop → Codex CLI → GPT‑5.6 Sol at max reasoning → the Peter loop → Git worktrees, tests, browser tools, reviewers, deployment scripts, and evidence.

The runtime plane is the product judges can use: browser → Next.js on Vercel → a signed server facade → Caddy/FastAPI and a durable worker on Alibaba ECS → private PostgreSQL → Qwen Cloud and typed travel/context providers → deterministic ranking, repair, and independent verification.

That separation matters. Codex did not become the hidden production travel model, and Qwen did not write or deploy the application.

Mapping the work to the judging criteria

Technological Implementation

The non-trivial part is not that Codex generated TypeScript and Python. It is that the two sessions operated a recoverable engineering system: explicit goals, persistent evidence, dirty-state recovery, isolated worktrees, source-blind regressions, bounded parallel workers, browser/network inspection, independent reviews, deployment identity checks, and canary-gated promotion.

The session IDs — shared privately through the hackathon submission — let the judges inspect the actual work rather than rely on this article.

Design

The loop produced a complete user experience, not a dashboard of agent internals. A fan can chat naturally, preserve or correct preferences, see a conflict, approve or refine a repair, compare ranked packages, inspect evidence, explore the map and stadium perspective, reload an immutable trip version, and create a privacy-safe share.

Design decisions were verified across desktop and mobile, keyboard and reduced motion, Chromium/Firefox/WebKit, loading/empty/error/degraded states, and the boundary between an illustrative experience and a factual commercial claim.

Potential Impact

The immediate audience is a fan planning event travel. The problem is real: a cheap itinerary can still fail because of airport distance, arrival buffer, hotel location, stale seller links, missing refunds, or preferences the planner forgot.

The same architecture also has a credible B2B path. A travel agency could embed a branded planning agent in its website, connect approved inventory and commercial providers, preserve customer preferences under its own tenant boundary, and require human approval before transactions. That agency product is a direction, not a shipped feature in this release.

Quality of the Idea

Many travel assistants can produce an itinerary. MatchDay’s different idea is that the recommendation should become more personal across sessions and more trustworthy before action. Memory has provenance, lifecycle, bounded retrieval, and correction. Autonomy has durable checkpoints, conflict repair, human gates, and an independent final contract. Commercial evidence has freshness and a ceiling: fixture, discovery, cached, sandbox, live, available, and bookable are not interchangeable words.

The Codex workflow mirrors that product idea. It also remembers the goal, survives interruption, attacks its own assumptions, and refuses to call the result verified until the evidence boundary passes.

The mistakes are part of the story

The build was not a straight line:

My one-review-total instruction created a real authorization deadlock. I fixed the process instead of weakening review.
A browser harness failed before reaching the product because dependencies were missing, then failed again because a symlink duplicated Next.js request context. Codex separated harness failures from product failures before continuing.
A provider page returned HTTP 200 while showing a robot challenge or losing the route/date. The contract changed from “link opens” to “usable exact result is proven.”
A production-stage LCP sample missed budget. Codex held promotion until repeat measurements and functional canaries established the real state.
The final evidence review found stale historical pointers after the runtime was already green. The review loop fixed the documentation boundary and finished clean on cycle three.

This is why I would not replace the loop with one enormous prompt. The failures were not noise around the work. They were inputs to the next verified slice.

Try the result

No account or credentials are required for the deployed application.

Open MatchDay in a fresh browser profile.
Choose Use demo scenario, then Plan this trip.
Watch Remembered → Conflict detected → Plan repaired → Result verified.
Open the proof map: Memory → Plan → Tools → Repair → Verify.
Add or edit a preference, reload, and verify that it remains in the same browser.
Send a short follow-up such as cheaper or closer.
Inspect the immutable revision, package evidence, Explore Map, Stadium Lens, and safe public share.
Open a private window to verify that it receives a different guest profile.

MatchDay does not purchase travel and does not invent missing availability, prices, refund terms, or booking status.

Run the application locally

The application source—not this article repository—lives at mzidan000/matchday-v3.

Prerequisites: Git LFS, Node.js 22, Python 3.11+, and a Qwen Cloud API key only for live-model runs.

git lfs install
git clone https://huggingface.co/mzidan000/matchday-v3
cd matchday-v3
npm ci
python3 -m pip install -e '.[dev]'
cp .env.example .env

Set DASHSCOPE_API_KEY in .env for live Qwen execution, or use the clearly labelled deterministic test adapter below without paid model calls.

Start the backend in terminal 1:

MATCHDAY_QWEN_MODE=scripted PYTHONPATH=backend \
  python3 -m uvicorn matchday.main:app --host 127.0.0.1 --port 8080

For a configured live-Qwen run, omit MATCHDAY_QWEN_MODE=scripted; the copied .env supplies the selected production adapter and key.

Start the frontend in terminal 2:

npm run dev -- --hostname 127.0.0.1 --port 3000

Then open http://127.0.0.1:3000.

Evidence and privacy

The sanitized claim ledger is in EVIDENCE.md. I am not publishing raw session transcripts: they include private conversation, local machine paths, security work, and potentially sensitive operational context. Devpost receives the two /feedback session IDs so the actual Codex work can be evaluated through the intended channel.

I also do not publish private chain-of-thought. The evidence covers observable decisions, tool actions, commands, diffs, tests, reviews, timings, and outcomes.

What Codex changed for me

Codex did not remove me from the loop. It changed where I spent my time.

I spent less time manually moving between files, terminals, test runners, browsers, reviewers, deployment commands, and evidence documents. I spent more time deciding what “correct” meant: whether memory was actually autonomous, whether a result link was honest, whether a visual was factual, whether a review rule could converge, and whether the release deserved the word verified.

That is the part I want to keep using after the hackathon: not “AI writes code,” but a human sets the product truth while Codex carries a difficult engineering goal through implementation, attack, recovery, and proof.

Downloads last month: -; Downloads are not tracked for this model. How to track

Inference Providers NEW

This model isn't deployed by any Inference Provider. 🙋 Ask for provider support