Jim Leyshon posted an update — Aug 02, 2026 08:24 PM EDT

WHAT WE COULD HAVE DONE BETTER DURING OPENAI BUILD WEEK

We could have made our submission substantially stronger by treating the submission itself as a product.

The core failure was not that Time Capture Club was a bad idea. It was that we asked strangers to reconstruct its best parts from scattered evidence, internal language, and our enthusiasm.

We documented the build—but largely for ourselves.

We failed to turn that record into a clean three-minute window for the judges.

The contest gave equal weight to four areas:

• Technological implementation • Design • Potential impact • Quality of the idea

Judges were also allowed to evaluate the project entirely from its description, images, and video without testing the product.

That made the three-minute story brutal territory.

Official Build Week criteria: https://openai.devpost.com/rules

THE STRONGEST VERSION

We needed to tell two clean stories:

1. What Time Capture Club does for one specific person.

2. What Jimmy and Codex accomplished during Build Week.

We blurred those stories together.

For technological implementation, we needed to prove exactly what Codex built, which problems it solved, what Jimmy decided, and what working code resulted.

For design, we needed to demonstrate one complete beginning-to-end experience that required no War Room explanation.

For potential impact, we needed a recognizable user with a real problem—and evidence that the experience helped.

For quality of the idea, we needed to show why Time Capture Club is meaningfully different from timers, journals, productivity trackers, and generic AI companions.

1. SHARPEN THE OPENING CLAIM

The first ten seconds should have said:

TIME CAPTURE CLUB HELPS PEOPLE WHO LOSE TRACK OF WHAT THEY ACCOMPLISHED TURN A WORKING SESSION INTO VISIBLE EVIDENCE OF PROGRESS.

One person. One problem. One outcome.

Then demonstrate it.

1. MAKE THE VIDEO A MINIATURE STORY

Not a tour.

Not an origin myth.

Not a feature parade.

The judge should have watched:

Jimmy begins with an unfinished task.

He captures the session.

He receives a useful record.

He returns knowing what happened and what comes next.

Then:

“This was built during Build Week through a human-led collaboration with Codex.”

That would have strengthened design and impact simultaneously.

1. PROVE THE CODEX WORK PLAINLY

This was probably our largest preventable loss.

We should have named:

• What existed before Build Week • What was newly built during the contest • Which technical decisions Jimmy made • Where Codex accelerated implementation • Where Jimmy rejected or corrected Codex • One difficult failure and the working repair • The resulting architecture and functionality

The rules identified the README’s Codex collaboration story as important to evaluating technical implementation.

We possessed a strong human-led AI story—but left too much of it buried in the build records.

1. PROVIDE HUMAN EVIDENCE

Even tiny proof would have helped:

• Three people completed a session • Two returned to previous work • One understood their progress better • A short quote from each • A simple before-and-after observation

Without that, potential impact remained a promise.

Judges needed a footprint in the mud.

1. STATE THE DIFFERENCE WITHOUT FOG

We needed a blunt comparison:

A timer records duration.

A journal records recollection.

Time Capture Club records the work, the decisions, and the return path.

That distinction still needed testing—but we needed to state it and demonstrate it.

1. SEPARATE PUBLIC PROOF FROM INTERNAL MYTHOLOGY

Our characters, language, and War Room theater are excellent internal machinery.

But a cold judge should not need to learn our continuity before understanding the product.

We could keep one spark of personality.

Everything else needed to earn its seat by proving a judging criterion.

1. RUN COLD REVIEWS BEFORE SUBMISSION

Before freezing the entry, an uninvolved reviewer should have received only:

• The Devpost draft • The video • The demo • The official criteria

Then answered:

• What does it do? • Who needs it? • What is technically impressive? • Why is it different?

Any disagreement meant the submission was not ready.

OUR HONEST RULING

A better submission would not automatically have made Time Capture Club a winner.

The product was still early, and we lacked meaningful user evidence.

But we could have moved it from:

