Deadline Loom: a schedule with a memory
DEV Community

Deadline Loom: a schedule with a memory

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange. What I Built Deadline Loom asks a small, uncomfortable question: which version of a deadline leaves enough time to finish? It is an Astro planning workbench for someone comparing several pieces of time-sensitive work. A source-linked deadline is one input; estimated effort, daily capacity, and prerequisites are others. Moving an estimate or selecting a proposed source version changes the schedule. A saved local planning decision remembers the inputs it covered and becomes stale when those inputs change. The strange part is treating a schedule as an argument with a memory. A reassuring timeline should still show where its dates came from, what its assumptions are, and what could invalidate an earlier decision. The sample content contains three real DEV challenges, with official source links checked on October 2. Build-hour and human-minute estimates are illustrative. The earlier-deadline revision is explicitly simulated. No green timeline represents eligibility, an organizer update, a likely win, or money earned. Demo Open Deadline Loom. No login is needed. When the query completes, the header shows CONNECTED / PUBLIC SANITY CONTENT. A failed read instead shows an explicit sample-mode notice. Try this short walkthrough: - Change the clock from Chicago to UTC. The start input changes from 13:00 CDT to 18:00 UTC; the planned instant stays the same. - Select the simulated earlier source version for the first thread. The selected deadline moves seven hours earlier, while the recorded organizer date remains visible. - Add a reason and record a local planning decision. - Increase that thread's estimated work to 30 hours. The plan shows missed deadlines, and your decision becomes stale. - Export the scenario as an ICS calendar file. Its events use UTC instants and include the source and planning disclaimer. Scenario edits and notes stay in your browser. The separate authenticated editorial workflow runs in Sanity Studio. The public decision memory displays a real persisted simulated approval performed during an authorized agent-operated Studio rehearsal; it does not imply that a human clicked or an organizer changed the deadline. Judges can inspect that published decision without editor credentials. Code Browse the public source repository or download the complete source ZIP. Original code is MIT licensed; third-party packages retain their own licenses. git clone https://deadline-loom-jaye-2026.netlify.app/deadline-loom.git cd deadline-loom pnpm install pnpm dev The project uses Astro 7.3.5 and Sanity 6.17.0. The repository includes the dependency lockfile, setup README, six document schemas, Studio document actions, seed validator, and planner checks. For CONNECTED mode locally, copy .env.example to .env , set PUBLIC_SANITY_PROJECT_ID=2mflxxa8 and PUBLIC_SANITY_DATASET=production , restart the dev server, and open http://127.0.0.1:4321 . Those values are public; no write token is needed. To use a different Sanity project, configure its public routing values and allow its browser origin through CORS with credentials disabled. My Build Process This was built on October 2 using Codex as the AI-native development environment. Delegated Codex agents researched primary rules, developed the content model, generated the interface and review actions, operated the authorized setup, and ran the checks. This account's owner authorized the work; the coding, browser rehearsal, and verification described here were agent-operated. I am not presenting them as manual coding or human user testing. The initial direction was broader: a source-linked opportunity review desk. Reviewing current entries revealed similar territory, including Proof Desk: receipts before rewards. The project narrowed to a distinct interaction: source versions alter the time available, effort consumes it, and planning decisions remember their context. No competitor code, text, or images were copied. These are condensed build directives, rather than verbatim transcript excerpts: - Keep official dates, proposed revisions, and effort assumptions separate; make the selected revision change a schedule without overwriting the accepted fact. - Give every local decision a fingerprint of its planning inputs; changing the plan must make its previous decision stale. - Build a public reader without a write token, and put authenticated editorial transitions in Studio with a reason and optimistic revision checks. Those constraints shaped the schema and UI more than a visual prompt did. The cream-and-green workbench puts the clock, threads, timeline, source versions, and decision memory in one place. The mobile layout stacks those controls while keeping the timeline readable. The main integration correction came from a real false positive: an anonymous Node query succeeded while the browser still showed sample mode. The origin was missing from Sanity's CORS configuration. Adding the exact local and deployed origins with credentials disabled made the hosted browser show live content and the persisted approval. A successful script read was insufficient evidence of a working public demo. A second correction separated the static build from content loading. The build now embeds the labeled fixture without a network request; the browser fetches published content and refreshes once a minute while visible. That gives the public view an honest failure state. The custom Studio actions approve or reject an evidence revision and save its decision in one transaction. A real approval can apply the proposed accepted value; a simulated approval only records the rehearsal. The observed rehearsal approved revision-simulated-deadline with a reason, created a public decision, and retained the official deadline 2026-10-05T06:59:00Z . This uses a custom document-review process built with Sanity's Document Actions API. It does not use the App SDK or the Sanity Workflows product. Checks actually run: - Production Astro and Studio builds, plus TypeScript checking, passed. - Planner checks covered equivalent Chicago/Pacific/India deadline instants, a winter offset, earliest-deadline order, capacity, revision impact, UTC calendar times, text escaping, and UTF-8 line folding. - Browser interactions confirmed the timezone-preserving start, seven-hour revision impact, local decision recording, late schedules, and stale decision memory. - Anonymous public queries and the hosted browser confirmed the Sanity content and simulated approval. The exported ICS file was downloaded and inspected. The scheduling model remains deliberately small: serial work using average daily capacity, with human minutes added separately. It does not model hourly availability or holidays. Prerequisites are a checklist, not an eligibility validator. The estimates are assumptions, and the rejection action has not been independently rehearsed in the live dataset. Sanity Project Details - Project ID: 2mflxxa8 - Dataset: production (public) - Published document types: competition ,evidenceSource ,sourceClaim ,evidenceRevision ,reviewDecision ,projectNote sourceClaim → competition + evidenceSource evidenceRevision → competition + evidenceSource reviewDecision → exact evidenceRevision projectNote → estimate, verification, or simulation context Sources remain independent documents with publisher, URL, and checked time. Claims preserve what was reported. A revision represents a proposed change, and a decision points to the exact revision reviewed. This avoids treating a copied date as both evidence and acceptance. The initial seed contains 28 documents. The Studio rehearsal added one persisted simulated decision, bringing the public dataset to 29. The browser reads published content without an Authorization header. Public routing values are included; write credentials, personal account details, identity documents, and financial records are excluded from the dataset and public source. Agent Session No public agent transcript is attached. The build account above describes the work actually completed, and the repository contains the implementation and reproducible planner checks. Submitted by @jayenichols. AI agents were development tools; there are no additional human teammates. Top comments (0)

Read on DEV Community ↗ ← Back to News

Comments

No comments yet. Start the discussion.