THE INTERACTION SPEC — Cedar's application surface

Scope: the Cedar candidate. Shared kit components remain reusable; another candidate defines its own interaction model and adopts this contract explicitly.

Status: canonical interaction contract within Cedar's proposal beneath THE-ARCHITECTURE.md and THE-SYSTEM-SPEC.md. It specifies how a person moves through, reads, edits, and recovers across Rocoto’s shared surface. It does not claim that the current browser kit has a production backend, live connector, or durable workflow.

INTX-00 · Authority and boundary

This document owns cross-sheet interaction, navigation, layers, focus, layout posture and the propagation of visible state. It does not rename or weaken a domain fact:

1. Architecture decides object ownership, source of truth and supersessions.
2. System Spec decides business state, commands, permissions, error semantics and the Product, Customer and Albarán control registries.
3. This document decides where those controls appear, what stays visible, whether a use is a route, menu, popover, dialog or sheet, and how context/focus/drafts survive a transition.
4. Product, catalogue and intelligence specifications decide their detailed controls within this surface contract. The wiring tasklist proves implementation.

Rocoto continues to use the current theme’s type, spacing, elevation, radii, colours and motion. This is not a second design system. The measured geometry below freezes the shared app behaviour that makes the domain controls usable across widths.

INTX-01 · Shared surface graph

The application has one ordered visible surface stack. A later layer never creates a second copy of the object under it.

flowchart TD
  G[Global application shell] --> W[Workspace index or master pane]
  W --> S[One object sheet or focused workspace surface]
  S --> R[Object door / child route]
  S --> O[One transient overlay]
  R --> N[Native source, related object, output or evidence context]
  O --> C[In-place confirmation or picker step]
  N --> S
  C --> S

1. Global application shell is always rendered for the active tenant, except when an explicit full-screen, accessibility-safe take-over is required. It contains the workspace navigation, active tenant/member context, authorized utilities and the job/connection/realtime state.
2. Workspace surface is the list, dashboard, catalogue, source inbox or administration area selected by Sales, Stock, Customers or Administration. It owns its filters and selection; it never owns a second editable customer/SKU/albarán copy.
3. Object sheet is the main surface for one Product, Customer or Albarán. Its object heading, route context, lifecycle state and permitted primary action are visible without hover. Its section anatomy and copy live in PRD-*, CUS-* and ALB-*.
4. Object door is a navigable relation: a customer, SKU, albarán, source, lot/equivalence, output job or evidence item. It carries stable object ID, tenant scope, origin and permitted relation context. It is a link or button with an accessible name, not an unlabelled card.
5. Transient overlay is used only for focused edit, selection, confirmation, short reference detail or a bounded job state. It has one owner, one return target and one scrollport. A child route is preferred when the person needs to read native source/history at length.

What is always visible, conditional, or revealed on intent

Fine-pointer hover adds orientation, never capability. Touch and keyboard receive the same named control, state and outcome without having to hover. A tooltip describes an already available control; it cannot contain a unique action, blocker, customer/source fact or required instruction.

INTX-02 · Navigation, object doors, and return context

Route and history contract

1. A workspace, object sheet, source/evidence context, search result and output job has a stable tenant-authorized route. Browser Back/Forward follows the user’s actual route stack, including the object selected and its opening context.
2. A user-initiated object door adds a history entry. Changing a local disclosure, hovering, receiving a realtime projection update or refreshing a read model does not.
3. A context carries only what the next view needs: origin object/workspace, permitted relation ID, list query/filter/page/selection and scroll restore point. It does not put protected source text, money, contact data, credentials or arbitrary tenant IDs in the address.
4. Direct entry or reload resolves the stable object route first. If the original context is gone or unauthorized, the sheet provides its safe default return: Back to sales, Back to catalogue or Back to customers.
5. A source route is subordinate. Open original conversation and Open related email enter a native-source context whose return control names the actual Product or Albarán. Supplier email never changes the primary Stock navigation seat.

Posture-specific movement

Focus, scroll, and draft return

1. Opening a new object sheet moves programmatic focus to its heading and resets only that sheet’s scroll to its heading. Returning moves focus to the exact origin door and restores its stored scroll position after the projection is ready.
2. Opening an editor focuses its heading or first invalid field; opening a picker focuses its search field. Closing a menu/popover returns focus to its trigger. Closing a dialog returns to the trigger unless a successful save replaces it with an inline updated field, in which case focus lands on the changed field’s summary.
3. Every editor owns one local draft tied to object ID, field set, base revision and tenant. A sheet route does not silently commit or discard it. Leaving a changed editor asks Discard your changes? with Keep editing / Discard changes; returning restores the same draft when its tenant/object/revision policy permits.
4. Tenant switching, sign-out, hard deletion/redaction and a revoked permission remove unsafe drafts/cache. Offline eligible drafts remain separately marked Not saved yet and are never shown as projection truth.
5. Realtime changes update non-edited read facts after their permitted cursor arrives. A change to a field under edit produces the System Spec’s named conflict surface, retains the draft and makes no automatic high-risk merge.
6. Request history return. Product Requested personalisations stores an opaque return token containing the permitted Products query/filter, selected record/sheet, scroll anchor and initiating door. Opening the row pushes the exact Albarán/line. Its Back control and browser Back restore that token after the Product projection is ready; an expired token falls back to the exact Product Sheet. It never returns to a generic catalogue root or exposes source text in the URL.

INTX-03 · Controls, pointer parity, keyboard, and visible state

Geometry of interactive targets

• Every directly tappable control has a minimum 44 × 44 px hit area. The desktop rail’s and phone-navigation row height is 44 px and 64 px respectively; an icon may be smaller only inside that target with an accessible text name.
• Rows with a primary door keep the whole stated row target and do not place a hidden action over editable text, a source link, a product door or another nested control. A nested control stops only its own event and identifies its outcome.
• A compact control may have a visually small label but cannot shrink its target below 44 px, even in a dense list. Numeric entry uses the domain’s explicit field geometry; it is not converted to an icon stepper by a narrow screen.
• Keyboard focus uses a visible 2 px theme-coloured outline with sufficient contrast. It appears on :focus-visible, not as a mouse-only hover effect. The focus outline may sit inside a bounded row only if it remains unambiguous.

Control state matrix

INTX-04 · Overlay, menu, picker, and dialog contract

The surface uses the smallest layer that can complete the current decision. Opening a layer always moves focus and creates a clear return path; no layer may make the underlying sheet’s scroll or draft state ambiguous.

