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>
42 lines
2.3 KiB
Markdown
42 lines
2.3 KiB
Markdown
# 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
|
|
`origin` object on a turn's `result`
|
|
(`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.md` has 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.
|
|
|