All three were found by the day-planning eval and reproduced against a
real model before being fixed.

decidedTaskIds was a permission set the model wrote itself. The parser
accepts a block's taskId when it appears either in decidedTaskIds or in
allowedExistingTaskIds — but only the latter was resolved against the
journal and filtered by the agent's allowed categories. A model could
therefore reference a deleted task, a non-existent one, or one in a
category this agent may not touch, simply by echoing the id into its
own draft_day_plan call, defeating the check the sibling branch
applies. Both sets now go through the same resolution. Legitimate
decided tasks are unaffected: they are hydrated for the prompt through
hydrateDecidedTasks, which already applies exactly this filter, so the
only ids dropped are ones the model was never given.

The prompt offered a cal exemption whose precondition can never hold.
It told the model that "only cal blocks mirroring real calendar events
may span" the current time, while the agent is shown no calendar at
all — calendarBlocks is documented as deferred and RealDayAgent drops
it. So the exemption was a standing invitation to plan the past, and
any cal block that persisted left the user with a block the plan
editor refuses to edit and their calendar has never heard of. Closed at
all three levels: the parser rejects a model-emitted cal block, cal is
gone from both tool schemas, and the prompt no longer promises it. All
three come back together whenever calendar events are actually wired
into the drafting context.

Block state bypassed the same-day guard. The guard fired only for
state == drafted, so writing a new block as committed placed work
before the current time — the same probing as the earlier trick of
relabelling a past-starting block buffer, one field over. The guard now
keys on what a state means: drafted and committed are plans and are
guarded; inProgress, completed and dropped are history a re-draft
legitimately carries forward.

Review found the first fix half-done: it closed the draft route and
left the refine route open, which is the same mistake twice rather
than two mistakes.

propose_plan_diff accepted `to.taskId` with no validation at all —
never resolved, never category-checked — and acceptPlanDiff copies it
onto the live plan. The approval summary the user reads carries the
title and times but not the task reference, so an approved diff could
attach a deleted task, a non-existent one, or one from a category this
agent may not touch, and the user would never have seen it described.
Both routes now share one resolveAllowedTaskIds; two implementations
with only one of them resolving the id is what produced the original
hole.

The same asymmetry applied to `cal`: removing it from the tool schema
does not stop a diff supplying it, and optionalBlockSnapshot happily
parsed it. The diff path now refuses it with the same reasoning, and
for the same user-facing consequence — an approved block whose type was
never shown and which the plan editor afterwards refuses to edit.

And a regression I introduced: a legacy `agreed` plan can hold
`committed` blocks the user already approved, so once one had started,
guarding `committed` rejected the entire redraft for faithfully
repeating what was already on the plan. A block that matches a
baseline block's id *and* start is carried forward and exempt; reusing
a known id at a new time is still planning the past.

…he request arrives

Review found the same shape three more times: a check placed at the
point a request is parsed, while the data reaches the plan somewhere
else entirely.

A ChangeSet is durable and synced, so proposal-time validation does not
bind. It can be accepted long after it was written — by which point the
task may have been deleted or moved out of the agent's categories, and
the part of the day it aimed at may already have passed — or arrive
from a peer on an older build that never ran the check at all.
resolvePlanDiff now re-resolves task references against the journal and
re-derives the clock at apply time, and the apply-path batch validator
refuses `cal` and past starts as well as the categories and timestamps
it already checked.

propose_plan_diff gains the past-start guard too, so refining today's
plan cannot place work in a part of the day that has gone, any more
than drafting it can.

Carrying a baseline block forward now requires the same state as well
as the same id and start. Matching id and start alone let a known 09:00
id be reused to drop a brand-new committed block into that slot,
rewriting approved work without the refinement approval that gates it.

Deliberately not tightened: a past-starting block in a *history* state
still needs no baseline. The first draft of a day can happen in the
afternoon, and the capture is where the agent learns what the morning
held, so requiring baseline evidence would forbid recording real work.
Whether a model should be able to invent that history is a live
question the eval already measures; it is a product decision about what
a plan may record, not one to settle by tightening a guard mid-fix.

The past-start guard on the refine path was too blunt. A full `to`
snapshot carries the block's unchanged original start, so extending
the end of a block that began at 09:00 was refused at noon for saying
09:00 — and a pending change accepted after its block started hit the
same wall on the apply path.

Both sites now compare against the live block and refuse only an
actual relocation. `add_block` has no live block, so any past start
there is still a genuine placement into the past.

Also documents the state match a carried-forward block requires, which
the README described as id and start alone.