irisandClaude Opus 5
acdf00ab1d
A markdown paragraph took every tap that landed on its glyphs, so an opened peer message or memory note could be shut anywhere except on the text -- which is most of it, and reads as a card that has stopped working. Measured on the emulator: with a handler on the text the tap did nothing at all, and with the handler removed the same tap shut the card. The words now do the shutting, through a composition local, since the renderer composes those paragraphs out of its own component table and there is nothing between the card and them to pass a parameter through. The link handler is bounded by the long-press timeout, so holding to select is not a tap. The other half is the tap that puts a selection away, which used to shut whatever card the words were in. The container clears the selection from that same press, milliseconds before the card reads it, so the answer is taken at composition instead -- what was true when the reader touched the screen. Selection colours are the app's own. Material's 40% of primary is a tint of whatever is behind it, and over the near-black a code block sits on it composited to a smudge, so selecting a line of code looked like nothing had happened. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.3 KiB
2.3 KiB
TODO
Working list from Iris, 2026-09-03. Remove an entry when it lands; annotate one in place when it turns out to need a decision.
App — transcript
- Text inside code blocks does not highlight when selected. Measured, and
it does — the selection is drawn, but over the near-black surface a code
block and a tool's output sit on, Material's default 40%-alpha tint
composites to a barely-there smudge, much weaker than the same selection
over a reply. The app now states its own selection colours
(
AiAppSelectionColors), which took the fill from #5B4C73 to #776394 on that surface. Worth confirming this was the complaint rather than a selection that draws nothing on the phone. - Text inside an opened peer message or memory note cannot be selected at all — the heading of the same card can, and so can a tool call's output, so it is the markdown text specifically. Pre-existing (measured against the build before this session's changes, by stashing them). It contradicts AGENTS.md's "all transcript text is selectable".
- Messages received from other agents are inconsistent — sometimes they
appear, sometimes they don't. Needs a rig. Read the code rather than
measured: a live Claude session only learns of a peer message from the
originobject on a turn'sresult(session/claude/translate.rs), which the CLI attaches to a turn the message started. So a message that arrives mid-turn, or a second one within one turn, has nowhere to be reported — while an imported session, which syncs from the CLI's own file, picks up every one of them. That would show exactly as "sometimes". Confirming it means driving a real stream-json session and sending it messages in both states.
Session settings
- Autocompact belongs in session settings; empty disables it, which is the
default. Needs a decision before building — nothing called autocompact
exists yet on either side.
PLAN.mdhas it only as a planned pi-driver feature (set_auto_compaction), and Claude Code runs its own. So this is a new server feature, and the open questions are what the empty-or-not value is (a token count? a percentage of the context window?) and which drivers it applies to.