Deadline Crypt

A local desk for cash-prize contests: separate credits, track materials, and distinguish registration from submission.

Comment

Inspiration

A contest can advertise a large prize while most of its rewards are credits. A registration can be complete while the actual work is unfinished. Repeated reminders can make a deadline feel familiar without helping anyone finish what remains.

Deadline Crypt began with the entrant's practical request: track contests with monetary prizes, remind them about deadlines and missing materials, and keep cash separate from credits and registration separate from submission.

The Costume Contest theme became a useful visual language. Approaching deadlines and unfinished work haunt the desk; an explicitly submitted entry stops returning as an unresolved alarm. Dark ink, amber light and a night-desk layout support that idea while leaving the information readable and the controls usable by keyboard.

What it does

Deadline Crypt is a static browser application for manually tracking opportunities.

  • Cash amounts and currencies are displayed separately from credits and other non-cash benefits. A cash-only filter selects records with a positive monetary amount.
  • Interested, Registered, Preparing, Submitted and Withdrawn are distinct stages. Completing every required material never changes the stage to Submitted automatically.
  • Each opportunity has a materials checklist, source details, notes and a suggested next action.
  • Exact deadlines are displayed in Europe/Warsaw. Input requires an explicit UTC offset or Z, and impossible calendar dates are rejected. Date-only entries remain marked UNKNOWN HOUR.
  • The on-page queue shows the current 7-day, 72-hour or 24-hour reminder. Acknowledging it prevents the same reminder from returning; a later threshold can still appear.
  • Submitted and Withdrawn records suppress entry reminders. A genuinely changed deadline gets a new reminder identity, while an equivalent timestamp with a different offset keeps the same history.
  • Versioned JSON backups include records and reminder acknowledgements. Imports are validated before merging, report conflicts, skip duplicates and preserve existing acknowledgements.

The desk starts empty. Load examples adds three explicitly fictional opportunities; their names, URLs, rewards and deadlines are invented. The examples demonstrate the workflow without presenting unverified real contests as recommendations.

The application is a manual planner. It does not discover contests, read email, submit entries, handle money or independently verify an organizer's receipt. Reminders refresh while the page is open, without background or push delivery. Records use unencrypted browser storage, so export a backup; someone using the same browser profile can access them.

How we built it

The entrant supplied and explicitly confirmed the application's purpose and priority feature. Codex translated that direction into a brief and acceptance scenarios, prepared the restricted environment and invoked native Kiro CLI 2.37.

Kiro performed two real native build sessions. It generated the initial application source, steering/specification/task documents and domain tests, then applied the first targeted bug fixes from review findings. The profile allowed project-scoped file reading and writing; shell, network and MCP tools were not enabled. Kiro wrote tests, while Codex executed them.

Codex subsequently made material changes to styling, unreadable-storage preservation, explicit example loading, backup acknowledgement merging, import validation and deduplication, fictional fixtures, form labels, focus handling and custom confirmation dialogs. The final code is a collaboration. Genuine Kiro artifacts remain in the repository's .kiro directory; the final source is not attributed solely to Kiro.

The application uses HTML, CSS and JavaScript with no backend or paid runtime API. Entered records are not uploaded to a remote opportunity service. Static hosting still involves normal page and asset requests; this is not a claim of zero network activity or a complete offline audit.

Challenges

An older backup must not make an acknowledged reminder appear new again. Restoring records and reminder history needed to work together. The merge now retains a newer acknowledgement for the same deadline instead of overwriting it with an older false value.

Timestamp identity was another subtle problem. The same instant written with Z and with +01:00 should not trigger two alerts. Reminder keys now use the parsed instant, while an actual deadline change still receives fresh treatment.

Real browser checks caught a different class of issue from the pure domain tests, including an early SVG class-name startup error. Later review exercised the actual filters, forms, dialogs and queue rather than relying only on isolated logic.

Accomplishments

The reviewed build passes all 136 automated tests. They cover deadline boundaries, calendar and offset validation, stage/reminder suppression, import schema and limits, deduplication and acknowledgement history.

Desktop Chrome and in-app browser checks confirmed that the cash filter selected two of the three fictional examples; completing all materials left the stage unchanged; explicitly choosing Submitted suppressed an alarm; a changed deadline brought an alarm back; and equivalent offsets did not repeat it.

Importing an older backup preserved a newer acknowledgement. An invalid import left the three existing records intact. Tab, Shift+Tab and Escape were checked in dialogs, and an emulated 320 px layout had no horizontal page overflow.

The public source and live demo are available at the links above. The checks described here do not constitute real-phone, Safari or screen-reader certification.

What we learned

A finished checklist is preparation; Submitted is an explicit user action. A date without an hour is incomplete information. A different spelling of the same instant is not a new deadline. Those distinctions have to exist in the data model before an interface can explain them reliably.

Kiro provided the initial implementation and a targeted revision, while tests and browser interaction exposed different problems. Keeping the actual contributions visible gives a more useful build account than assigning every final line to a single tool.

What's next

Possible later work includes calendar export and testing on real phones and more browser/accessibility combinations. Automatic discovery, email access and background notifications would be separate features with different data and access requirements; they are outside this version's scope.

Built With

Share this project:

Updates

Submission history