DEV Community: Hyunsik Park

ShiftCal: a local Gemma roster reader for someone close to me

Hyunsik Park — Mon, 05 Oct 2026 01:04:11 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.

What I Built

Someone close to me finds it cumbersome to move a rotating shift roster into a calendar. ShiftCal takes their own shifts as text, uses local Gemma to read the dates and shift types, and prepares a calendar file after they check each row.

A night shift makes the problem concrete. 31일 나이트 means a night shift on the 31st. With the example hours of 23:00–07:00, an October shift ends on November 1. Typing the wrong end date would leave a misleading calendar entry. ShiftCal calculates that boundary in tested code and shows both dates for review.

The real-person need is confirmed. The schedules shown here are fictional, and I have not yet collected feedback from the recipient.

Demo

Open the interactive recorded demo.

Click Try a recorded example. The fourth row, 4일 이브닝?, stays unresolved. Correct it to Evening only if the original roster confirms that shift, or remove it. Check each remaining row to enable the calendar export. Day-off rows stay visible but create no event.

The public page replays a saved response from an actual Gemma run; it does not host inference. To process new text, follow the local setup in the README. The app needs Python and Ollama, with no Python or JavaScript packages. It currently accepts text only and uses Korea Standard Time.

Code

Source, setup and tests on GitHub · MIT license.

How I Built It

Gemma (gemma4:12b-it-q4_K_M, through Ollama) extracts a day and a D/E/N/O shift code from each Korean or English input line. Each result remains beside its source. Missing or duplicated model rows are flagged; explicit uncertainty stays unresolved.

JavaScript handles dates, shift hours and iCalendar formatting. It rejects invalid dates, duplicate dates and overlapping shifts. Changing a row or its settings clears the relevant confirmation. Export stays blocked until the remaining rows are valid and checked. There is no automatic calendar sync.

The Python server listens on loopback, calls a fixed local Ollama address and rejects foreign origins and Host headers. It limits input size and handles one extraction at a time. It does not log or save roster text. Users are asked to leave out names, workplace details and other people's shifts.

Fifteen unit tests passed, including month and year boundaries, leap years, overnight overlaps, uncertainty and server access checks. Four synthetic fixtures also went through the actual model: three matched exactly, with 13 of 14 date/code pairs matching overall. In the remaining row, 주간 had no date. Gemma left both fields unresolved instead of retaining the expected day-shift code. The row remained visible and could not be exported. These are small functional checks, not an accuracy benchmark.

Desktop and mobile layouts were checked, along with a fresh three-line extraction in the browser. Calendar-app import and recipient field testing remain unverified. Reimporting a file may create duplicates; the app recommends a separate calendar.

Why Does Open Innovation Matter?

An open-weight model makes local roster processing possible without sending each schedule to a hosted model service. Open source makes the boundary around that model visible: the prompt, schema, validation and export code are all in the repository. Someone adapting ShiftCal can change the shift hours or inspect a date calculation without depending on a private API.

The first model download needs an internet connection and disk space. Local inference still needs suitable hardware and electricity; the application has no per-request service charge.

Prize Categories

Best Use of Gemma. Gemma performs the Korean and English roster extraction in the local application. The public demo includes a recorded response from that same implementation.

AI disclosure: Codex generated and revised the implementation, tests and prose under my direction. I supplied and confirmed the real-person problem. Executed tests and model responses were checked; no interview, testimonial or field trial is claimed. This entry uses the Fully Autonomous development disclosure.

Constraint Clerk: A Source-Cited Changeover Agent

Hyunsik Park — Sat, 03 Oct 2026 15:13:18 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content.

Fully Autonomous AI build. Codex generated and revised the implementation, original fictional records and this writeup. The verification below is an actual Sanity Content Agent response. No human coding or venue experience is claimed.

What I Built

Constraint Clerk checks a changeover plan for a fictional pocket theater. A cart needs to reach backstage before an 18:12 cue. The September survey records a 940 mm passage, but an October sound screen reduces it to 690 mm. The unfolded cart is 880 mm wide.

Finding both numbers is not enough. The agent must identify which claim applies, follow the explicit supersession, then combine width with cart state, preparation time, route duration and crew availability. Folding makes the cart narrower, but requires two crew and three minutes of preparation. The wider east passage has a timed closure. The west passage has no measured width.

The output separates blocked, feasible and unknown, with source records for each check. It never converts a missing measurement into permission to proceed. All venue and equipment records are original fiction, not a real inspection or safety assessment.

Demo

Open Constraint Clerk — no login required.

Start with View recorded AI verification. It loads the real October 3 response, its calculated result and the retrieval trace. Expand Full actual answer and Actual retrieval trace to inspect them. Selecting a source opens the original record, including the superseded survey.