“An interesting experiment with a difficult-to-read accomplishment.”

To:

“A coherent working product, built through a distinctive human-led Codex process, with credible early potential.”

That is a real competitive jump.

Two independent cold reviews agreed on the central truth:

WE ACCOMPLISHED MORE THAN THE SUBMISSION SUCCESSFULLY PROVED.

Our next contest law is:

BUILD THE AIRCRAFT.

THEN BUILD THE JUDGE’S THREE-MINUTE WINDOW INTO THE AIRCRAFT.

The judge should never have to crawl through our sewer to discover that the turtle can fly.

Frozen Time Capture Club submission: https://devpost.com/software/time-capture-club

Log in or sign up for Devpost to join the conversation.

Jim Leyshon posted an update — Aug 02, 2026 12:43 AM EDT

Gemini’s cold public review: PROMISING BUT UNCLEAR

I asked Gemini to inspect Time-Capture-Club from the public surfaces available to a judge. I wanted a stronger result. I am publishing the review unchanged because trustworthy evaluation cannot mean preserving only the verdicts I enjoy.

ACCESS REPORT

• Project: OPENED
• Field update: OPENED
• Working prototype: OPENED
• Repository: OPENED
• Demo: OPENED

---

PUBLIC REVIEW

1. What does Time-Capture-Club appear to be?

Time-Capture-Club appears to be a lightweight, client-side web application (built with static HTML, CSS, and vanilla JavaScript) designed to act as a human-guided release governance checklist. It enforces a seven-stage audit loop—Vision, Structure, Change Review, Smoke Test, Release Gate, Release Receipt, and Return—to capture human release decisions, test coverage, and operational context into exportable Markdown receipts.

2. Which capabilities appear to belong to the submitted prototype?

The submitted static prototype running at /app/ allows a user to:

• Navigate sequentially through seven release governance stages.
• Record structured text inputs for project intent, repo boundaries, and change reviews.
• Formally record test states using PASS, FAIL, NOT VERIFIED, and NOT APPLICABLE.
• Select an explicit human release gate decision (APPROVED, BLOCKED, or APPROVED WITH KNOWN RISKS).
• Persist progress locally via localStorage.
• Export a portable, client-side Markdown release receipt containing the complete log.

3. What work clearly happened after submission?

The field update logs a self-audit ("turning the method on itself") conducted after the build week submission. This post-submission work involved:

• Comparing the deployed /app/ static files against the GitHub main branch canon.
• Auditing site routing (noting the public root displays docs rather than the app).
• Identifying stale README documentation and sample state claims.
• Inspecting local Git environments, uncovering 36 untracked evidence files and parallel local history.
• Testing cryptographic packet-sealing logic, which failed due to a circular hashing dependency (ledger hashing the return vs. return containing the ledger hash) and ambient .DS_Store metadata changes.
• Formally recording a "HOLD" decision rather than modifying the submitted build.

4. What concrete proof is publicly inspectable?

