MiniMax M2.x reasons inside <think> tags in the normal content field, and
that reasoning is billed against max_tokens. At 4096 the heavier batches
spent the entire budget thinking, were truncated before writing a single
answer, and stripThinking correctly removed the unclosed block — leaving an
empty response.
The signature was distinctive: batches returned 25/25 or 0/25, never
anything partial. 193 of 779 commits went unsummarised with no error
anywhere. At 16384 the same 193 completed 8/8 batches with zero failures.
The interview's question call had the same bug at 1024, where it would have
returned an empty question and silently ended the interview on the first
turn. Now 8192.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
dnd-kit derives the id of its accessibility description element from an
internal counter that starts fresh on the server and is already advanced on
the client. Every sortable card rendered aria-describedby="DndDescribedBy-0"
server-side and "DndDescribedBy-3" client-side, and React reported a
hydration mismatch across the whole board.
A stable id makes both sides agree.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The test overwrote ai_api_key with a marker and then restored it to ""
rather than to its previous value, so every run of the integration suite
silently wiped the AI provider key. Symptom appears much later and looks
nothing like a test problem: AI features quietly stop working.
Captures the existing value first and restores it in a finally block, so a
failed assertion cannot leave the marker in place either. Deletes the
record instead when the test created it.
The suite runs against the shared instance — there is no separate test
database — so anything it touches, it must put back exactly.
feat(board): give the owner both a quick box and Plan with AI
The Phase 4 spec made the intake wizard client-facing only, reasoning that
the developer creates cards directly. That was wrong about how he wants to
work. The quick box stays the default for lines he already understands;
Plan with AI runs the same interview for work that is genuinely unformed.
Hidden entirely when no provider is configured.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The effect that syncs server state re-ran whenever `busy` flipped, which it
does at the end of every drag. It then called setCards(initialCards) with
the snapshot it already had — the server had not re-rendered — discarding
the optimistic move. The card visibly returned to its original column while
the database held the correct value.
Tracks the last adopted snapshot in a ref so the effect only acts on a
genuinely new one, and calls router.refresh() after a successful move so a
new snapshot actually arrives.
Also hardens the timeline drag: the pointerup handler compared against
`dragging` state, which updates asynchronously, so it could read the
pre-drag value and return early with the drag never committing and no error
anywhere. Reads a ref instead, and clears on pointercancel.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two views rather than one chart, because the data forced it: measured on
the live database, 1 of 5 live cards has a target date and none has both
dates. target_date is client-owned and optional; start_date is only set on
Inbox acceptance. A conventional Gantt would render almost empty.
So Now/Next/Later is the default and works with zero dates, and the
timeline earns its place as clients set dates. From Dave's Gantt reference
it takes the quarter header, the Today marker, project grouping with the
client's colour, and the per-row completion percentage — which maps onto
checklist progress, the one honest source for it. The faint full-width
track is load-bearing rather than decorative: it makes a sparse chart read
as unscheduled instead of broken.
Drag-to-reschedule always writes an activity row naming the owner, because
target_date belongs to the client. A developer silently moving a date the
client chose is the failure the activity log exists to prevent.
Completes the plan set for phases 1 through 5.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4a builds the stateless interview. Every constraint that matters is
enforced in code rather than requested in the prompt: the seven-question
cap, the answer length, and what fields a brief may contain. parseBrief is
a whitelist, not a parser — a brief asserting priority or accepted loses
those at the boundary and they never reach a caller that could act on them.
4b adds a separate intake route rather than extending Plan 1a's client
card route. That route's tests were written against a two-field body;
widening the shape it accepts would leave them passing while proving less.
Both routes set column, priority, accepted and created_by_role themselves,
and both are separately proven to.
The property both plans are written to: the worst a hostile brief can
achieve is a strangely-worded card in the Inbox.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A guided interview that produces a written brief with sub-tasks, landing
in the Inbox as a draft through Plan 1c's existing accept flow.
Corrects an over-promise made during the Phase 1 discussion: the wizard
was described as grounding date proposals in measured per-card velocity,
and that data does not exist — Plan 2c deferred per-card effort because
session padding does not sum correctly across cards. This phase therefore
produces no time estimate at all, only a size band.
Names the intake as the highest-risk surface in the product: it is the
only place where text written by someone other than the developer enters
a prompt whose output creates records. The security property is that the
worst a hostile brief achieves is a strangely-worded Inbox card.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three tests cover the storage and access boundary:
- A client manager cannot list the settings collection at all (rules are
superuser-only — verified by the rejection, not by silent skip).
- The settings page HTML returned to the owner does not contain the key
value, even when the key is freshly set to a unique sentinel.
- A client manager gets 404 on /admin/settings (admin layout gates on
role, not on session presence).
helpers.ts gained ownerEmail / ownerPassword — needed by the settings test
and reusable for any owner-only integration test going forward.
3a ports the provider structure from MEGAIFRASTRUCTURE's chat/ — SDK-free
types, one adapter per provider — but deliberately not its interface: this
phase needs text in, text out, not a chat transcript and tool protocol. It
carries forward the MiniMax details that module learned the hard way: the
native /v1 route rather than the /anthropic shim, an Open Platform key, and
stripping the inline <think> blocks M2.x emits.
3b is built around one property: batch responses are matched to commits by
an echoed index, never by position. A single skipped line under positional
matching would attach fluent, confident, wrong sentences to every later
commit, with nothing raising an error.
3c is the first plan whose output a client reads, so its verification step
is to read a narrative as the client would and check it claims no
completion, states no date, and invents nothing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