The public demo is static: viewing the recording makes no new AI request. The other controls run the local checker. Changing inputs clears the recorded response, so a local result cannot be mistaken for a fresh model answer.

Example	Result	Verification scope
Original unfolded cart, north route	Blocked: 880 mm cart, 690 mm passage	Real Content Agent + Context conversation; also locally reproducible
Folded cart, same route and two crew	Feasible against the documented constraints; finish 18:10	Local deterministic check only
Folded cart, unmeasured west route	Unknown; width evidence is missing	Local deterministic check only

Code

Source repository · MIT licensed.

The React interface, TypeScript checker, local agent server, Sanity Studio schema and pinned lockfiles are included. The README explains how to run the local demo and reproduce the cloud integration with a separate project and your own credentials. 21 local tests pass, including source supersession, closure boundaries, missing measurements, canonical reference recovery and transport limits. Type checking and the production build pass.

How I Used Sanity

One dataset, two scoped Context endpoints

The Content Lake holds 19 fictional documents: 11 ccSource records and eight ccClaim constraints. A claim stores its target, property, value, effective date and optional supersedes reference. Routes refer to passages; folding requirements and crew rosters remain separate records.

A Knowledge Base was built from that dataset. One read-only Context MCP endpoint exposes only the KB. A second exposes only the project's ccSource and ccClaim records. The agent uses Sanity Content Agent through the AI SDK, with built-in read, write and web search disabled.

The request follows this path:

The harness reads the KB outline and exposes knowledge_base_read to the model.
The model reads a relevant KB entry, then calls the custom check_plan tool.
check_plan queries the live dataset using Context's groq_query, restores canonical reference arrays using array_field_reader, validates the typed records and runs the checker.
The model explains that result with exact source document IDs. The structured result is authoritative for the selected plan.

The actual result

One live conversation on October 3 made four model HTTP requests and four agent tool calls: two KB reads and two plan checks. Each plan check retrieved 19 structured records and restored four canonical reference arrays.

The final answer cited cc-claim-north-current for 690 mm and cc-claim-north-old for the explicitly superseded 940 mm survey. It blocked the 880 mm unfolded cart, a 190 mm shortfall. The roster and 18:07 calculated finish passed; width was the blocker.

The response also kept its scope: it described folding's requirements but did not claim to have evaluated the folded variant. That alternative is shown separately as a local check.

Where retrieval needed a stricter boundary

Context can outline an array instead of returning its full contents, even when it has one reference. The first adapter rejected that output rather than calculating with incomplete links. The corrected adapter reads each outlined array through array_field_reader and checks its document ID, field, count, indices and cropping flags. A truncated response fails closed.

The KB also has one reviewed, unresolved issue: a derived east-passage entry omits a closure interval that exists in the original structured source. The issue has not been dismissed. Exact intervals and measurements come from the validated records, not generated KB prose. The saved dataset was read back and matched the original seed's full typed-content hash.

Cost and runtime limits

The project was automatically assigned a USD0 Growth Trial, with automatic downgrade to Free after 30 days. Only Free-included features were used; there was no paid upgrade or hosting purchase. Paid overages were disallowed.

A durable one-conversation permit was reserved before inference. Limits were four model requests, four agent tool calls, 90 seconds, no SDK retries and 512 KiB per model response. The provider has no token-output cap, so none is claimed. No further live attempts were made. Immediately afterward, the usage screen still showed 0/1,000 credits and USD0; the settled consumed-credit count was not yet reflected and is not claimed to be zero.

The public site has no model endpoint or tokens. The optional agent server is loopback-only. The README discloses two low-severity production dependency advisories and 12 separate Studio/CLI advisories, including the mitigations and remaining limits. No all-clean security audit is claimed.

Sanity Project Details

Project ID: r7tbo2j3
Dataset: production (public, original fictional records)
Document types: ccSource, ccClaim
Knowledge Base: Constraint Clerk — North Pier Room (kb4e4xT6fMwh)
Dataset source filter: _type in ["ccSource", "ccClaim"] && _id match "cc-*"

This is a separate project from the Path Two entry. Neither its content nor its submission was changed for this build.

Agent Session

The public recorded verification contains the actual question, selected plan, answer, structured result and timestamped retrieval trace. Its answer and trace match the original private run receipt. Credentials, private paths and unrelated work are excluded. This is the application agent's verification record, not an uploaded coding-session transcript.

The integration follows the official Sanity Context MCP, Knowledge Base and Content Agent interfaces.

Alibi Atlas: A Continuity Workbench for Fiction

Hyunsik Park — Sat, 03 Oct 2026 09:22:23 +0000

An entry for the Sanity Challenge — Path Two.

What I Built