1. Inline disclosure is for readable evidence already attached to its section: details/history, insight evidence, price/stock history and short source metadata. It changes neither route nor focus unless deliberately opened by keyboard, then exposes a labelled expanded state.
2. Menu is for a bounded set of valid sibling actions, such as More customer actions or More albarán actions. It is anchored to a visible text-labelled trigger; Arrow keys move items, Escape closes it, and menu state is not persisted in browser history. If a touch/phone surface has insufficient safe room, the same menu opens as a named action sheet with identical order and labels.
3. Popover is for a short, non-destructive lookup/preview tied to its trigger: unit conversion summary, row provenance or short status detail. It must fit without horizontal clipping, close on Escape/outside activation, and expose no edit that needs a second dialog. A long native source, audit log or related object is a route/sheet instead.
4. Picker is a focused selection state inside its owning editor: product search, tariff, contact owner, customer, lot or unit. It has a heading, search/filter field where needed, labelled empty/loading/error state, listbox semantics and Cancel. Selecting one result returns to the original editor with the selection uncommitted until that editor’s specific Save.
5. Dialog is for an editor, high-impact confirmation or compact review. It has one title, purpose/consequence, one internal vertical scrollport, labelled close/Cancel action, focus trap, Escape behaviour and a final named command. It never opens a second modal above itself.
6. Full-screen sheet is for a phone or stacked-desk flow that needs sustained reading/editing: native conversation, full output status, product/customer/albarán detail or a multi-step review. It has a top named Back/Cancel and one body scrollport. A phone full-screen sheet does not leave a hidden active dialog behind it.
7. Confirmation step from an editor replaces the editor’s body in the same dialog/sheet. It retains the draft behind the review and gives Back / Keep editing rather than nesting a new dialog. An object door inside an overlay either opens its own full route after an explicit Open … action or is a read-only summary; it cannot silently abandon unsaved work.

Overlay state and closing rules

• At most one modal/dialog/full-screen sheet is active. Menus and popovers close before it opens.
• A modal owns only its own scroll. The sheet behind it is visually inert and does not scroll under touch or keyboard; no global overflow side effect creates a competing scroll container.
• An outside click/tap closes only a non-destructive menu/popover. A changed editor, issue review, archive/merge/void confirmation or external-send review requires its named Cancel/Back path.
• A picker’s New product route preserves the original form’s unsaved context and enters PRD-C01. Save proposal may return without an SKU; only the separate reviewed SKU-confirmation command returns a reviewed SKU. It does not write an arbitrary product into the calling line.
• A permission or revision change while an overlay is open leaves its text/draft readable where safe, replaces its final command with the exact unavailable/conflict state, and never submits an old intention.

INTX-05 · Cross-sheet and external-state propagation

A projection refresh must show a change where a person expects it, but it must not blur different truths or rewrite an issued snapshot. The table is a visibility contract; the authoritative command/event rules remain in the System Spec.

Conflict and presence across surfaces

1. Presence names only a permitted viewer/editor and broad action area; it is advisory and cannot lock a sheet or claim ownership of a field.
2. A source or AI evaluation may mark one exact albarán field/line as checking. It must not dim, block or resolve unrelated fields. A Customer or Product Sheet sees the same source/proposal as related evidence, not as an independent fact.
3. An issued albarán always reads its own immutable snapshot even while the current Product or Customer Sheet changes under it. A direct link labels the relationship and opens the current object in a new context.
4. Invalidation banners name the affected object/action: This price changed while you were editing, This customer is now paused, or This source is no longer available. Never use an unexplained global refresh.

INTX-06 · Responsive geometry and reading measure

The application follows a four-posture continuum. It reflows live as browser width changes and never uses a stretched phone layout on a tablet or horizontal page overflow as a fallback.

Measured shared geometry

• Product, Customer and Albarán readable inner content is capped at 720 px including its own horizontal padding, centred in a wider pane. On a wide or stacked table-sized pane this yields a maximum 680 px text/control column after the 20 px desktop padding on each side. It stops tablet rows becoming an unscannable 960 px line.
• Sheet content uses 20 px horizontal padding on desk/stacked desk and 16 px on phone. At 390 px that makes a 358 px sheet surface with a 326 px inner column; at 320 px it makes a 288 px sheet surface with a 256 px inner column. Do not add a second nested side gutter.
• Current object heading measure is 28 px type with 36 px line height. Body text remains 16 px. Long names wrap; they do not reduce below the body scale, overlap a control or force a horizontal scroll.
• Section separation uses the current theme scale. Measured product Stock begins after 24 px and its rows use 12 px gaps; the contained insight card has 16 px padding and a 12 px radius. Customer and Albarán sections use these existing surface patterns rather than bespoke card systems.
• Task dialogs use the 800 × 600 px landscape frame in INTX-11. The viewport clamps it; header and final actions remain outside the body scroll. The price field retains its large numeric entry style inside this frame, with product/tariff context beside it on a desktop and above it on a phone. This supersedes the old 480 px price dialog.
• The target phone frame has 8 px viewport insets, giving 374 px at 390 px and 304 px at 320 px. A 16 px body gutter leaves 342 px and 272 px respectively. There is no second nested modal gutter. Keyboard/short-height states scroll the body while retaining reachable actions; measured release evidence must verify this, not infer it from the CSS.
• The desktop header in the measured view uses 16 px vertical and 20 px horizontal padding; phone header uses the 16 px page gutter and a 12 px lower separation. Shell/pane measures are not duplicated inside a sheet.
• The measured 1600, 1024, 768, 390 and 320 px views have no horizontal overflow. This remains a release requirement for all shared states, including long names, inline errors, red concerns, price editors, source attachments, tables and menus.

INTX-07 · Accessibility, motion, and reading safety

1. All route changes, overlay opens/closes, validation summaries, save/unknown-outcome/conflict changes and source/AI evaluation updates announce through appropriate semantic live status. Announcements name the object/action and never repeat private source content.
2. Menus use menu semantics only for action menus; selection uses listbox/combobox semantics; field groups have legend/labels; date/quantity/money controls state unit/currency/precision to assistive technology. A red concern has its target relation in text and programmatic metadata.
3. Escape closes a menu/popover, returns focus, and never commits. Escape in a changed editor asks the same discard question as its Cancel path. Enter only invokes the safe focused control; it cannot issue, void, archive, merge, dispatch, deliver or send external communication without the explicit final confirmation.
4. Hover affordance is ignored under coarse pointers. Motion respects reduced-motion preference: no essential state is communicated only by animation, transitions are removed or reduced, and a resize goes directly to the correct posture without a transient wrong layout.
5. Loading skeletons have the right section label and do not become an endless motion barrier. Rows/cards with data visualisation provide readable text/table equivalents. Contrast, focus and target checks apply to all normal, disabled, concern and external-job states.

INTX-08 · Required interaction evidence

