Four lifecycle cards — review, recommendation, schedule proposal and verification — drawn where a reader actually meets them: inside the chat conversation, between one message and the next. Each card is the surface that already carries its work on its own page, composed into the thread rather than redrawn for it; every section names the page its surface comes from. Part of Cinatra Application Design; match it exactly.
This page composes; it does not restyle. Each surface below is reproduced from the page that fixes it, at that page's own markup and tokens. Some surfaces have no drawing on any of these pages and say so where they appear.
| Surface | Drawn on |
|---|---|
| Review target, artifact tiers, decision floor, review states, recommendation chip-row | Agent run & review |
| Schedule option rows, the scheduling form and its controls | Components · Standard scheduling step |
| Suggestion chip | Artifacts · type picker |
| Thread measure (the Wide cap) | Application Design · Content widths |
| Conversation chrome · the bound, unbound and cannot-act rows · verification card | Not drawn on any other page — §I, §VII and §X–§XII |
The thread is the frame. A lifecycle card is never met on its own — it arrives in a conversation, after something a person asked and before whatever the assistant says next. The stream and the composer both cap at the Wide measure and sit centred (Application Design § Content widths).
Two turn shapes. A person's turn is right-aligned: their name and initials above, then a filled bubble that hugs its text, then the quiet copy and edit marks beneath. The assistant's turn is left-aligned and carries no bubble — the Cinatra mark and name, then the content on the thread ground, filling the column. A card takes that content slot, at the column's full width, exactly where prose would otherwise sit.
The turn shapes and the composer above have no drawing on any Application Design page — only the thread's Wide measure is fixed, in § Content widths. This page is where they are now fixed, and they borrow rather than invent: the composer takes the 8px radius the prompt window already gives a conversational input, and every colour is a shared token. Everything inside a card, from §II on, comes from a page that already draws it.
The composer knows which card it answers. A single open review binds it with no press at all — sending is then the same act as pressing that card’s own control. A row above the floor states the binding and gives it back with one press. Where more than one review is open, none is bound until the reader picks one, and the row says so rather than route a guess.
One input, not two. A conversation carrying a card has two places a reader could type — the card's own note field and the conversation's chat box — and drawn at the same weight they read as a choice, so it is genuinely unclear where to type. They are not a choice. The chat box is the one primary input: it is where a reader types by default, and the prompt window acts through it on the active card — the card bound to it — under that card's own authorization. The note field is subordinate: it stays, because the note belongs with the decision it rides, but it is never drawn as a second place to hold a conversation.
How the weight is taken off it. The note field gives up the three things that make the chat box read as somewhere to type — the enclosing box, the raised ground and the send affordance — and keeps a single quiet ruled baseline under a mono label. The chat box keeps all three and takes the line-strong edge, so the primary input is the darker-edged one on the page. Nothing is hidden and nothing is disabled; only the weight moves.
No box of its own, no fill, no send. A ruled baseline under a mono label — it reads as a field on the card, not as somewhere to start typing.
Its own box on the raised ground, the line-strong edge and the send affordance. This is where a reader types, and what the prompt window acts through.
Exactly one primary input is drawn per conversation, and it is the chat box. Any field a card carries is drawn subordinate to it. Where there is no chat box to be subordinate to — the run page and the review page — the card's field is the only input there is and takes the primary treatment instead. The hierarchy is between the two inputs, not a fixed look for either one.
Same panel as the floor beneath it: the 8px radius, surface-strong ground and a single line border. The toggle is the floor’s own secondary/ghost button, pressed when bound. Its trailing line reads in muted for both quiet readings — bound and given back — and turns mustard-ink only where a typed message cannot act on a card at all — more than one review waiting to be chosen, or a conversation that cannot use a card's controls.
One card, one gate. The review card fills the assistant's turn: the target panel naming what is under review and pinning its exact revision, then the decision floor that governs it. Both are reproduced from Agent run & review — the target's inert header (§IV) and the comment / regenerate / continue floor with its note field (§VI) — unchanged by the move into the thread.
One artifact per review, never a combined one. A gate pins one artifact at one reference, so a card carries one target panel over one floor. Work that made several artifacts is not gathered into a single card: it raises one review per artifact, in order, and the run waits at each. Comment is non-terminal — it annotates and leaves the card pending, so the thread simply continues beneath it.
Three affordances, weighted apart: Comment quiet at the left, Regenerate in the outline treatment and Continue primary at the right, over the one note field.
Typing the request into the chat box at the foot of the thread is the request — there is no fourth button. The corrected revision returns as a new review card further down the same thread, so the exchange stays in one place.
The composer bound to one card — the row above the floor that names it and gives it back with one press — is fixed in §I. What that binding does to the card, and what the reader sees while it does it, is §X. A change request is typed into that composer: Agent run & review §VI fixes typing a request as the whole affordance, and inside a conversation the composer at the foot of the thread is where it is typed. No prompt window is drawn inside a conversation — the prompt window is the box outside the chat.
Before the card, the slot holds its placeholder. A run that will ask for a review carries, in the slot the review card will fill, the run progress card — and while the run is working that card is a placeholder for the review screen: the card frame, and a spinning icon, the indigo arc of Components § Skeleton / Spinner. It names no status, reports no result and draws nothing to press.
The placeholder is replaced, in place, by the review. When the run's output is generated, the placeholder becomes the Review requested screen — the same slot, in the same turn. It happens on its own: the reader neither asks for the card nor presses anything to bring it.
The card carries no link to the run page. No Open the run page link is drawn beneath it.
One slot, twice: the same turn, in the same place, carrying first the placeholder and then the review card.
The rule above, in a reading. A run that writes a post and a picture for it does not raise one combined card. The post comes up for review first, drawn by the blog-post extension’s display — and what that display renders is the post itself: its title and its body text. The picture is not in it — the featured image is a separate artifact, related to the post but not part of it. Then the featured image comes up for review on its own, drawn by the blog-image extension’s display. A blog run makes one picture, so the run raises two artifact reviews and no third; a regeneration adds a successor gate over an artifact already reviewed, never a third artifact. The run waits at each: one gate is open at a time, in its own assistant turn, and the second review is raised only once the first is decided. The assistant’s line above each card names the artifact that review is for.
A display brings its whole renderer, review or not. The post is drawn by the markdown display, so it carries that display’s Code and Preview tabs here exactly as it does on the artifact’s own page (Agent run & review §V.1) — the tabs are the renderer’s, not the card’s, and a renderer does not shed part of itself because of where it is read. On a review target both tabs are read-only: Preview is the active tab, Code is one press away, neither is editable, and there is no saving indicator to draw — nothing on this card can move the revision the gate pinned (Agent run & review §IV). The strip is the display’s own header and it holds the tabs alone — no renderer chip and no provenance line, here or anywhere else a display is drawn (Agent run & review §V). Read-only is what the panel is, not a word it wears. No picture is drawn on the post’s card at all — not inside the rendered post, because the display renders the post’s own representation and composes no other artifact into it; and not beside it, because a card carries one target. The featured image gets a panel of its own on the review that follows.
What each review decides — the same floor, both times. Both cards carry the same three affordances: Comment, Regenerate, Continue. The reader continues and the run goes on with the revision on screen; or regenerates, and the work is made again from the words in the card’s note field. On the post’s card that field opens empty; on the featured image’s card it opens carrying the prompt that made the picture, there to be edited — and words the reader never touched are not filed as the reader’s if the card is continued or commented instead. The floor’s Comment is a different act again: a note recorded against the review that leaves the card pending and asks for nothing. Asking for changes is a fourth road and still not a fourth button: it is typing the request into the composer at the foot of the thread (§II above, and Agent run & review §VI). It is not Regenerate said differently: Regenerate runs the same producing step again from the note field and settles the card superseded beneath a successor over the same artifact, while a typed request is read by the run, which works out for itself what to change and how, and settles the card changes-requested. Nothing to press sits on the picture itself — the display draws the work and nothing more, and the target header the gate draws stays inert (Agent run & review §IV). A reader who wants none of it leaves the card as it is.
Regenerating re-opens one review, not both. Pressing Regenerate on the featured image’s card appends a revision to that picture alone and mints a successor gate for that picture: a pending gate’s pin is immutable and a differing reference is refused, so the picture’s review re-opens as a fresh card further down the thread, on what the reader will now decide, and the earlier gate is settled as superseded. The post’s review does not re-open for the picture’s regeneration. A decided gate keeps and shows the target it froze — one artifact per review, one reference per gate — so a settled card and a superseded one still draw what they were about, at the revision they were about it.
One target per card and one floor beneath it — and the order on screen is the order the run asks in: the post, then its featured image. Regenerate sits on the floor, beside Continue, and never on the picture; pressing it settles that card as superseded and raises its successor beneath it, while the post’s decided card is left exactly as it was.
Pressing Regenerate does not redraw the card in place, and it does not reach the post’s review. The revision this card pinned is what it keeps; the new picture arrives as a fresh review card further down the thread, and this one is marked superseded — the same rule that makes no longer open a drawn state rather than a silent swap (§IV). The post is a separate artifact and is not revised when the picture is regenerated: its own review is not re-opened, and its decided card keeps the revision it was decided at.
A target is never blank. Where the artifact's type resolves to a renderer, the target shows it — and says nothing about it. A build-time renderer the defining extension ships and a runtime one from an installed extension are drawn the same way: no chip, no package identity, no provenance line, because a reader is deciding on the work, not on what drew it. Where no renderer resolves, the target falls to the metadata floor, which does say so: a sanitized one-line diagnostic above the generic read-only view of the representation. Which of the three a target shows is decided by the renderer, never by the host the target is read on; below, only the captions tell the tiers apart. All three are reproduced from Agent run & review §V.
All three drawn on Application Design — Agent run & review §V
A third presentation — a pinned capture pair, setting a reviewed image beside the applied one — belongs to this ladder but has no drawing on any Application Design page. It is deliberately not invented here. Until it is drawn, a target whose renderer does not resolve shows the metadata floor above, which is drawn — the same fall, on every host.
Four drawn states, and one that draws nothing. A card is loading while the host prepares the target; restricted when the reader may see the gate but not decide it — the terminal affordances disabled, the reason shown; and no longer open when the gate was already settled or the run moved on, offering a refresh rather than letting a stale decision through. All three are reproduced from Agent run & review §VII.
You can respond to this review, so Comment and the chat box are live — but a terminal Continue / Regenerate needs approve access on the run, so those stay disabled with the reason shown. (A viewer with no run access never reaches the surface — they get the not-authorized panel.)
This review is no longer open
The gate was already decided or the run moved on. Refresh
All three drawn on Application Design — Agent run & review §VII
Restricted is a card that renders: the reader sees the target and the disabled floor, with the reason on screen. Absent is no card DOM at all — a reader who may not read the target gets no panel, no placeholder and no reason, and the assistant's turn carries only its prose. A withheld card must never be drawn as a disabled one, and a disabled one must never be silently dropped.
Shaping the work before it starts. The row is drawn in the assistant's turn, after the assistant has started the run: the assistant says it dispatched the agent and that the run paused for a decision on the recommended skills — the run is dispatched and held at that gate, and none of its work steps has run, which is what before the run starts means throughout this section — and that same turn carries the chip-row beneath the line — one pill per skill, each carrying a checkbox in front of its label. The label reads the skill's name and then by its vendor, on one line, the vendor in the muted secondary colour — so two skills of the same name are told apart in the pill itself. A checked box means that skill is applied to the run; a box left clear leaves the skill out. The row is reproduced from Agent run & review §II.
The row and its Continue are the whole card. There is no heading plate above the row, and a pill carries nothing to press — no Confirm, no Adjust, no Skip. The reader sets the boxes and presses Continue beneath the list — the same Continue the HITL screen draws — and the whole row is answered at once, every box together.
One row, three readings. While the question is open the boxes take a change and Continue stands beneath them. Continue does not close the row. For as long as the run has not started, a reader who comes back to the Skills step is shown the same pills with the boxes still able to take a change and Continue still beneath them, and may change the selection. Once the run has started the same pills are drawn with the state their boxes were left in, read-only, and with no Continue — and that is the reading a reader is shown when they select the Skills step of a run that is under way (Agent run & review §I). No reading is ever redrawn as a row above another card.
@cinatra-ai/outreach (runId: run_5c2d…, status: pending_input). The run paused for a decision on the recommended skills.Continue is not a lock. For as long as the run has not started, a reader who comes back to the Skills step gets this reading: the boxes as they were left, each one still able to take a change, and Continue beneath them to keep the new selection. The row is still the whole card — nothing is summarised above it.
Once the run is running, the selection is fixed and the row is read-only: each pill states in its own box whether that skill was applied to the run. No Continue is left beneath it, and nothing is left to press.
Shaping this run needs run access on it. Every box, and the Continue beneath them, stays on screen disabled — the reader sees exactly what is being asked, and that it is not theirs to answer.
A row with every box clear is still the whole card. There is nothing to skip and nothing that means skip: clearing every box and pressing Continue is an ordinary answer to the same question, and the run goes ahead with no recommended skill applied. The row keeps its place, drawn exactly as any other row is — one pill per proposed skill, every box clear — and the boxes themselves state that none was applied. Nothing is summarised above the row, and no panel stands in for it.
A row whose boxes were all left clear is not the same as a card the reader may not read. Absent (§IV) is no card DOM at all, and it is reserved for the reader who may not see the thing. A row the reader did see keeps its place in the turn and states, box by box, that no recommended skill was applied — otherwise the question, the answer and the fact that nothing was applied all vanish from the transcript together, and nothing on screen says any of it happened.
The row and its Continue are the whole card — no heading plate above it, and one control beneath it. A pill carries a checkbox, the skill's name and its vendor, and nothing else; the boxes are set together, and Continue keeps the whole row in one act.
The card is the scheduling step, in the turn — and it is the only thing drawn. Asked to run something later, the assistant reads the schedule out of the reader's own words and shows it back as the standard scheduling step: the question When should this run? over the three option rows, the chosen row taking the indigo edge and tint and owning its fields, and the estimated duration beneath. It is reproduced from Components § Standard scheduling step. There is no raw cron field: the schedule the reader stated is what the reader sees and confirms.
One card, five readings, and never a second card. The card is drawn once and stays where it is; what changes across its life is the floor beneath the rows and whether the rows still take a change. No summary box is ever drawn, no status label, and nothing stands between the reader and the form — the rows are the reading.
| Reading | The rows | The floor |
|---|---|---|
| First shown — nothing exists yet | editable | Confirm |
| Configured — the schedule as it stands | editable | Save changes |
| Expired — nothing was scheduled | editable | Confirm |
| Fired, one-off — the schedule was spent | read-only | none at all |
| Fired, recurring — runs still to come | editable | Save changes · Cancel schedule |
One line above the card, and it is this section's own. A turn that carries a schedule card draws exactly one prose line, and that line is the sentence this section gives for the card's reading — the platform's own sentence, said in the turn: never softened, never re-worded, and never joined by a second line above it or beneath it. A reading's words do not change with the occasion: the first shown, configured and expired readings drawn below all carry Schedule proposal is ready. Confirm it on the card below and I will arm it; change the rows first if it is not right. word for word, and each reading whose schedule has already fired carries its own sentence instead — neither of which calls that schedule a proposal.
The scheduling step on Components arms its trigger directly on Continue, because there the run already exists. On this card nothing exists until the reader confirms, so the floor is Confirm. It is the only control: there is no Adjust, and no step to press before the rows can be changed — the rows are editable as they stand, and correcting them is the ordinary thing to do. A control that has to be pressed before the form appears would put a door in front of a form that is already open.
Confirmed, the card stays exactly where it is. No second card is drawn and nothing is summarised: the same rows show the schedule as it stands, and the floor becomes Save changes — quiet until a row is actually changed, because there is nothing to save until then. Changing a row and pressing it re-arms the schedule.
Nothing was added and nothing was replaced. Read the two examples above against each other and only one thing differs: the word on the floor.
An expired card stays visible, and stays editable. A card that was never confirmed expires on its own after thirty minutes. It does not vanish and it is not greyed out: a short line above the rows says nothing was scheduled, the rows still take a change, and Confirm is offered again so the reader can set the schedule from the same card.
This schedule expired before it was confirmed. Nothing was scheduled — change it if you like, then confirm it again.
The line is the only thing the expired reading adds. It never reveals whether a token was expired, foreign or forged — it says what happened to this schedule and what the reader can do next.
Once it has fired, the card is a reading. A one-off that has fired cannot be changed, so the rows go read-only — the values still legible, the pickers gone — and the card carries no floor at all: no hairline, no button, nothing to press. A spent schedule is still worth reading, so nothing is hidden; it simply asks nothing.
Only a one-off — Run right after setup or Schedule for later — reaches this reading. A recurring schedule is never spent by firing: its past runs are history and its runs still to come stay changeable, so it keeps editable rows over Save changes, and gains Cancel schedule beside them — drawn next.
A recurring schedule is not spent when it fires: the rows still take a change, Save changes is still the floor, and Cancel schedule stands beside it. Pressing it stops the recurring schedule, and the rows are not editable after that.
Once it is stopped, the turn says so in the past tense. Above a stopped recurring card the one line the rule above fixes for every reading is The recurring schedule was stopped; its rows are no longer editable. — it reports the press that was already taken, and it is never the description of the control itself, which speaks of a press still to come.
Wherever a schedule is read — this card, the run's schedule step (Agent run & review §I), the widget — it is drawn as this form in one of the five readings above. There is no Trigger configuration panel, no held-steps list beside it and no Adjust anywhere: a reader who wants to know when something runs reads the rows, and a reader who wants to change it changes the rows. Cancel schedule appears only where the schedule is recurring, and it stops the recurring schedule and then leaves the rows no longer editable. There is no Run now — not on this card, and not on the run's schedule step.
An advisory reading, not a decision. After a repair, the turn may carry a verification card: the Core analysis heading with its outcome pill, the scope sentence, the two revision pins, and the field-by-field before / after of exactly what was inspected. It carries no floor at all — it asks nothing, so it draws nothing to press. It closes with Advisory comments: a label over one panel per comment, each carrying its author kind in mono above the comment itself. The reading's provenance is the body of a service comment there, not a line of its own.
Three outcomes. Verified, Out-of-scope drift — a field changed that the review never covered, marked in place in the table — and Findings not met. The outcome pill is the only place the card carries state colour. Disclosed and out of scope are separate marks: a field may be disclosed to the analysis and still lie outside what the review covered, and the table says so on the row while the provenance says so in the list.
The verification card has no drawing on any Application Design page. It is drawn here in the shared token vocabulary — the mustard plate and pill treatments, the mono meta lines, the etched table — and this page is where it is now fixed. The bordered panel is the card treatment for a conversation, where the reading has to separate itself from the turns around it; on the run's own review page the same regions sit unframed in the page column, and that surface is unchanged.
Marks, not a decision. A card may carry per-item suggestions. Each one shows what it would change — the current content beside the suggested content — because a label alone cannot tell a reader what accepting it does. The label rides a suggestion chip, the mustard pill drawn on Artifacts § type picker; beside it, in mono, the change class the producer emits.
Two states, and no third. A suggestion arrives accepted. One press makes it dismissed; one press accepts it again. There is no unmarked state to return to and nothing to clear. Dismissed is carried by the muted ground and the dashed edge alone — never a strike-through, which would pile a second marker on a pill that is already marked. The suggestions carry no submit of their own: they ride the review card's one terminal decision — Continue takes the accepted ones with it, and a Regenerate carries them into the work that is made again.
Re-connecting on Q3 priorities
A quick question about your Q3 pilot
Are you open to a short call next week?
Book 15 minutes here — no prep needed.
Press a suggestion to dismiss it, press it again to accept it. Nothing is recorded until you press Continue or Regenerate below.
The slot beside the label carries the change class the producer actually emits — replace, add or remove. It does not carry a confidence score: this producer is deterministic and computes none, so no drawing on this page may promise one. Where a producer one day does emit a score, it is drawn as an addition to this slot, not as a replacement for the class.
Artifacts draws the pill at rest and fixes accept / dismiss as its semantics. Two things are new here and are built from that same pill: the before / after panel beneath it, on the shared surface and line tokens, and the dismissed reading — the resting pill's dashed edge over a muted ground, with the fill removed. The accepted reading is the pill with its fill, because accepted is where a suggestion starts.
Four hosts, one card set. The chat thread drawn throughout this page, the embedded site widget, the run card, and the page gate region. Every card appears on every host, and it is the same card wherever it appears: the same regions, the same states, the same data on screen, and the same actions its reader is authorized to take. Only the frame changes — the thread, the widget's panel, the run card's detail column, the gate region of the review page.
| Card | Chat thread | Site widget | Run card | Page gate region |
|---|---|---|---|---|
| Review | Yes | Yes | Yes | Yes |
| Verification | Yes | Yes | Yes | Yes |
| Recommendation | Yes | Yes | Yes | Yes |
| Schedule proposal | Yes | Yes | Yes | Yes |
New · the presence matrix
What holds a card back is the reader, not the host. The states of §IV are read the same way on all four hosts. A reader who may act gets the card whole, with the actions its kind carries live — the review card's decision floor (§II), the skills row's checkboxes and its Continue (§V), the schedule card's Confirm (§VI). A reader who may view but not act gets the restricted card: drawn in full, those affordances disabled, the reason on screen. A reader who may not read the target gets absent — no card DOM at all. No host puts a step in front of those actions, and no host trades one of these readings for another.
| What the reader may do | Chat thread | Site widget | Run card | Page gate region |
|---|---|---|---|---|
| May view and act | Card · actions live | Card · actions live | Card · actions live | Card · actions live |
| May view, not act | Card · actions disabled | Card · actions disabled | Card · actions disabled | Card · actions disabled |
| May not read the target | No card at all | No card at all | No card at all | No card at all |
New · the reader matrix
Every row reads the same across the four hosts: that constancy is the rule. A card that asks nothing — the verification card of §VII — has nothing to disable: it is drawn whole, or it is absent. The reason on a disabled affordance is the reader's, never the host's.
These matrices fix whether a card appears, not how it is laid out. A card that appears keeps the drawing its section fixes — the same target panel, the same floor, the same option rows — whichever host it is on. A host supplies the frame and the measure a card is laid out at; it never drops a region, a state or an affordance the card's own section draws, and never adds one.
What is typed goes to Cinatra, which works the card's own controls. The row above the floor (§I) states which card the next message acts on. What that message can do is exactly what the card already draws — decide where a decision is open, comment where a comment field exists, fill and submit where fields wait. A card that draws no decision lends none, and no card gains an action its controls do not have. One road is the typed road’s alone: on a review card, asking for changes is typed and never pressed, because the floor draws no control for it (§II) — it is read by the run and settles the card changes-requested.
One press per message, in the reader's own words. A message presses the bound card's controls once. Filling the fields in front of the reader is not a press, so one message may fill and then press; a second press asked for in the same message is refused in the answer, and the reader sends again. A typed comment lands word for word; a typed decision records those words as its reason. There is no confirmation step — an explicit decision lands exactly as pressing the button does, and a message that is not plainly a decision decides nothing.
While the act is in flight, the card is its loading reading. Nothing new is drawn for the wait: the card takes the loading state of §IV until the act comes back, then settles in place in its own settled reading. The answer in the turn reports what came back and adds nothing; where a line and a card could disagree, the card is right.
Filling is not submitting. Where the bound card is fields over a button, the values appear in the fields on screen and nothing is sent; the reader presses the screen's own button, and may correct any field by hand first. Asked in the same message to send it, Cinatra presses that same control — never a second path.
The row is unchanged while the act is in flight: it still names the card, and it still gives the box back with one press. What changes is the card beneath it, which reads as loading until the server answers — and then settles in its own settled reading, drawn where that card is drawn.
A card acted on from the box records the same reader, the same permissions and the same one decision as the card's own control, and it settles once. The box is a second way to reach the card's affordances, never a replacement for them — and an act sent from it reads exactly as an act pressed on the card, loading while it is in flight and settled when it comes back. A change request is the one thing it does that no control on the card stands for: it is read by the run, and it settles the card changes-requested (§II).
A refusal is the platform's own sentence, said back. Where nothing is bound, or where the reader may read a card but not decide it, the platform states the refusal and the answer in the turn carries that sentence. It is never softened, never re-worded, and never replaced by an act.
The same words, wherever they appear. The answer carries the sentence the row above the floor carries (§I), or the clause the card shows under a disabled affordance (§IV), unchanged. A reader who reads the row, the card and the answer reads one wording, not three readings of one situation.
The message is sent, and the turn answers. A message that cannot act on a card is still a message: it is sent, it is read, and it is answered. A turn never ends in silence, and nothing is quietly dropped on the way. With nothing bound, no control is lent at all — so a comment cannot land on a card the reader did not pick, and nothing settles by accident.
Word for word the row's own sentence (§I). Nothing settled, and nothing was invented to fill the gap: the reader is told what is true and what to do next.
The card is unchanged by the refusal: it stays drawn whole with its terminal affordances disabled and their reason on screen (§IV). The card and the answer carry the same clause, word for word — one is not a softer reading of the other.
A refused act settles nothing: no card moves, no gate resolves, no schedule is armed. And a refusal is said — the turn carries the sentence in plain words. A message that vanishes without an answer, or a card that quietly settles in a way the reader was not told about, is neither of these and is never drawn.
A conversation whose model cannot use tools cannot work a card at all. Where the model behind the conversation has no tools to call, nothing can be lent to it: in that conversation a reader genuinely cannot comment, decide or fill a form by typing. That is a real limit of the conversation, not a detail of the display, and it is drawn as one.
The limit is stated where the binding would have been. The row above the floor (§I) carries the limit instead of the binding, with its toggle disabled — there is no binding to take or give back — so a reader learns it before typing. The moment a message asks for an act, the answer in the turn says the same thing.
The card keeps every affordance live. The limit is the conversation's model, not the reader's rights, so nothing on the card is disabled: Comment, Regenerate, Continue and Confirm all press exactly as they always do. What is closed is the typed road, and only that.
The row keeps its panel, its toggle and its trailing line (§I). Only two things differ: the toggle is disabled, because there is no binding to take, and the line reads the limit in mustard-ink — the same weight the row uses when a typed message cannot act.
The answer names the limit, names the control that still works, and asks the reader to press it. It never promises to try, and it never answers as though it had acted.
Restricted (§IV) is about the reader: the rights are missing, so the terminal affordances are disabled with the reason under them. Cannot act is about the conversation's model: the reader's rights are intact, so nothing on the card is disabled and only the typed road is closed. Drawing a live card as a disabled one — or a disabled one as a live card — tells the reader the opposite of the truth about what they may do.
The same display, in a conversation. Every display the fleet adds (Agent run & review §XI) is drawn on the review card exactly as it is drawn on the artifact’s own page — the same header, the same chrome, the same readings. A renderer does not shed part of itself because of where it is read (§II.1). What the card adds around it is the floor, and nothing else.
The states are the card’s, not the display’s — so they are drawn once. Only the rendering differs from artifact to artifact; everything the card puts around it — the turn it sits in, the floor while the review is open, the settled marker below the whole card once it is decided — is the same whatever is inside. The states below are every display’s states: §XIII.1 draws them once over one artifact, in the conversation and outside it, and they read the same way over every other display in this section — swap the panel, and nothing else moves. Continued is the only settled reading; there is no second status after it. One review per artifact holds here as everywhere: a run that makes several things raises one card each, in order, and waits at each (§II.1). Each section after §XIII.1 therefore draws its rendering alone, in the content forms that rendering has, and no review state of its own.
Where the review states are already fixed. This section does not restate them. The card’s own states are drawn on this page at §II. The review card in the thread and §IV. Review states; outside a conversation they are drawn on Agent run & review at §III. The in-run review gate and §VII. Permission, loading & blocked states. Those drawings are the fixed ones; §XIII.1 below shows only how a fleet display sits inside them.
How to read the drawings below. Inside the frame is what the product draws — the real tab labels, the real field labels, the real content, the real controls, and nothing else. Every explanation of a drawing sits outside the frame in this page’s annotation voice: the mono line above a frame, set against the annotation rule. No line inside a drawn frame is a note about the drawing.
One artifact carries the states for all of them. The email body stands in for every display in this section. Below it is drawn pending and settled, first in a conversation and then outside one, in the in-run review gate. Nothing in either drawing is particular to email except the panel in the middle: put any other review target’s display, §XIII.2 to §XIII.7, in its place and the turn, the floor, the marker and the words around them are unchanged. That is the whole of what the other sections would otherwise repeat.
The draft is read as mail. The email extension’s display draws the mail reading pane on the card as it draws it anywhere: the initials avatar, the sender, the address on the line right beneath the name, the date at the end of that line, the subject under them, and the body under a rule — in one view, with no tab strip. On the artifact’s own page the subject and the body take an edit in place (Agent run & review §XI.1); here the target is pinned, so there is nothing on the pane to type into and it offers no composition. No picture is drawn on this card: the avatar is initials in a plain disc, and a text display composes nothing into itself. No recipient is drawn: who it goes to is a record of its own and is never shown here. The pane draws no reply field at all — answering a message is not part of this display; the only controls around it are the floor’s.
The same two states, outside a conversation. On the run page the review is a gate inside the run (Agent run & review §III. The in-run review gate), not a turn in a thread. The frame changes and nothing else does: the same display, the same floor while the review is open, the same Continued marker below the whole gate once it is decided. The gate’s own loading, restricted and no-longer-open readings are fixed at Agent run & review §VII. Permission, loading & blocked states, and at §IV. Review states on this page; they are not redrawn here.
The form the artifact has is the form the card draws. A kind written as text is drawn through the markdown display on its Code and Preview tabs; a kind a person handed over as a pdf is drawn in the embedded PDF viewer the pdf extension mounts, with that extension’s own download floor behind it — what each of those two readings is, and when a reader meets it, is stated where the display is fixed (Agent run & review §XI.2). Which form it is is never a choice on screen. The three readings below are those three renderings and nothing else — the states around them are §XIII.1’s.
The picture is the work. The screenshot display draws the captured picture to the aspect it was taken at and the facts of the capture beneath it — the address, the viewport, and when it was taken — here exactly as on the artifact’s own page. The states around it are §XIII.1’s, unchanged: a picture is taken rather than prompted, and nothing in that changes what the card draws around it.
Reading is reading. A deck arrives as an exported pdf, and the deck display draws it in the same embedded PDF viewer as any other pdf reading (Agent run & review §XI.4), with that extension’s own download floor behind it. The deck writes no viewer of its own: no page counter, no Previous, no Next. The two readings below are those two renderings; the states around them are §XIII.1’s.
A dashboard is drawn on the card, not floored. The card draws the pinned configuration through the read-only composition, with the numbers read live and the line that says both things at once: the configuration is frozen at the revision, the numbers are current, and the reading carries the time they were read. The rendering below is the one a reader meets while the review is open, so it offers no live dashboard to open: that link belongs to the continued reading alone, and the continued reading is §XIII.1’s state, drawn over the artifact’s own page at Agent run & review §XI.5.
A portlet is drawn as itself. Where the work is one number rather than a whole dashboard, the portlet is the target and the card draws that one entry, naming the dashboard and the dashboard revision it was cut from. As with the dashboard, the rendering below is the reading while the review is open and carries no live dashboard link; that link belongs to the continued reading (Agent run & review §XI.6).
The view is the display’s, not the card’s. A staged change to a page on a site outside Cinatra is drawn as the page snapshot, and the extension’s display draws on the card exactly what it draws on the artifact’s own page: one view and no tab strip — the page embedded live in a frame, a diff of only the changed excerpts beneath it in the page’s own formatting, and Open in the CMS under those. The pill reads the kind — CMS page — and the platform the page lives on is carried in the identity line, which also names the one renderer both CMS extensions draw through, @cinatra-ai/website-artifacts:page-diff, so a WordPress page and a Drupal page are told apart there and nowhere else. The reading below is that rendering; the states around it are §XIII.1’s.
A pointer is drawn as a page, and never reaches a review. In a conversation the pointer display draws the node it points at through the same page drawing as a WordPress page — the same one view, the same embedded page, the same changed excerpts beneath it, the same CMS page pill, and the same renderer, @cinatra-ai/website-artifacts:page-diff, named in the identity line with Drupal beside it. It is not pinnable and it is never a review target: no gate opens on it and no floor is ever drawn beneath it, so none of §XIII.1’s states is the pointer’s own. Where the page it points at was itself reviewed and continued, the settled marker below the card belongs to that review (Agent run & review §XI.7), never to the pointer. The reading below is that rendering.