Alibi Atlas is a continuity workbench for fiction. It asks a narrow question: can a character be where the scene puts them?

The starter case, The missing lantern, has three characters, four places and six events. Mira appears at the archive and the dock at overlapping times. Theo has four minutes to make a ten-minute journey. Jules says they visited the dock, but that statement is not treated as an established scene.

The app puts physical conflicts beside a timeline and a diagram of authored routes. Select an event, try different times or a different place, and see which conflicts remain. These preview changes stay in the browser; they do not rewrite the author's Sanity content.

It is a tool for checking a fictional draft, not for deciding whether a real person's account is truthful.

Demo

Open Alibi Atlas — no login needed.

Try this short walkthrough:

Select Checks the departing boat. Change its time to 18:34–18:44, then choose Apply to preview. Mira's overlap is resolved, with enough time for the eight-minute journey.
Select Delivers to the keeper and try 18:30–18:38. The second physical conflict disappears.
Select Jules's account needs a decision. Change it to This happens in the story. A new overlap appears: the keeper is now established at the tower and the dock at the same time.
Reset preview restores the loaded story. Inspect report JSON shows the case, changes, findings and source metadata for inspection or manual copying.

Example preview report · 390px layout

Code

GitHub repository — MIT licensed, with local setup, Studio instructions and tests.

The public viewer is a Next.js static export on GitHub Pages. It reads the real public Sanity dataset through @sanity/client. Studio runs separately for authenticated authoring. No write token is bundled into the viewer, and there is no runtime AI call.

My Build Process

Codex generated and revised the implementation, fictional case, documentation and this article. This is a record of an autonomous AI build, not a claim that I wrote the code by hand or a verbatim prompt transcript.

The brief and the schema

The working brief, paraphrased, was to build a fiction-continuity editor backed by real Sanity content. Characters, places, journeys and scenes needed their own documents. A character's statement had to remain separate from an event established by the author. Readers needed to test corrections without changing the published story.

That distinction became an explicit certainty field rather than something inferred from the wording of a scene. Each event also keeps the author's scene or dialogue note visible in the inspector.

Document	Count	What it records
Character	3	Name and role
Place	4	Name and diagram coordinates
Journey	4	Two place references and a minimum time
Story event	6	Character, place, interval, certainty and source note
Case	1	Time window and references to the other documents

The case references those documents instead of storing the story as one block of prose. A GROQ query dereferences them into the graph used by the workbench. Journey times are authored constraints, not estimates from map coordinates. The analysis uses the shortest connected, undirected route; a missing route stays unknown and appears as a review item.

Where the early attempts broke

An initial-value resolver tried to use context.documentId. TypeScript rejected that API. The replacement uses fixed starter IDs and explicit initial-value templates. The starter tool creates the 18 linked documents through the authenticated Studio client and reads them back without overwriting existing documents.

The first architecture put Studio inside the Next.js app. It was separated so the public reader could be a static export while authoring retained its authenticated session. This build uses the Sanity client and Studio, not the App SDK or Sanity Workflows.

The first all-clear wording was too strong when a route could be missing. It now says only that no physical conflicts were detected under the authored constraints. Unknown journeys still need review.

Browser checks also caught a stale validation message after reset. Reset now starts a fresh inspector without remounting it on every input change. The time-input automation changed displayed values without updating React until native key input was used; the final correction checks used keyboard input.

What was checked

All 12 domain tests passed, including nested overlaps, route choice, reported accounts, missing routes and invalid references or intervals. The public Pages workflow passed tests, type checking, the static build and deployment. At 390px, the page had no horizontal overflow; the timeline scrolls inside its own container.

A published description change produced the live-update notice and kept an in-progress preview. An actual Studio event edit reduced the public viewer from two physical conflicts to one after refresh, without preview edits. That test edit was then restored. A complete case readback matched the pre-test snapshot, and the dataset again contained the original 18 documents.

The visible report was read back with two preview edits, zero physical conflicts and one reported-account review. Browser automation did not confirm a completed file download or clipboard contents, so neither is claimed from the buttons alone. The inspectable JSON and linked example make the payload available directly. The controller also stalled on a dirty-preview refresh confirmation; a separate reader verified the new published content, and clean-preview refresh worked.

The prototype handles one case and one time window. It does not infer travel times, prove a statement is true or review every kind of plot hole. The aim is to expose contradictions the author can inspect, with the underlying event and source note still visible.

Sanity Project Details

Project ID: 0k0a3q37
Dataset: production — public, original fictional demonstration content only.
Published documents: 18 across the five schema types above.

The viewer queries published content without a token. Sanity remains the authoring source: publishing a change raises a notice, and the reader chooses when to reload it. A connected query failure shows an error instead of silently substituting the local fixture.