8000 feat(calendar): propose an event from a date said in an asset, sent only once approved by adeelahmad · Pull Request #688 · adeelahmad/lense · GitHub
[go: up one dir, main page]

Skip to content 8000

feat(calendar): propose an event from a date said in an asset, sent only once approved - #688

Merged
adeelahmad merged 1 commit into
mainfrom
claude/project-thread-xfmkzn
Oct 19, 2026
Merged

adeelahmad merged 1 commit into
mainfrom
claude/project-thread-xfmkzn

Conversation

@adeelahmad
Copy link 8000
Copy Markdown
Owner

Requested by Adeel · project thread

Description

Before: dates said in an asset ("let's meet next Tuesday at 3") were read as days, but turning one into a calendar event meant retyping it in the calendar.

After: next to each date said (the Entities tab, under Dates said), Propose event makes an event for a Google Calendar connection an admin let add events. It is prefilled from the line: the day said, at a time said in it ("at 3" is 15:00) or all day; the line as its title; and who it names (for an email, its sender and recipients), never emailed unless asked. It waits in Approvals as an add_event, and nothing is added or sent until the person approves it there, signed in. Declining does nothing. Agents propose through POST /api/v1/dates/propose and the MCP tool propose_event, and can decline but never approve. GET /api/v1/dates says whether proposing is offered.

How: domain/event_proposals.py builds the event from the date's line and files it through the existing approvals flow and the Google Calendar write path.

Motivation and Context

Item from the personal feature plan sheet (dates said become calendar proposals).

Screenshots (if appropriate):

n/a

Steps to reproduce (if appropriate):

With a Google Calendar connection allowed to add events and dates-said reading on, open an asset that says "let's meet next Tuesday at 3", choose Propose event under Dates said, then approve it in Approvals: the event appears in the calendar on that Tuesday at 15:00.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change; ! in the title)

Checklist:

  • The title is a Conventional Commit.
  • My code follows the code style of this project (make hooks checks it on commit).
  • I added or updated tests (tests/api/test_event_proposals.py, tests/api/test_mcp.py, __tests__/said-dates.test.tsx).
  • My change requires documentation updates, and I have updated docs/ accordingly (docs/processing.md#propose-an-event, docs/mcp.md, docs/assistant.md, docs/automations.md).
  • Users need more than the title to understand it, so I wrote it under ## Unreleased in CHANGELOG.md. Written as changelog.d/date-proposals.md, per build(release): changelog fragments in changelog.d/ instead of one Unreleased section #581.

Done questions (AGENTS.md)

  • Goal: delivers what the user wanted, merged on green CI.
  • Agents: usable through the API, MCP or an assistant tool. POST /api/v1/dates/propose and MCP propose_event; agents can decline but not approve.
  • Zero setup: no new prerequisite, .env edit or manual step. Offered only where a calendar connection already allows adding events.
  • Fewest clicks and keystrokes. One click to propose, prefilled; one to approve.
  • Configurable: new settings in the web app with defaults; wizard asks only what is required. n/a: no new setting; uses the existing calendar connection's add-events permission.
  • Light: default install still runs on a Raspberry Pi with cloud models. Rule-based, no model calls.
  • Private and secure: data local and encrypted, passkeys, threat model updated. Approval only by the signed-in person; threat model (md, yaml, json) has the new entry and the validator agrees.
  • Cost: cheapest path, model calls in the activity ledger, budgets respected. n/a: no model calls.
  • User decides: consequential or new actions wait for the user; defaults unchanged. Nothing is added or sent until approved.
  • Upgrades: existing installs upgrade safely (upgrade step for stored-data changes). Proposals use the existing approvals table; no shape change.
  • Honest: sources cited; labelled built, in progress or planned. README built list and docs/requirements.md name the checks.
  • Tests, docs and generated files updated (make openapi, no drift).
  • Open standards; dependencies keep Lens MIT. n/a: no dependencies.
  • Result reported with evidence; "refine later" items written down.
  • Reuse: existing Lens code and permissive libraries reused, nothing reinvented. Reuses dates said, Approvals and the calendar write path.

Local CI: the container runs several times slower than usual, so I ran the changed tests directly: test_event_proposals.py, test_dates.py, test_mcp.py, test_setup_assistant.py, test_scaling_agents.py (71 passed), said-dates.test.tsx (3 passed). ruff, mypy, tsc and the threat model validator are clean, and make openapi shows no drift. GitHub CI decides the merge.


Generated by Claude Code

…nly once approved

A date said in an asset ("let's meet next Tuesday at 3") can be proposed as
an event for a Google Calendar connection an admin let add events: Propose
event under Dates said in the Entities tab, POST /api/v1/dates/propose, or
the MCP tool propose_event. The event is prefilled from the line (the day
at a time said in it, else all day; the line as its title; the addresses it
names and an email's sender and recipients, not emailed unless asked) and
waits in Approvals as an add_event. Only the person, signed in, approves
it; an API key, an app, MCP and the assistant can only decline, and
declining does nothing. GET /api/v1/dates says whether proposing is offered.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QFUNzy1QZy5HhKAyJxTAYJ
@adeelahmad adeelahmad self-assigned this Oct 19, 2026
@adeelahmad
adeelahmad merged commit 6625e93 into main Oct 19, 2026
12 checks passed
@adeelahmad
adeelahmad deleted the claude/project-thread-xfmkzn branch October 19, 2026 15:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

0