A feature cannot pass visual review merely because a static sheet looks correct. The release record must include reproducible evidence that:

1. every PRD-*, CUS-* and ALB-* leaf has a visible/resting, keyboard-focus, touch, loading, empty, save/failure, conflict, permission, offline, archive/deleted/redacted state where it is applicable;
2. all object doors preserve tenant authorization, stable return context, focus and scroll across Product ↔ Customer ↔ Albarán ↔ native source ↔ evidence/output flows;
3. menu/popover/picker/dialog/sheet nesting follows INTX-04, keeps one scroll owner, traps and returns focus correctly, and preserves/discards drafts only by the stated path;
4. a command/event/receipt causes the exact refreshes in INTX-05, with no issued snapshot, physical-stock/estimate, source/normalized fact, or queue/receipt confusion;
5. desk, compressed desk, stacked desk and phone pass at 1600, 1024, 768, 390 and 320 px with no horizontal overflow, 44 px target minimum, readable content cap, safe-area bottom spacing and no hover-only action;
6. screen-reader, keyboard-only, reduced-motion, high zoom, slow-network and reconnect runs cover the same surface graph; and
7. the wiring task graph records these results against INTX-01 and the owning domain control IDs. A design-kit pass is visual evidence only until the production command/projection/receipt contract also passes.

INTX-09 · Workspace anatomy beyond the three object sheets

This section gives literal surface anatomy for the shared workspaces that surround Product, Customer and Albarán Sheets. It supplies the interaction contract where a domain canon has deeper rules: THE-CATALOGUE-CONTRACT-SPEC.md for catalogue/source, THE-STOCK-LOTS-SPEC.md for LOT-01, THE-EXPORT-CANON.md for export interaction, and THE-SYSTEM-SPEC.md for production authority. It is a target specification, not a claim the current kit or any provider implements all of these paths.

Global shell, navigation and work controls

Tenant application
  → top/side shell
    → active tenant
      → Switch tenant menu
    → primary workspaces
      → Sales | Stock | Customers | Administration
    → global work controls
      → Search | Notifications | Help and support | profile menu
    → utilities
      → Stock update | New product | Upload | Export

The shell uses the existing 208 px expanded or 64 px compact rail on desk, the 64 px navigation posture on phone, 44 px minimum direct targets, and the 20 px desk / 16 px phone content gutters from INTX-06. At 560–1095 px, a workspace door pushes the detail pane and Back to [workspace] restores filters/scroll; it must not force a phone bottom-navigation layout.

Products, New product and source-evidence anatomy

Products
  → toolbar
    → Search products
    → Filters
    → New product
      → Add one product
      → Add a product list
        → Drop/choose a file | Paste a product list | Take photo (phone)
        → Catalogue intake review queue
  → coded SKU or uncoded sale-item row
    → Product Sheet
      → Internal category feedback
      → Related products inline picker → exact existing SKU
  → separately gated Stock update
    → incoming supplier/source feed
    → native source detail → return to exact SKU

Catalogue arrow keys and Home/End skip structural Internal-category headings. In a desktop split view they select an exact row and update its adjacent preview. In a narrow single-pane view they move focus without opening or hiding the list; Enter or Space opens the focused row through its native button. Internal-category headings own no artwork, stock, price, selection state or Product Sheet door.

Stock work surface and LOT-01 door

Stock → Product Sheet → Stock
  → Recorded balance
  → Receive stock | Record a stock count
  → Lots
    → Assign stock to lots
    → lot rows / Unassigned stock
    → Stock history
  → Daily stock estimate

Assign stock to lots is an explicit physical-attribution action with a fixed Recorded balance. It must never be labelled Allocate stock or open an Albarán chooser. Its typed lot-number selection, quantity slider plus exact input, total/unassigned summary, new-lot flow, source/reason, concurrency, history and mobile accessibility are defined by LOT-L01–LOT-L07 in THE-STOCK-LOTS-SPEC.md. Albarán-line Allocate stock is the distinct fulfilment commitment flow at LOT-A01–LOT-A08.

Messages and native-request anatomy

Sales → Messages
  → conversation list
    → Search messages | channel/status filters
  → read-only conversation
    → channel header / participant
    → source timeline
    → reasoned ReplyAttention tray when required
    → one-destination unvalued Albarán card
    → native Open chat / Open Gmail / Open Outlook handoff

⚠ That future profile arrived: FEED-IA §196.7 / §196.8 (E193.08–09) add the composer, and MSG-26 / MSG-27 below are its contract. The projection above still describes the SOURCE — read-only, provider-custodied — and the composer stands beside it rather than inside it. What §196.7 lifts is only the clause forbidding a writing surface; every non-claim MSG-25 makes about delivery, receipts and provider custody stands unchanged.

For an Albarán, native source stays a readable, channel-correct section rather than a parallel business object. WhatsApp-style controls appear only where actual channel capability permits them; email shows thread/subject/attachments. A simulated composer or tick must never stand for a provider connection or delivery receipt.

Export, print, packing, files and integrations anatomy

Superseded by THE-OUTPUTS-SPEC.md OUT-02 and OUT-04 (E200 · FEED-IA §202). One library of templates, and one print screen holding Preview and Edit on the same paper. The history below is kept.

The current detailed interaction authority is THE-EXPORT-CANON.md, subject to Architecture/System Spec supersessions for authoritative money, document snapshot and receipt rules. The centred Export center is one bounded output workspace, never a screen-sized list or a collection of unrelated panes. It has three explicit destinations: Print, Email and Files. They start with the same applied date/salesperson/order scope and each names a distinct outcome. Albarán/Packing print cards sit side by side on desktop and stack on phone; their document kind, selected template and output status remain separate. Connection setup and provider qualification still live in Administration Connections; a job/provider path is target behaviour until its own receipt/recovery evidence exists.

Sales or Albarán → Export center
  → Print
    → Saved copies | Templates → Use template → configure copy | Albaranes | Packing lists
    → Print remaining | Print all | Preview
  → Email
    → Saved copies | document copy / scheduled delivery | recipient, channel and schedule review
  → Files
    → Saved copies | Recent files | Templates → Use template → configure copy | current-data file setup
Administration → Connections / roadmap
  → operation-specific destination cascade

Connections and roadmap, outside active destinations

The Email destination is a customer-document action, not an integration-setup substitute. Print, Email and Files do not gain generic ERP tabs. The path for a future or connected operation lives in Administration Connections and the read-only What Rocoto can connect today roadmap. It is shown per operation, never as a generic export mode.

Administration settings anatomy

Administration
  → Organization
  → Operations
  → Commercial
  → People and security
  → Connections
  → Notifications
  → Billing
  → Data and privacy
  → Test, support and audit

