A commitments board for what people promised in meetings

Build me an app that tracks every commitment people make in meetings. Ours get lost between scattered notes and nobody remembers who promised what by when, so I want one persistent board of promises rather than another checklist. The General Input Database is the anchor and the system of record: it owns the commitments, their owners, due dates, status history and the link to the calendar event each one came from. Every read and write in the app goes through the user-database Execute SQL operation, and on first run the app should use Create or List Databases to find or create the database and then create its tables if they do not exist.

Use roughly this schema, adjusting names as you see fit. A commitments table with: id, owner_name, owner_email, promised_to (the person or team the promise was made to), commitment_text (the actual wording of what was promised), due_date, original_due_date, times_moved, status (draft, open, done, cancelled), calendar_event_id, meeting_title, meeting_start, source (agent or manual), created_by, created_at and closed_at. A date_changes table with: id, commitment_id, previous_due_date, new_due_date, reason, changed_by and changed_at. A nudges table with: id, commitment_id or owner_email, sent_by, sent_at, slack_target and message_preview, so every nudge that has ever gone out is visible on the board.

The app opens on a board of commitments. Each card shows the owner, what they promised in their own words, who they promised it to, the due date and the meeting it came from. Give me these views over the same shared record set: overdue first (anything past due, most overdue at the top, with days late on the card), by owner (grouped per person with an open count and an overdue count each), by meeting (grouped by calendar event, so you can see everything that came out of Monday's planning call), and recently closed (what was completed in the last few weeks, so the board shows follow through and not just debt). When a person opens the app, default them to their own open items, filtered on owner_email matching the signed in viewer, with one click to see the whole team's board. Every one of these views is a SELECT through Execute SQL, and creating, editing, completing or cancelling a commitment is an INSERT or UPDATE through the same operation.

Use the Google Calendar List Events operation to pull recent and upcoming meetings so a commitment can be attached to the meeting it actually came from. Scope it to a window such as the last 30 days through the next 14 days, expand recurring events into individual instances, and order by start time. Show that list wherever someone attaches or reassigns a meeting, and support searching it by title since busy calendars are long. Store the calendar event id on the commitment along with a copy of the meeting title and start time, so the by meeting view still reads correctly even if the calendar entry is later changed or deleted.

Include an "Extract commitments from this meeting" button that kicks off a background agent. The person picks a meeting from the calendar list and pastes in the notes from it, and the agent reads the notes, parses out each distinct commitment, and works out the owner, the exact wording of what was promised, who it was promised to and the due date. It should resolve relative dates like "by end of week" or "before the next sync" against the meeting date, and leave the due date empty rather than guessing when the notes genuinely do not say. The agent writes its findings back through Execute SQL as rows with status set to draft and source set to agent, tagged with the chosen calendar event id. Those drafts never appear on the main board. They land in a review queue where a person reads each one beside the line of notes it came from, edits the owner, wording or date, then confirms it (which flips the status to open and puts it on the board) or discards it. Show the run in progress and land the drafts in the queue when it finishes so the app can display them without the person going anywhere else.

Nudging is always an explicit button, never automatic. When someone presses nudge on an owner, the app uses the Slack Bot Look Up User by Email operation to resolve that owner's email to a Slack user, then Send a Message to direct message them a short, friendly list of their open commitments with the due date and source meeting on each line. Log every nudge to the nudges table and show on the card when the owner was last nudged and by whom, so nobody gets pestered twice in a day by two different people. Do not add any scheduled or background nudging anywhere in the app.

Re-dating a commitment must keep the original date visible so slipped promises stay obvious. When someone changes a due date, keep original_due_date as first captured, write a row to date_changes with the old date, the new date, who moved it and an optional reason, and increment times_moved. The card should read something like "due 17 March, originally 3 March, moved twice", and the overdue view should treat repeat movers as worth noticing rather than quietly resetting the clock. Completing a commitment records who marked it done and when, and it drops into recently closed rather than disappearing.

Keep the whole thing fast to work in: inline editing on the board, a quick add form for a commitment someone remembers after the fact, and a search across owner, wording and meeting title. The people who use this are whoever sits in the meetings, so it has to be readable by someone who has never seen the app before and does not want to learn a workflow.