Repository navigation
feat(memory): show each card type in one layout on every surface - #280
Merged
Merged
Conversation
The chat shows a card as the HTML Matrix allows, with the markdown as the plain `body` (ADR-016 §4). Every bot now converts that markdown with `stack.matrix.html.matrix_html`, so a card or an answer reads the same whichever bot sends it. Task lines (`- [ ] …`, `- [x] …`) show as ☐ and ☑: Matrix allows no checkbox, and the bare brackets read as noise.
`stack messages send` converted markdown with its own subset, which made every line a paragraph of its own, bold `<b>` instead of `<strong>`, and a list of any line starting with `- `. The same text sent by a bot read differently. The host cannot import the `markdown` package the bots use, so it keeps a standard-library subset (paragraphs whose newlines stay breaks, `- ` lists, bold, code) and a test holds it to the output of the bots' converter for that subset.
A card type now has one renderer, and it writes markdown (`stack.card_render`, ADR-016 §4). The chat, the card browser and the agent will all show a card from it, so a note, a document or a diary entry reads the same in each. A rendered card is its title, one line of the facts that matter for its type (date, people by name, correspondent, kind), the type's own sections (summary, facts, to-dos, media, its text), and the person's own words last, quoted, with the replies after them. Each field appears once: the meta block under the heading, a second title and `Person:` tags are not shown. Due dates keep the one form the files write (`📅 2026-10-15`). A type without a renderer of its own shows its title, its fields as a list and its body. `stack memory card` shows that markdown in place of the file's text, and with `--json` returns it in `rendered`, one per card.
`GET /card/<id>` now carries `rendered`: the markdown the card's type renderer writes (ADR-016 §4), the same that `stack memory card` prints. A page shows that instead of laying out each card type on its own. The to-do label follows the household's language.
The card browser laid out every card type in its own JavaScript: a facts grid for a document, a day banner for a diary entry, its own list of items for a list. Each card's body is now the markdown the cards API renders for it (`rendered`), the one the chat and the agent read too, so a card looks the same in all three. The header, the people, the tags, the media players, the views and the walk stay. Task lines show a box, ticked when done; due dates show as the card writes them (`📅 2026-10-15`) instead of a date in the browser's language.
The archivist's replies laid out a filing in their own way: a row of topics and people joined with `|`, facts indented by two spaces, a due date as "(due 2026-03-15)". The filing reply, the capture reply, the diary card notice and the search hits now show the card through the renderer the card browser and the agent use (ADR-016 §4): - the first line names what was filed, then the card's line of facts (date, people, correspondent, kind), its summary, facts and to-dos, with due dates in the form the card writes them (`📅 2026-03-15`) and the to-do label in the household's language - a search hit is the card's title and line of facts - media is a link and links into the memory repo are names, since the chat shows neither Topics are no longer listed in a reply: the card shows them as tags.
`docs/stack-reference.md` now says what each card type's renderer shows, which surfaces show it, how the chat turns its media and links into what it can show, and that every bot converts markdown to Matrix HTML with one function while `stack messages send` keeps a subset held to it.
Framework code names no household. No behaviour change.
A capture whose message was only a caption files it as the title and under `## Caption`, so the rendered card ended with its title again. Own words that equal the title are left out.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
lib/stack/card_render.py, ADR-016 §4). The archivist's chat replies and search hits, the card browser andstack memory cardall show a card from it: the title once, one line of facts, the type's sections, then the person's own words. People show by name,Person:tags and the meta block are not shown.stack.matrix.html);stack messages sendkeeps a standard-library subset that a test holds to the same output.rendered, andstack memory card --jsontoo.