Every settings route has heading, one-sentence purpose, current saved value, Edit or named primary action, local draft, Cancel, Save [section], save/failure/permission/conflict state and immutable history/audit door where setting affects documents or operations. A generic Manage label is not acceptable.

Cross-workspace state and disclosure rules

Workspace cards and rows use the existing surface rhythm: 16 px body text, 12 px internal gap for compact product patterns, 16 px card padding/12 px radius where the current contained card pattern applies, 20 px desktop and 16 px phone page gutters, 44 px direct targets and the 720 px inclusive reading cap. Dense export/template/settings tables may scroll horizontally only inside a labelled data-table region with a usable compact card alternative on phone; the page itself must not overflow.

INTX-10 · Line discussion and compact output panel

Albarán arithmetic occupies at most 420 px on desktop: quantity/unit, rate and total in readable aligned groups. Phone uses available width and preserves separate quantity/unit targets and validation. Customer note is attached below product; internal discussion/review machinery consumes no row space until opened. Full stock, product-stat and outbound views remain inactive outside the Meta-window capability gate; their unavailable state must name the gate and preserve the current order context, never show a stale count, callable send control or implied live transport.

INTX-11 · Connected task anatomy

This section is normative UI detail, not runtime evidence. The implementation task graph maps every ID below to a leaf with its own failure and release proof. Labels are operator-facing; architectural explanations stay here or behind an intentional evidence door.

Shared task frame → header → content → actions

Insights → chart card → exact evidence

Assistant → conversation → scoped proposal → outcome

Files → gallery → custom template → columns → file

Print → immutable attempt → physical confirmation → reprint

Browser capability references: Window.print opens the browser dialog and returns no result proving physical completion; afterprint also runs when print preview is closed. These facts govern the receipt model, independently of visual design.

MSG-24-HISTORICAL · Outbound-template reference states — superseded by MSG-25

Messages is a transient workspace. Its visible navigation marks are icon-only 48px targets: one New message, one Hide sidebar beside the sidebar, and one Expand workspace/Collapse workspace at the workspace edge. New message opens a compact two-path choice: Message a customer searches the real WhatsApp conversation book and opens the chosen composer; New test chat opens the isolated test selector. At expanded desktop width the workspace occupies the viewport inset and blurs inactive work behind it; on a phone it covers the active screen, including bottom navigation. Minimise/restore retains thread, draft, scroll position, sidebar posture and reply target. Opening an albarán parks that snapshot; only a browser return to its source route restores it. A later unrelated route clears it.

Outbound entry and chooser. New message is one icon-only 48×48 px control with an accessible name and tooltip. It opens a compact 420 px choice card titled New message, with an icon-only Close control and exactly two bounded, keyboard-focusable choices: Message a customer (Choose an existing WhatsApp conversation.) and New test chat (Try a message without contacting a customer.). The first opens a 560 px Message a customer selector: an autofocus Find a customer search field, a 48×48 px icon-only Back control, and a contained result list of real, non-test WhatsApp conversations only. Each row names the customer and channel; Reply window closed is a quiet state cue where current evidence says so. It is not a provider claim or an alternative send path. An empty query result says No customer matches “[query]”. No selector creates a contact, conversation, draft, provider connection or secondary store.

The choice’s Close/Escape returns focus to New message after its focus lock is released. Selector Back returns to the choice without losing its context; selector Close/Escape returns to New message. Choosing a customer closes the chooser, opens that exact existing thread, then focuses the ordinary composer. Choosing New test chat opens the existing isolated test selector and never creates a real outbound conversation. These transitions work at desktop and phone width; a phone chooser remains inside the same active Messages surface and never exposes the footer navigation beneath it. Choice and result rows use inherited text styling, visible hover/focus treatment, contained scrolling and no page-level horizontal overflow.

Conversation ground is a pale brand dotted field. Incoming bubbles are neutral grey; customer-facing outgoing bubbles use brand red with accessible light text. A source email and a condensed order are individually bounded cards. Ordinary internal tool outcomes are compact trails without notification dots. A response-required item is a dismissible drawer tab protruding from the composer; its dismissal requires the existing free-text rationale and retains ordinary concern evidence. Read order is the active verb.

Email has individual thread cards. Its only primary actions are Reply when the connected provider permits it and Open Gmail/Open Outlook using the provider mark and an external deep link. A separate labelled history icon opens the customer communication sheet; no card background opens history. Forwarded/imported mail is visibly read-only. Provider reply receipt/failure owns truthful state; a reference UI must not claim a local send is provider execution.

The WhatsApp 24-hour state is a provider-evidence gate, never an AI decision. The user starts in the ordinary conversation: search/select a customer or open an existing thread, write the intended message, then press Send. The send boundary checks fresh provider evidence. An open window sends through the normal permitted-channel command; a closed window opens the shared task dialog; missing, stale or unavailable evidence blocks free-form sending and offers Retry. The composer text, reply target and attachment selection stay unchanged while that check or dialog is active.

Closed-window dialog. Use the shared 800×600 desktop task frame (maximum 8px viewport inset, full-screen on phone), one scrollport, a quiet WhatsApp step label, the title Reply window closed, and the sentence WhatsApp requires an approved template because the last customer message was more than 24 hours ago. Close/Escape returns focus to the composer and preserves the intended message. The dialog never repeats internal IDs, model reasoning or provider jargon in visible copy.

Matching and message ownership. Semantic matching may rank approved templates but cannot approve one, alter its immutable body or infer the 24-hour window. Exact locale, enabled state, variable schema and provider evidence must pass before a candidate appears. The match view deliberately shows the rendered outcome rather than technical variable machinery; the create view exposes only fields the operator can change. Each transition produces a quiet conversation activity item—window intercepted, template submitted/pending/approved/rejected, template dispatch accepted/failed—with actor and time. It never appears as a customer message until the channel provider accepts that outbound request.

The reference kit deterministically demonstrates closed-window approved-fit, no-fit/approved-hello, create, submitting and pending states. It marks provider revision, locale, blocked lifecycle states and reference_only evidence in non-visible test metadata. It makes no WhatsApp/Meta/provider call and must never present its local transition as provider approval or delivery.

Authority and visibility. The New-message chooser is visible only to members allowed to view the conversation book. Message a customer is enabled only with the channel-send permission for that tenant/channel; without it the operator sees the account’s ordinary read-only conversation route and a concise permission explanation, never a simulated send, template form or provider state. Template creation, submit, replacement and administrator-only remediation remain independently permission-gated. A permission, policy, consent or evidence failure never discards the composer intent; it names the blocked action, gives the authorized next step where one exists, and creates no outbound attempt.