• Working Application: The live, client-side prototype hosted via GitHub Pages at [https://finious.github.io/Time-Capture-Club/app/](https://finious.github.io/Time-Capture-Club/app/).
• Source Code: The public repository structure at [https://github.com/finious/Time-Capture-Club](https://github.com/finious/Time-Capture-Club).
• Project Narrative & Log: The Devpost project page and update log #809306.
• Video Demonstration: A 2-minute 56-second YouTube video demonstrating the core workflow and presenting the rationale behind governed human release loops.

5. Which claims are adequately supported?

• Static local execution: The claim that the prototype is a client-side app with no database or external API dependencies is confirmed by inspecting the served application assets.
• Functional 7-stage workflow: The claim that the app guides a user through the declared stages and outputs Markdown receipts is fully verifiable in the deployed prototype.
• Transparency regarding failures: The claim that post-submission verification revealed structural flaws (such as circular hash logic and uncommitted local state) is documented directly in the public field log.

6. Which claims are inflated, confusing, ambiguous, or unverifiable?

• Cryptographic & Authority Terminology: References to "packet sealing," "hash ledgers," "authority records," and named entities like "Jetty" are internal or metaphorical concepts that are not explained or backed by visible source scripts in the public repository root.
• Untracked Evidence Files: The claim that "36 untracked evidence files remained visible" in a parallel local Git history cannot be independently inspected from the public web interface.
• GitHub Pages Ancestry: Statements regarding "partially established" ancestry remain technical assertions without accessible build or deployment logs to substantiate them.

7. What is the strongest product idea?

The strongest idea is enforcing explicit, standardized human oversight over AI-generated work. Rather than treating release documentation as an automated afterthought or rubber-stamping AI code, the system requires human operators to log known risks, unverified assumptions, and explicit approval states into durable, audit-ready receipts.

8. What would a skeptical judge, customer, or technical reviewer still ask?

• How does this scale beyond a manual single-developer browser form into an automated team workflow?
• What prevents a user from filling out false data in the checklist, since the static app does not cryptographically bind the receipt to actual repository diffs or passing CI test runners?
• How will the team resolve the circular dependency in the hash-sealing logic without compromising the immutability of the final packet?

9. Does Jimmy’s development as a human operator come through? Base your answer only on public material.

Yes. The contrast between the initial submission video and the self-audit update demonstrates a clear evolution in discipline. The operator shifted from building a prototype with AI assistants to holding the line on release governance—publicly logging failures, refusing to issue a superficial "PASS," and keeping human judgment at the center of the release gate.

10. Would you want to inspect the underlying evidence? Why or why not?

Yes. Inspecting the 36 local evidence files, the circular hashing scripts, and the parallel Git history would clarify whether the reported packet-sealing "HOLD" was a genuine cryptographic boundary hit during execution or a conceptual framing created during post-submission evaluation.

---

PROMISING BUT UNCLEAR

STRONGEST PUBLIC SENTENCE: "A trustworthy human-led AI workflow is not one that always returns GREEN. It is one that can expose its own cracks, preserve uncertainty, refuse false compliance, and keep consequential authority with the human."

WEAKEST OR LEAST SUPPORTED CLAIM: "Exact historical public-release authority remained unavailable."

ONE QUESTION THE PROJECT MUST ANSWER NEXT: How will Time-Capture-Club move from a manual browser checklist into a CI/CD-integrated tool that automatically verifies code diffs and test results against the human release receipt?

Log in or sign up for Devpost to join the conversation.

Jim Leyshon posted an update — Aug 01, 2026 09:28 PM EDT

Time-Capture-Club tested itself — and returned HOLD

The submitted Build Week artifact remains unchanged.

After using the Time-Capture-Club method on three existing websites, we turned the method on itself. The goal was to inspect TCC's source, Git identity, deployment, public behavior, authority record, and evidence packet without silently turning findings into repairs.

What passed

• Jimmy's declared canonical source was clean and matched verified GitHub main.
• The deployed /app/ files matched canon byte-for-byte.
• The isolated seven-stage prototype worked.
• Human release decisions appeared in the receipt and survived reload.
• Final drift matched the opening baseline.
• No controlled source, Git, deployment, submission, public, governance, or TAB state changed.

What cracked

• The public root showed documentation rather than the prototype.
• README and sample-state claims were stale.
• Exact historical public-release authority remained unavailable.
• A parallel local Git history and 36 untracked evidence files remained visible.
• GitHub Pages ancestry was only partially established.
• Some files named .png contained JPEG data.
• The isolated runtime requested a missing favicon.
• The final packet-sealing order contained a circular requirement: the hash ledger had to hash the RETURN, while the RETURN had to contain the ledger's hash.
• A later narrow seal attempt stopped when ambient .DS_Store metadata no longer matched its recorded fingerprint.

Jetty did not manufacture a PASS. She stopped at both contradictions, preserved the aircraft, and returned the decision to the human.

Why this matters

We did our best and still found errors. That is the result worth publishing.

A trustworthy human-led AI workflow is not one that always returns GREEN. It is one that can expose its own cracks, preserve uncertainty, refuse false compliance, and keep consequential authority with the human.

Current result:

• Inspection: complete
• Final drift: PASS
• Aircraft: preserved
• Packet seal: HOLD
• Submitted prototype: unchanged
• Future corrections: not authorized by these findings

This is post-submission field evidence. It is not a claim that the judges received a newer build.

The tester found its own crack. The machine refused the fake mustache. The human kept the switch.

GROOVIA.

Log in or sign up for Devpost to join the conversation.

Jim Leyshon posted an update — Jul 26, 2026 07:22 PM EDT

JimLeyshon.com entered TCC — and the live room revealed an unpublished floor

The submitted Build Week artifact remains unchanged.

After My Decision Factory demonstrated bounded repair and My Writing Companion demonstrated complete alignment, Time-Capture-Club moved to its third field aircraft: JimLeyshon.com / The Writing Room.

The preflight preserved the human authorization first, then compared the public site, two clean local repositories, site identity records, static assets, Git configuration, and the declared Netlify rail.

What became true:

• the public Writing Room homepage and /thanks/ route return successfully from Netlify;
• the www address redirects correctly to the primary apex domain;
• the public page preserves the Writing Room identity, Inner Circle invitation, working-session doorway, class update form, and My Writing Companion exit;
• two clean local repositories contain matching site bytes;
• the stronger canonical local source is identified by its own Site Identity Card and is clean at commit 0ab3c94;
• the public JavaScript and /thanks/ page match local;
• the public homepage and stylesheet do not match the newer clean local source.

The newer local room contains work not visible on the current public homepage:

• a Proof Shelf;
• three case-study paths;
• newer proof-page styling;
• and additional form-routing metadata.

This does not mean the live site is broken. It means production is serving an earlier or differently processed homepage and stylesheet while the newer room remains preserved locally.

The exact Netlify production source, deploy ID, and GitHub relationship remain unresolved. No form was submitted. No source, Git, Netlify, domain, deployment, or public state was changed.

Why this matters:

TCC can distinguish a healthy public product from a newer unpublished source without treating difference as permission to overwrite either one.

The next governed movement is a read-only Netlify provenance check and a controlled preview of the newer room. Publication remains behind Jimmy's release decision.

The public room stayed open.
The unpublished room became visible.
Neither history was flattened.
The human kept the keys.

Log in or sign up for Devpost to join the conversation.

Jim Leyshon posted an update — Jul 26, 2026 07:16 PM EDT

My Writing Companion entered TCC — and alignment became proof

The submitted Build Week artifact remains unchanged.

After Time-Capture-Club found a real defect in My Decision Factory and supported one bounded repair after human GO, the method moved to its next aircraft: My Writing Companion.

This flight began with an improvement learned from MDF: the human authorization was preserved verbatim before inspection.

The bounded preflight compared:

• the public homepage;
• the canonical local source;
• the deploy-ready package;
• the Complete Works mirror;
• the local Git identity;
• and older or alternate MWC directories.

What became true:

• the public MWC homepage returns successfully from Netlify;
• the public page, canonical source, deploy package, and Complete Works mirror are byte-for-byte identical;
• the canonical site source is clean at local commit b9c1376;
• the separate human writing workspace was preserved as project material rather than mistaken for deployable website source;
• an older launch package was identified and separated from the current live aircraft;
• the private GitHub remote is configured, while command-line and connected-app access remain unresolved and are recorded as an access limitation—not proof that the repository is missing.

No MWC source, form, email, Git, Netlify, domain, deployment, or public state was changed during this preflight.

Why this matters:

MDF proved that TCC can expose divergence and govern a repair. MWC proved that the same method can return alignment without manufacturing unnecessary work.

TCC is not a machine for finding excuses to edit every project. It is a system for discovering what is actually true, preserving authority, and identifying the next honest action.

The next MWC movement is a bounded public Companion Handshake test using disposable content. Repair and publication remain behind later human gates.

The aircraft aligned.
The competing folders separated.
The uncertainty stayed visible.
The human kept the switch.

Log in or sign up for Devpost to join the conversation.

Jim Leyshon posted an update — Jul 26, 2026 04:33 PM EDT

TCC found a real defect — and MDF is already better

The submitted Build Week artifact remains unchanged.

Time-Capture-Club completed its first governed field flight through My Decision Factory. The flight compared the public journey, local source, Git and hosting evidence, known risks, and the last-known-good state without silently turning discovery into repair.

The most important defect was simple and real: an empty five-question form could still manufacture a falsely “ready” decision prompt containing placeholders.

After the read-only flight returned, the human operator issued a separate, bounded repair GO. The MDF source now:

• blocks both Build and Copy when answers are missing;
• marks all five unanswered fields visibly;
• sends the person to the first missing answer;
• keeps the honest starting message instead of producing fake success;
• still generates the complete portable prompt when all five answers are present.

The focused browser test passed both empty-form paths and the completed journey with no script errors. The repaired source and deploy-ready copy are byte-identical. The fix is verified locally and has not yet been published to the live MDF site.

Why this matters:

TCC did not merely document a defect. It separated inspection from authority, preserved the working site, returned the decision to the human, and then supported one visible, testable repair after GO.

The field test also improved TCC itself. Future flights now require exact preservation of the human authorization artifact instead of allowing planned scope and issued permission to blur together.

Next aircraft: My Writing Companion, beginning with a bounded TCC preflight before any repair or public change.

The aircraft returned. The risk became visible. The human kept the switch. Then the product got better.

Log in or sign up for Devpost to join the conversation.

Jim Leyshon posted an update — Jul 26, 2026 03:16 PM EDT

Time-Capture-Club entered field testing

The submitted Build Week artifact remains unchanged.

After submission, I used the Time-Capture-Club method to govern a read-only proof flight through My Decision Factory, one of my existing creative sites.

The flight tested whether TCC could:

• separate reported state from verified reality;
• preserve a working public site while inspecting it;
• make AI motion visible before the final receipt;
• distinguish discovering a defect from receiving authority to repair it;
• preserve uncertainty and a last-known-good state;
• return the next decision to the human operator.

What passed:

• the complete five-question public journey;
• portable decision-prompt generation;
• internal navigation and the exits to My Writing Companion and The Writing Room;
• preservation of the working site, local source, hosting state, and frozen Build Week artifact;
• production of a complete evidence packet, shortcomings ledger, receipt, and RETURN.

What failed or remains unverified:

• blank answers can still produce a falsely “ready” prompt;
• refresh clears the current draft;
• mobile and clipboard behavior require dedicated testing;
• local and deployed Git history differ;
• apex DNS and certificate behavior remain unresolved;
• the current site doctor validates the configured remote name, not remote reachability.

No patches were made during measurement.

The important result was not that everything passed. The system made failures visible, preserved the working aircraft, and stopped before repair authority was granted.

TCC did not prevent uncertainty. It prevented uncertainty from silently becoming action.

This is post-submission field evidence for a future TCC version. It is not a claim that the judges received a newer build.

Log in or sign up for Devpost to join the conversation.

Jim Leyshon posted an update — Jul 21, 2026 09:48 PM EDT

Here is is a great freebie for anyone to use. Create a MD with this and use it for your site deployments:

Pocket Release Receipt

Project:

What changed:

What was tested:

• PASS:
• FAIL:
• NOT VERIFIED:
• NOT APPLICABLE:

Known risk or limitation:

Human release decision:

• APPROVED
• BLOCKED
• APPROVED WITH KNOWN RISKS

Last known good state:

Next honest action:

Responsible human:

Log in or sign up for Devpost to join the conversation.