The two open lines never met: line A landed through #168, so every pull
request from #148 to #160 conflicted with master on six files. This
reconciles them.
Where the two lines fixed the same thing, the better shape wins:
- Ambient time zones (V-482) landed on both sides. Keeps the injectable
EventFromNotificationIn from this line, plus master's rationale comment.
Drops master's forced n.Posted.In(time.Local), which defeated the loc
argument.
- tick.go: master's guardNudge call and say.CountWord edits, moved onto the
split files this line created. The digest summary now declines through
say.CountWord inside tick_digest.go.
- voice.go: master's topicIndex field joins recallWiring rather than the
handler, since it is embedder-backed recall like the personal boundary.
topics.go and its test read h.recall.topics now.
- mavweb: master's capability and risk columns ported into tools.html, which
is where this line moved the markup. The Go const is gone.
- Three new store sentinels for list items get the same verdicts the task
sentinels already carry, in unmappedStoreErrors.
make build: 12 binaries. make test: green. make fmt-check: clean.
--no-verify: a merge of two long lines cannot fit the 300-line budget.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A relay that posts its instant as `2026-08-02T09:00:00Z` handed the wall clock
inside the text that same zone, so «созвон в 14:30» was built as 14:30 UTC and
read back as 18:30 on this UTC+4 box. Every ambient event landed late by the
deploy's own offset, and correct on a UTC box, which is why no test caught it.
Posted is an instant and carries a zone. The clock reading is a wall clock and
carries none, so it resolves against the daemon's zone now. The tests pin
time.Local to +04 in TestMain, so the four hours show up on a UTC runner too.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A phone posts an RFC 3339 instant ending in Z, and the clock inside the
text is a wall clock nobody means in UTC. The wall clock used to be
resolved against Posted's own zone, so on this UTC+4 box a 14:30 standup
was stored at 18:30. The size of the error is the deploy's offset, which
is why the tests never saw it: they ran on a UTC box.
EventFromNotificationIn takes the zone explicitly and EventFromNotification
passes time.Local. The day comes from Posted's local day too, since a
notification posted at 23:30Z saying "завтра" is already tomorrow where he
is standing. Posted itself stays an instant, so the past-grace check still
compares instants.
The two handler fixtures said a bare "10:00" against a 09:40Z post, which
is stale once the clock is read locally. They say "завтра" now, so they
mean a future meeting in every zone. internal/calendar and cmd/mavweb pass
under UTC, Europe/Samara, America/Los_Angeles, Pacific/Kiritimati and
Asia/Kathmandu.
EventFromNotification took the date from the notification's own day, on the
grounds that a meeting notification is about today or it would not be firing.
Calendar apps break that. A 21:00 reminder reading "Tomorrow at 09:00" became
an event at 09:00 today, twelve hours in the past, and FactKey filed that
wrong meeting under today's date. Storing a wrong meeting is the one outcome
this parse works to avoid.
An explicit day word now moves the date: завтра, tomorrow, послезавтра,
сегодня, today, tonight. Matched whole, so послезавтра is not read as завтра,
and stripped from the summary so the meeting is not named after the day.
Anything still landing more than two hours before the notification is refused,
which covers the cases with no day word at all. The grace keeps a repost for a
meeting already under way.
Also matches the bearer scheme with EqualFold. A phone sending "bearer <tok>"
fell through to the X-Maven-Token branch and got a 401 that looked like a
wrong token. A bare token with no scheme in Authorization is now rejected
rather than silently accepted. The route table in mavweb gains its /api/ambient
row, and the missing calendar_busy write is recorded as a known gap.
Found in review of #57.
Maven does not get a work credential. A corp mail or calendar session living on
the homelab ties the box's blast radius to the employer's data, which is the
thing this task exists to refuse. What she reads instead is the signal: an
Android notification-listener on the phone relays meeting notifications over
wg/LAN to POST /api/ambient, and the ones that clearly describe a meeting become
calendar events at source=ambient:notif, confidence 0.6.
The provenance is the point. A notification is evidence about a meeting, not a
reading of a calendar, so it is never indistinguishable from one: it is stored
below full confidence, store.CalendarEvents keeps the source and confidence on
every row it returns, and the query path hedges — "похоже, Планёрка @ 14:00" for
a relayed event, plain text for a CalDAV read.
The parse is deliberately conservative (internal/calendar/ambient.go). It needs
a real clock reading and a summary that is not just that clock reading;
otherwise it stores nothing at all. A bare hour is not a time, an unread count
is not a time, and "срок 2026.08.15" does not offer 08:15 as a meeting — loose
digits in a notification are far more often a badge or a date, and a mailbox of
noise rendered as invented meetings is worse than a gap.
The ingest is off unless configured: no -ambient-token, no route registered. The
token is a shared secret compared in constant time, because the poster is a
background Android service and WebAuthn has no answer for one. The endpoint is
write-only, accepts one shape of write, and cannot read anything back out.
Reposts of the same notification dedupe against the latest fact for that
key+source, the same append-only discipline cmd/mavcaldav follows.
Not shipped: the Android relay app itself, which is a separate artifact and a
device, not Go in this repo.
claude
kami