Accessibility: drawers and review cards use labelled dialogs, Escape/close returns focus to the composer, keyboard focus remains visible, all icon-only controls have aria labels/tooltips, and sender/background contrast meets the shared text standard. The New-message choice and customer selector likewise return focus deterministically as stated above. Analytics records message_workspace_opened, sidebar_toggled, workspace_resized, email_history_opened, email_native_opened, email_reply_attempted, whatsapp_window_intercepted, whatsapp_template_reviewed, whatsapp_template_submission_state_changed, whatsapp_outbound_entry_opened, whatsapp_outbound_customer_selected and whatsapp_outbound_entry_dismissed, with tenant, actor, thread, source/template revision and result; never raw message body.

MSG-25 · Messages and native communication handoff

Superseded by THE-OUTPUTS-SPEC.md OUT-05 (E200 · FEED-IA §202). «Open chat» and «Open the email» open the app’s own surfaces, and one email door replaces the separate communication-history icon. The history below is kept.

MSG-25 is the live order-review interaction contract. MSG-24-HISTORICAL is preserved only as design history for a possible later customer-outbound capability; none of its composer, New message, sidebar or Meta-template controls may render in the order-review profile.

Messages is a source workspace with exactly two postures: collapsed and expanded. There is no hide-sidebar posture, New message flow, Meta-template dialog or in-product customer send.

⚠ «customer composer» left this sentence with FEED-IA §196.7 (E193.08) — «emails can be answered in the chip or by hitting reply and answering in the composer otherwise it's whatsapp» — and the composer's contract is MSG-26 below. The SOURCE is still read-only and still provider-custodied, and there is still no in-product customer send: the composer hands the words to the channel's own door and the app delivers nothing.

Frame and geometry

• Collapsed desktop has two deliberate sizes. The conversation panel is 400 px wide and min(78vh, 720 px) high; the conversation-book panel is 640 px wide and min(84vh, 760 px) high. Both keep a 24 px viewport edge and share the launcher's corner.
• Expanded desktop occupies the viewport with a 24 px inset, the shared large radius, a soft deep shadow and 7 px backdrop blur over inactive application content.
• At 767 px and below both postures resolve to one full-screen conversation surface; bottom navigation is hidden and safe-area padding applies at the bottom.
• Controls are 48×48 px and sit on the actual outer header edges: Back chevron left; one posture toggle and one Collapse chevron right. No duplicate expand, text Chats, or Hide sidebar.
• Expanded desktop's conversation book is 400 px. Conversation content is centred in the remaining area with a readable maximum. Dots cover the whole conversation ground and use only a pale brand-red tint.
• Restore retains thread ID, scroll anchor, source route and collapsed/expanded posture. Opening an albarán parks that snapshot; returning restores it. An unrelated route clears it.

Object boundaries

Conversation rows use a whole-row rounded neutral hover/focus state like WhatsApp. Name, true last-message preview, timestamp and outgoing ticks stay within the one row. Unread uses a count or dot only where there is a real unread state; dots never decorate actions.

Incoming and prior outgoing messages use neutral bounded bubbles; brand red belongs to the pale dot ground and attention accents, not a customer-message fill. Message, email and order objects have a 1 px quiet boundary and a stronger soft shadow only where they float above the ground. Hovering a message or order card changes its whole rounded container, never an isolated word.

A condensed albarán card is unvalued. Header: delivery day and document number on the left, one text action Open at the top right. Body: exact product name plus quantity/unit; unresolved lines show their proper field, provisional or multiple-choice state. There is no euro total, bottom Open albarán, expand icon, customer link or second destination. Previous/next controls belong to the opened Albarán Sheet.

Reply attention and bottom dock

A ReplyAttention renders as a tray immediately above the bottom dock, nearly the dock's full width. It states the reason, for example Reply needed · The customer asked which size is available. The tray can coexist with line checks, has one dismiss action with optional free-text rationale, and keeps its evidence scope. It is not a tiny Needs reply badge.

⚠ E193.08 (FEED-IA §196.7) repeals «not an editor», and nothing else in this paragraph. What still holds, unchanged: WhatsApp shows the supplied official channel mark and an icon-free Open chat; email shows provider identity, Open Gmail / Open Outlook and a separate communication-history icon; individual email messages are bounded cards whose backgrounds never open history; email remains provider-custodied and read-only in Rocoto; and opening the native provider records only that the door was used, never that a reply was sent. The door moved onto the composer's own channel line rather than standing as a second strip; its identity, its label and its destination are the same.

The hybrid composer · MSG-26 (FEED-IA §196.7)

Superseded by THE-OUTPUTS-SPEC.md OUT-05.6 (E200 · FEED-IA §202). A connected house sends from Rocoto and the conversation gains its turn; the native door stays as the fallback. The history below is kept.

The customer thread's dock is a composer, and the composer states its channel on the send control — the disc §196.7 names, which is always on the bar and wears the channel whether it is ready or waiting.

⚠ THE MIC HAS A SEAT OF ITS OWN BESIDE IT (E193.17, §196.7 read with §196.8). It was one seat with two occupants — the messenger idiom the kit Composer ships — and read together the two clauses of §196 CANCELLED: a prefilled draft is typing from the first render, the seat then held Send, and the transcribe mic was unreachable on exactly the messages that carry a draft. The seat follows what the mic is FOR. A mic that RECORDS shares the seat, because the take IS the message and it is an alternative to sending. A mic that DICTATES does not, because the take becomes words in the box — something you do BEFORE sending, and often on top of words already there. This one dictates, so:

• Send is always present, dimmed while there is nothing to send, and the mic stands before it — 🎤 (➤), the Copilot editor's own order, ported.
• The mic is a ring, not a second coloured disc («add a transcribe mic button like with copilot», and the Copilot's is «a backgroundless mic beside it»). Two identical channel discs side by side read as two send buttons. Dictation is the same act on WhatsApp and on email, so a channel colour on the mic would promise a destination it never touches.
• The waiting send is the channel standing back — the same hue at a lower saturation (channelTheme repoints buttonDisabledFill too), never the app's neutral grey, so an empty composer still says which pipe it is pointed down.
• Both keep the 44 px floor at every width, and the writing surface grows to seven lines before it scrolls — the port's own ceiling, because a drafted reply is a paragraph the app wrote and the person has to read it before they trust it.

The channel itself:

Both colours are declared once, in src/rocoto-theme.ts (CHANNEL_INK), under the same bounded licence the emulated WhatsApp pane holds: a channel is somebody else's mark, and the accent stays reserved for Rocoto's own act. The paint reaches the send disc and the record disc through a scoped theme (channelTheme) that repoints six button roles — the ready pair, the two press states and the WAITING pair; no component learns what a channel is.

Colour is never the only carrier. The composer states data-channel and data-because, the control's accessible name says the channel in words, and one quiet line under the box names the channel, says why where a reason is worth stating — WhatsApp starts the moment Meta confirms your number. — and carries the native door.

What «hooked up» is read off. Exactly two facts, both things that happened: the activation ledger's whatsapp-connect («a verified provider callback bound the number»), or a customer's own WhatsApp message standing in the conversation — nobody receives on a number nobody bound. A settings toggle, a customer's stated channel and the live cohort are not evidence and are never read.

The mic dictates. Speech becomes words in the box through the kit runtime (Deepgram nova-3), exactly as the Copilot's does, with the same honest states: Transcribing…, Dictated N words into the box. Edit it, then send., Runtime offline · type the words here. It dictates on both channels because the app sends on neither — an audio payload would have nowhere to go.

Nothing claims delivery. Pressing the control opens the channel's own door carrying the words — wa.me/web.whatsapp.com, the connected provider's compose window, or mailto: — the conversation gains no turn, the words stay in the box, and the line says which door opened. A trading name is never handed over as an address. The source record itself keeps no field: the composer stands beside it, which is what keeps email provider-custodied.

Reply. Each received email card carries Reply; pressing it aims the composer at that message (data-because="reply-aimed", placeholder Reply to …, the subject carried into the door) and writes nothing into the record.

Drafted replies · MSG-27 (FEED-IA §196.8)

Wherever the app tells a person to reply, the reply is already written. A standing response concern — and nothing else — puts a draft in the composer, in Messages AND in the composer inside the chip embedded in the albarán.

• The words are composed deterministically from the document's own facts: who the customer is, the goods the concern names, the delivery day. Nothing internal crosses into them — not sale.reading, not needsReply.about, not the withheld sentence, not a policy word — and they promise no price, quantity or availability the house has yet to decide. Four shapes: a complaint, a question, a request for more, a held order.
• The mark reads Draft, and beside it stands Rocoto's own withheld reading (§9.11's abstention, visible at last) with Delete at the right edge.
• Focus selects the whole draft, so one keystroke replaces it. Typing takes the box: data-draft moves standing → taken and the mark comes off. Emptying the box hands the seat back to the draft.
• Delete is remembered, keyed by document and concern, in the same shape dismissals.ts keeps: the same concern never re-drafts, a new concern on the same order does, and deleting in the albarán deletes it in Messages. The prefill itself is never written to the draft store — a reload re-derives it, because it is a prefill and nothing more.
• The person sends. Nothing here reaches a channel.

⚠ This supersedes §110's ghost (chat-ghost) where a reply is owed: the withheld reading that stood on a pill above an empty field now stands in the field, marked and deletable. Where nothing is owed, §110's offer is unchanged.

Flagged orders in Messages (FEED-IA §196.3). A message belonging to a flagged order wears red-flag.tsx's own 2px red outline on the bubble; the pinned order card wears the outline and the flag's word; an order nobody flagged wears neither, and every red identifier on the surface resolves to one colour.

Internal Copilot

⚠ E193.02 (FEED-IA §196.2) re-seats this surface; notes/THE-COPILOT-SPEC.md is its contract. Copilot is a first-class AGENT: the frame's third grid track (E193.16 — the screen on a phone · the screen on a desk too narrow to hold both · 416 px beside the work · a 216 px sessions rail beside 416 px at ≥ 1728), a thread on ruled grid paper, and SESSIONS per tenant — a list, a current one, New, Forget — filed only when work happens and surviving a reload. Its chat and composer are ported from app.soyrocoto.com's own copilot column. The supply report, the affected-order review and the catalogue correction are CARDS inside a turn rather than modes that replace the conversation, so the composer stays live beside them and there is no way «back» out of a mode because there is no mode.

IT PUSHES, IT NEVER COVERS (E193.16, §196.2 «in full even down to the grid»). The live app's copilot IS the desk grid's third column — .desk.has-copilot { grid-template-columns: 216px minmax(0,1fr) 336px } — so shell/frame.tsx reserves a track of exactly the column's own width and the column stands IN it: the rail's recipe mirrored, sticky, one screen tall, gridColumn: 3. The day bar keeps its whole line, the right pane stays on the screen, and the launcher the agent was opened from stands beside it, so it is a toggle rather than a one-way door.

AND THE ROOM THEN DECIDES THE RUNG. shell/viewport.ts reads §103's ladder off the width MINUS the reserved track: 1366 − 416 = 886 px of work is the STACKED rung's room, so the desk stands its two panes one at a time instead of squeezing a 640 px document into 494. The housing question stays the window's — no docked column may put phone furniture on a desk. Where the window is too narrow to hold work and agent at all (≤ 1095), the column reserves nothing and stands in FRONT as a destination, with the scrim and the head's own way out — the stacked desk's own push model, never an overlay across half a screen. The reserve is given back the moment the agent closes.

The rail's 1728 is derived, not chosen: 216 + 416 + 1096, the room two honest panes need. It was 1440 while the column was an overlay costing the work nothing; as a track, 632 px of a 1600 px desk is forty per cent of the screen and the desk lost both its panes to a list of past sessions.

Copilot owns the only active internal composer in this release, in the port's EDITOR shape: one box with the writing surface above a control row, a ghost mic BESIDE a send that is always present (dimmed until there is something to send), Enter to submit and Shift+Enter for a new line, and a field that grows to a stated ceiling and then scrolls. Dictation appends to the draft and never sends a voice note; it goes to the kit runtime (Deepgram nova-3, Spanish) and states its machine on data-dictation — with the service absent the line reads Runtime offline and typing stays usable. No transcript is ever invented, and no thinking state is drawn for work that is not happening.

Internal messages, proposal cards and compact activity/tool summaries have clear boundaries. A general turn may explain, organise or draft, but visibly states when it changed no data and contacted nobody. Catalogue feedback and supply-impact reporting can attach exact Product, Customer and Albarán cards. Applying a catalogue proposal, editing an albarán or opening a native provider remains a separate explicit action. The current release has no assistant customer-send action.

Accessibility, events and nonclaims

All icon-only controls have accessible names and tooltips; hover has matching focus-visible state; tray, dialog and mobile layers restore focus to their opener. Text, rows and actions remain usable at 360×800, 390×844 and 393×873 with the on-screen keyboard.

Analytics records message_workspace_opened, workspace_posture_changed, conversation_native_opened, email_native_opened, communication_history_opened, reply_attention_viewed, reply_attention_dismissed, order_card_opened, assistant_conversation_opened and assistant_draft_submitted with tenant, actor, object IDs, revision and outcome. It never records raw message or assistant body in operational analytics. No local state means the customer replied, a provider accepted content, a document was delivered, or a runtime/model achieved an accuracy level.

INTX-12 · E188 list, line, filter and mobile-work contract

Authority and precedence. FEED-IA §188 established this physical-interaction contract; E191 supersedes only the valued Albarán hierarchy. This section supersedes every older full-width list hover, repeated product-column heading, cramped phone next/previous control, parallel Export-filter drawing and fixed multi-column money grid. Capability availability remains separately gated.

Cross-surface visual proof. Inspect the same built artifact at 1366×768, 1536×864, 390×844 and 393×873 in Sales, full Albarán, Messages, Products, Customers and Export. Evidence includes hover/current list geometry, a long wrapped item, a large decimal terminal, all three line states, invalid inline-edit recovery, open Filter draft, keyboard-reduced edit and phone dock. Full-width highlight, euro leakage, clipped terminal unit, tiny art, column drift, shifting borders, permanent form underlines, sub-44 px touch actions, duplicate glyphs or unreachable actions fails INTX-12.

INTX-13 · E191 tariff-card and mobile matrix interaction

Long tariff/product names wrap or ellipsise only in their bounded identity slot. Large decimal values use tabular figures and may enlarge their field; Unit stays attached to the number and the page never scrolls horizontally. Proof covers 1536×864 and 1366×768 desktop plus 360×800, 390×844 and 393×873 with reduced visualViewport, invalid recovery, three and one tariff fixtures, product swipe and no focus loss. A software keyboard is platform UI; browser proof asserts decimal input, retained focus, visible actions and visual-viewport response rather than fabricating a keyboard screenshot.

INTX-14 · E193 red-flag identifiers and the onboarding ring

FEED-IA §196.3 · §196.4. Peter, 2026-09-04: «any fucking alert or message for "flagged" orders have to have red identifiers and not dots, like red outline on the message etc like come on be top down!!!» and «Also the onboarding circular bar shit like remove the numbers from it».

⚠ Supersession. This repeals the DOT as a flag's identifier — §185.7's «pale brand-red dots» and attention-dot.tsx's 6px disc for §127.3's claim. Everything else those sections settled stands: one fold decides the claim, it carries a sentence a person can read aloud, it never decorates resolved history, and it clears on an act or a dismissal-with-why. §127.3's accent reservation is widened by one sentence and no more — the accent marks the AI's own act, the claim that a person is waiting, and a FLAGGED ORDER. No warning colour, no positive colour, no second red, no traffic light.

The vocabulary — five marks, one hue, one file (app/red-flag.tsx)

What «flagged» means

One fold, flagStandingOf(sale), and any of three facts is a flag: a standing response concern, a standing check concern, or sale.flagged — the operator's own Flag/Unflag ledger event, which before §196.3 was the only flag in the product that wore no red anywhere. «To review» filters and counts exactly this set, so the tally and the outlined rows are provably the same set.

The boundary that keeps the claim believable. A customer BEHAVIOUR reading — «Ordering well under their rhythm», «Changed the order after it was recorded» — is an observation about a year of trading, not a flagged order. The customer book carries no flag vocabulary at all.

The onboarding ring (§196.4)

The sidebar/day-bar journey mark shows fill only: the arc, and no figures on or inside it. ⚠ This supersedes THE-CHECKPOINT-AUDIT finding 8, which had stamped «0/10» inside the circle. What that finding protected survives in words: the card's aria-label still reads «n of N done · next: <step>» and its title still names the next step, so the progress is STATED rather than drawn. The collapsed card holds a real 44 px target at every phone width (flexShrink: 0; the day yields).

Evidence. drives/drive-196-red-flags.py — 512 GREEN / 0 RED at 1920 · 1600 · 1536 · 1366 · 393 · 390 · 360, proven red first by six source flips across fifteen claims (62 deliberate reds). ?theme=proof moves the whole vocabulary to the proof brand's green, so no colour is owned outside rocoto-theme.ts.

INTX-15 · E193 parsing and the packing mark (§196.5)

The two full contracts live in THE-PARSING-SPEC and THE-QR-SPEC. What belongs here is the INTERACTION: what a person sees, what each state says, and what a press may do.

The extraction seat

One seat under the source it came off — albaran-intake-extraction on the albarán, stock-batch-reading on the stock batch — wearing data-state and data-provider.

⚠ A repealed negative. The stock card said «OCR is not connected yet». §196.5 connects it, and the sentence was a sentence about what the product could NOT do. What stands in its place is the evidence line, or the honest runtime posture, and in both cases the next thing to do.

The proposal

Rows are PROPOSALS (§191.1). Each is matched against the house's own catalogue; a row that matches nothing shows as New to the house · write this line yourself and is excluded from the count — the albarán may only carry goods the house sells (§191.7). The quantity sits in a 44 px input a hand corrects first, in a terminal whose width is a COLUMN PLAN sized once per proposal off its longest quantity and unit (§194.2), so the figures line up down the card; on a phone that seat takes its own line when the plan will not fit beside the name. Put N lines on the albarán writes through addLine, the composer's own event; the paper's stated unit price stays beside the row as evidence and is never written, because the house's price list is the price (§191.4). One source is read ONCE however many seats display it.

The reading road

qr-read.tsx states its road as data-road: native (the browser's BarcodeDetector), library (the bundle's decoder slot — OWED, QR-09), typed (the token printed under the mark, which works on every browser with no camera at all). A resolved code NAMES the run and says whether the paper still matches it; it opens nothing and writes nothing by itself.

Evidence. drives/drive-198-parsing-qr.py — 294 GREEN / 0 RED, proven red first by six source flips across 33 deliberate reds: the six-viewport band for both parsing postures, the long-value proposal and the typed road; the app's own QR decoded by a real libzbar at three print sizes and through rotation, contrast loss and an occlusion sweep that survived 2–10 % and failed at 14 %; and the reader's two roads driven end to end.

INTX-16 · E193 the voice rail — identity, calls, the transcript, the dial (§196.6)

The full contract is THE-VOICE-CONNECTION-SPEC · PART TWO (VOICE-17…VOICE-23). What belongs here is the INTERACTION: what a person sees, what each state says, and what a press may do.

The standing line — one sentence, four surfaces

RuntimeStanding (voice-objects.tsx) is the only place the kit prints the rail's state, so the words cannot drift between Connections and a customer's sheet. It wears data-voice-ready (yes/no) and data-voice-standing.

Readiness is TWO facts agreeing — the runtime reporting twilio: configured AND the tenant's saved house number. Neither alone is a line. Check again re-reads health without a reload.

The identity card (data-identity-state)

The provenance line stands on the card's face in EVERY state, before it holds an answer. The lookup is automatic ONLY on an unknown caller — the number belongs to nobody in the book and the call has already happened; everywhere else a person presses, because the house is the authority about its own customers (VOICE-07C's order, enforced by where the lookup is automatic). Google links nobody: on a create-customer draft, Fill this draft with it copies the name and address into fields a person still confirms.

A call, as a row (data-call, data-call-missed)

The same anatomy on every line, in the same columns: the channel mark · the kind (+ «Missed» pill) · when, and how long when there was a how-long · one concise state about the audio at the right. Pressing a row opens the call; it never opens the customer or an order by surprise.

The audio state at the right is Transcript ready or Metadata only — never a second way of saying the kind, which the row's own words already say.

The call, opened

Direction · Duration · Audio as three facts; Between (the two numbers) and When; a missed call states what it left behind — «The call rang out. Ring them back from here.» — then the transcript, then the acts. Provider identifiers and media URLs never appear.

The transcript panel

data-transcript-language="es", and a provenance line that says the engine, the number of voices and which voice the house is: «deepgram nova-3 · Spanish · 2 voices · Marc Danés is voice 1». Each line carries its speaker's NAME and its second in the call (0:07); the house's lines sit right, the caller's left. Swap voices moves the house's voice to the next speaker and the call remembers it (rocoto-call-voices). Quote this line puts «who · when — the words» on the clipboard and says «Copied · paste it in the reply». Under it, the custody sentence: «Recording held by Rocoto · the words stay in this account.»

The activation test (Connections, step 4)

Two rows, each with its own state word at the right and its own control.

A leg that finds nothing stays waiting, forever if need be. Neither pass is written into the saved setup: phone-connection-config normalises every provider-owned field back to pending on write, so a saved setup still reads not-run (VOICE-01A.1).

The unmatched queue

With a runtime answering, the queue IS the inbound calls on the house line whose last nine digits no account in the book owns. Each row is a CallRow; opening one asks Places by itself. What the kit does NOT do is write the link: CallAssignment is the server's (VOICE-03H) and the contract names no endpoint yet, so the surface says it — «The account this caller belongs to is a person's decision, kept with the call on the runtime» — and Call them back is the act it can honestly offer. With no runtime, E191's labelled preview stands exactly as it did.

Evidence. drives/drive-199-voice-real.py — 245 GREEN / 0 RED at 1920 · 1536 · 1366 · 393 · 390 · 360 across four postures (runtime absent · runtime without Twilio · the harness answering · the live W6 runtime), proven red first by six source flips across 16 deliberate reds. drives/drive-191-voice.py — 271 / 4, its two §196.6-repealed claims migrated in place, the four remaining reds named as E193.02's hidden Copilot dialog.

INTX-17 · E200.07 the live field, everywhere a value is picked from a list (§196.1)

Peter, 2026-09-04, on the E192 product sheet: «any time its a field that is sort of cms related like a form field for a product there should be a dropdown with suggestions appear which filters as people type… same for units, same for like other shit.» E193.01 wrote that organ (app/src/app/live-field.tsx) and mounted it on the Product Sheet alone (THE-PRODUCT-SHEET-SPEC §0.0). This section carries the same law across the whole application, so a person meets ONE field rather than four.

INTX-17.1 · One organ. Every field whose value is picked from a list is LiveField. There is one dropdown engine in the app — Base Web's own Combobox, wrapped once — and no surface mounts a second. ⚠ SUPERSEDES LiveChoice (the attached menu of §116.3/§122), which is retired: a menu shows everything and narrows nothing, which is the «doesnt look like live dropdowns» Peter named. It also supersedes Base's bare Select on these seats, and the chip rail the customer's tariff used.

INTX-17.2 · The house's own values, and what a typed word means. A field's list is what the tenant already has. Typing filters it: values that BEGIN with the word lead, values that CONTAIN it follow. An open register takes a word the house has never used, marks that row New, and keeps it literally. A closed register — one whose members carry consequences (a channel the runtime routes on, a tariff with prices behind it, a run the map draws, a role that grants rights, a unit kind that decides how a number behaves) — declines a word it does not hold and says how to answer: «Choose <the field's noun> from the list.»

INTX-17.3 · The seat prints the noun once. Where the seat already carries the label (a customer Fact, a team LiveFact, an admin Row), the field is mounted with hideLabel and keeps the name as its aria-label. One field never wears two names, and the visible label and the spoken one are the same word. An optional field says Optional once, on the label's row.

INTX-17.4 · Nothing opens a dialog to change one word. THE-PRODUCT-SHEET-SPEC §0.0.6's carve-out is the whole carve-out: a sub-object surface (Unit conversions) survives; a FIELD does not. ⚠ E200.07 SUPERSEDES the Team card's Role overlay — its five bundles are the field's own option rows, each carrying the sentence that says what that person does — and the sentence under a person's name is a statement, no longer a door.

INTX-17.5 · A control stands apart from the content beside it. A run whose comercial was already set drew a person chip and no control, so the one fact a house re-decides the week somebody leaves could not be re-decided. The chip is the PERSON; the field is the DECISION, and both stand.

INTX-17.6 · Geometry. 44 px on the input and on every option row, at every width (INTX-12's floor, kept on the desk too so one field has one geometry). Cells sharing a grid line share their input's top edge: a row of fields is top-aligned, because a live field grows a line under itself the moment it says «Saved» or names a word it declined, and a bottom-aligned row would push its own input off the line. The keyboard order is the reading order, and the list is driven with typing, ↓ and Enter alone.

The eleven this release converted. Customer sheet — slot (open), channel, settles, profile-tarifa. New customer — new-customer-channel, new-customer-run (optional). Team card — truck (open), zone (optional), role. Geography — zone-comercial. Administration → Units — tenant-unit-kind.

What is NOT a field, and stays as it is. Connections' «Choose your ERP» card: its four names are an integration decision that reconfigures export mapping and carries a posture paragraph, and the card exists to SHOW that register rather than to hold a value — the same reason Unit conversions survives §0.0.6. The unit registry's Unit name and Plural stay free text: a registry that makes a new word may not offer the word it is about to refuse as a duplicate.

Evidence. drives/drive-200-live-fields.py — 148 GREEN / 0 RED at 1600 and 390, walking all eleven fields through the five questions above. Red-proved against the published kit (https://kit.soyrocoto.com/app.html): 10 GREEN / 34 RED, the three named claims failing there with «0 seats named channel», «0 seats named role», «0 seats named tenant-unit-kind», and the customer sheet still reporting menus=2 for the attached menu this section retires.

Source document ↗