Osnara design system.

Monospace labels

After discovery

Uppercase for short eyebrows and category labels. Sentences and explanatory metadata use sans-serif. Preserve the original casing of filenames, URLs, code and identifiers.

<BottomNavigation items={items} />

View the approved navigation in Figma. The standard master and linked screens are updated; preview utility and admin variants remain code specimens.

<BottomNavigation items={adminItems} />

Patterns in use

Established direction records Christian’s confirmed rules. Local pilot identifies a bounded implementation; it does not claim full state coverage or full Figma parity. Interactive specimens above stay on this page. Additional workflow studies are available in the development reference.

• Whole-card navigation

  Established direction · October 22 whole-card use-case navigation

  When a card has one destination, make the whole card a native link. Include its image, text and padding in the target. Use the visible heading as its accessible name, retain a visual action cue and show the existing focus ring around the full card.

  One keyboard stop per card; no nested links or buttons. Cards with separate controls need separate targets and must not use a whole-card wrapper. Preserve native open-in-new-tab behavior and use semantic theme colors for hover and focus.

• Conversational product copy

  Established direction · October 19 Humanizer copy direction

  Use everyday words and complete, varied sentences. Describe what the person can do and what happens next. Founder copy uses Christian’s supplied experience and voice; avoid staged slogans, repeated fragments and internal terms such as bounded work or metric strip.

  Keep permission requirements, fictional disclosures, uncertainty, save outcomes and private versus published states explicit. Friendly wording must not promise AI accuracy, automatic access, retention or confidentiality beyond the product contract. Preserve legal substance. Keep familiar action labels stable. On the marketing homepage, give the founder note and closing invitation distinct editorial roles. Access CTAs lead to the dedicated contact page, where the request form and manual-review/account steps stay together; align editorial split sections to shared column anchors. The homepage hero uses left-aligned copy beside its decorative artwork on desktop and stacks the illustration below readable copy on phones. Decorative connectors attach to actual card edges as text and viewport dimensions change. Keep the CTA above the artwork.

• Collapsible workspace navigation

  Local pilot · October 19 workspace entry and navigation direction

  Desktop uses a persistent expandable sidebar. The compact rail uses the selected Form O with labeled navigation icons. Group non-interactive account identity, the single Settings destination and theme controls at the bottom; keep the lab credit subordinate. Preserve the local collapse preference without storing account information.

  Collapse changes presentation only, not available destinations or permissions. Keep keyboard names, active state and focus visible in either mode. The rail scrolls in short windows; mobile retains BottomNavigation. Marketing and workspace mobile headers share a 64px frame, 20px gutters, centered 122px wordmark and 44px controls. Project options open inward above their trigger on narrow screens. Browser theme color, root/body canvas and color-scheme follow the selected theme from startup and across route metadata changes; native Safari chrome still requires device confirmation. Authentication entry resumes a verified existing session without extending its lifetime. On route navigation, keep the rail in place and settle the incoming page once using the existing reveal duration; typing, saves and query updates do not replay the entrance. Reduced motion shows the finished layout immediately.

• Established action colors

  Established direction · D07, D121 (reverts D120)

  Use the semantic action token for the single primary action in a task. Match the existing Figma action, action-text and action-hover variables: charcoal in light mode and pale green-gray in dark mode. Progress intent uses the existing sea token. Use green only in its established accent roles.

  A new color value or a change in a token’s semantic role must be presented as a proposal before adoption. Use the shared Button for task CTAs, with secondary or quiet appearance for supporting actions. Review later is quiet navigation; confirmed deletion or link revocation uses destructive intent, while retry remains neutral. Native action links keep link semantics and reuse existing action-token styling. Menu, disclosure, tab and dictation controls retain their own contracts. Preserve the same action-color role across product routes and theme changes.

• Quiet guidance before saving

  Established direction · D114

  Place short, readable helper text near the save action to explain what changes and what stays unchanged. Use muted sans-serif text without a colored panel, shield or confirmation checkmark for routine save guidance.

  Keep consequential warnings and explicit consent visible and distinct. Guidance describes behavior; it does not assert that saving has succeeded or that user-authored evidence is verified.

• Settings grouped by consequence

  Local pilot · D112

  Align section title and explanation beside its form on desktop; stack on narrow screens. Reuse system inputs and action hierarchy. Keep profile, professional context, public collection, password and account actions distinct. Publication review uses one surface with aligned identity rows, readable trust guidance and a separated consent row; avoid nested notice cards. URL prefixes and editable slugs share one input boundary and focus ring.

  Keep supplemental How this works disclosures closed initially while consequential summaries stay visible. Group account removal in one surface, separate from sign-out. Preserve public-identity review and destructive confirmation. Failed password submissions retain the current in-memory fields without persisting or logging them; confirmed success clears the form. Failed Featured selections restore the previous local choice and explain that the save did not complete. Preview actions must explicitly report simulation and never call account or publication mutations.

• Opportunity preparation and controlled sharing

  Local pilot · D107, D108, D109, D110, D111

  Use the shared Applications location. Saved opportunities follow a numbered role review, supporting-work selection and private-portfolio review sequence, using existing section links and title/content alignment. Keep the suggested next action compact and preserve access to every section. Empty recommendations lead back to Library. Sequence opportunity input before full-width results; retain the submitted description in a collapsed disclosure and place the existing quiet Edit job description action inside that disclosure with input preserved. Keep the result header to the role title and compact source control; preview explanations belong outside the product header. Do not keep the input form beside completed results. Group recommended work, project rationale, story focus and the next action together. For multiple projects show compact expandable rows with a visible contribution summary and one group action; preserve the single-project card. Never infer a lead from array order: a featured lead requires explicit evidence-backed ranking. Give evidence support a separate secondary group, distinguish supported requirements from those needing review, and keep the optional story outline collapsed. Show evidence support without a match score. Keep requirements readable before expansion. Private portfolio modes separate reading, editing and publication; the public portfolio shares the approved story reader shell. Sticky saves clear the mobile navigation dock.

  Selecting work, saving a private version and publishing are separate states. Preserve confirmed-evidence, related-project and publication checks. A newer private draft never implies the shared snapshot changed. Fictional previews guard generation, persistence, sharing and tracking. When asking users to review a journey, valid input must advance to clearly labeled fixed sample results and connected next steps rather than a permanently disabled primary action. Move focus to the revealed results.

• Visible knowledge, expandable evidence

  Local pilot · D106

  Show each recovered area with its existing insight visible beside a consistent label column, beginning with Problem. On mobile stack label above insight. Long insights preview two lines and expand in place; short insights remain complete. Reveal source attribution on expansion. Short entries without additional detail are static. Keep missing areas and their recovery action separate.

  Use recovered text without inventing summaries. Story Map uses divided text rows with a visible recovered or not-yet-covered state, keeping recovered insights and source context visible without decorative category icons. Recovered content does not mean a problem was solved or a claim confirmed; do not add completion checkmarks. Expansion retains the full insight and keyboard-operable native disclosure.

• Opportunity actions within a project

  Local pilot · D103, D104, D105

  Nest opportunity context in a separated footer of the primary project task card, retaining the same text inset in Next step and saved Case study states. Keep it collapsed by default in a compact native disclosure: opportunity count, outstanding action count and chevron. Opportunity actions do not imply a prerequisite for building the case study. Reveal the project text grid and semantic action styles on demand. Name the opportunity, group outstanding actions and link directly to the contribution question. Ownership recovery retains the app shell and breadcrumb, with the question before supporting context. Group contribution-writing tips under What to include above the answer field; distinguish personal decisions from team work and make outcome guidance conditional on what is known. These are prompts, not separate completion tasks. Reusable-fact review keeps the exact quote visible as a quiet Source line separate from editable fact text; reuse the existing project-learning treatment rather than adding a quote notice. Both proposal-review consumers use divided rows within their existing section or task surface, with a visible editable-fact label, plain uppercase Mono category and existing shared actions only for pending proposals. Saved and declined history remain read-only; no nested row cards or category pills.

  No project actions describes only this project in the current private draft, not whole-portfolio readiness or evidence confirmation. Fictional previews disable saving and voice; portfolio destinations are explicitly unavailable. Post-save proposal review still requires live verification.

• Project actions and destructive confirmation

  Local pilot · D102

  Keep secondary actions behind a 44px options trigger. Opening the disclosure focuses its first action; Escape returns focus to the trigger. Destructive actions open a modal confirmation with Cancel initially focused, a clear consequence, contained focus and explicit confirmation. Preserve errors in the dialog.

  Do not treat opening confirmation as permission to delete. Fictional previews disable deletion in both UI and handler. The real delete workflow is unchanged and was not exercised in visual QA.

• Uppercase monospace labels

  Established direction · D99

  Use uppercase for monospace eyebrows, short category labels and step labels. Use the regular sans-serif for sentences, instructions, captions and explanatory metadata. Casing is owned by the label style, so sentence-case source copy cannot drift visually.

  Never uppercase source filenames, URLs, code, token names, identifiers, or quoted evidence. Numeric indexes may remain monospace. Apply casing by semantic role, not a global font selector. This is the Osnara rule; it does not change shared FDL typography.

• Unavailable task with a clear return

  Local pilot · D101

  Keep location navigation stable. Use an uppercase mono eyebrow, a compact regular-weight heading, a brief explanation and one safe return action. Preserve generous padding; omit decorative hero panels and completion icons.

  Paused drafting is a service state, not evidence confirmation or project completion. Do not offer retry while the operation is disabled. Enabled drafting remains a separate state.

• Stable location, flexible task content

  Established direction · D96, D97, D98, D113

  Unavailable tasks retain the breadcrumb and use a compact heading, short explanation and one safe return action; omit decorative hero panels and completion icons. Library remains active for project, recovery, import and new-project routes. Empty case-study states retain the same breadcrumb row as saved stories. Keep breadcrumbs in a 56px shell-owned row before width-constrained content. Use a 40px desktop inset and 20px mobile inset; never center navigation with the task panel. Parent locations are links, current location is plain text. Recovery phases share the Recovery location; phase progress stays with the task. On mobile show the immediate parent and current location. Keep a compact Library heading with count and primary action. Ordinary workspace page titles reuse the existing page type role (32px/38px, installed sans 400), including Library, project, opportunity, Applications and Settings. Preserve the distinct auth, focused-task and editorial reader scales; short uppercase supporting labels use installed Mono 500. Landing page display copy retains its scale with the approved sans face.

  This is navigation, not workflow progress or evidence status. Keep the app shell during instant and deep recovery, including paused states. Import, discovery review, and new-project setup use the same location row. Keep preview-only controls below the product. Keep essential orientation in the location row; role, company, year and overall coverage belong on the project overview, not in a repeated Project context accordion. Long labels truncate without wrapping the row and retain their accessible name. Public stories and immersive voice sessions retain their own purpose-specific shells. The coordinated reskin is deployed; Figma parity remains separate from code adoption.

• Trust guidance with a neutral surface

  Local pilot · D117, D118, D119

  Place the relevant privacy, processing, publication, or account boundary beside its action. Use the inline presentation when guidance sits inside an existing form or review surface: no nested box or shield, a muted uppercase mono eyebrow, and regular sans-serif copy. Reserve the neutral card and Osnara green shield/eyebrow for a stand-alone notice. At sign-up, keep both account-privacy details directly visible beneath the summary and place the privacy-policy link after them; remove the disclosure control. Use a closed native disclosure for secondary explanation in other contexts unless the decision requires its details immediately.

  Green identifies brand guidance; it does not mean evidence is verified, data is certified safe, or an action succeeded. Keep copy specific to the actual boundary and preserve the caller-owned action. Portfolio publication and case-study identity review use inline guidance; the public/unlisted warning remains visible when secondary details are closed.

• Focused private-beta authentication

  Local pilot · D115, D116, D119, D134

  Pair a clear authentication form with a distinct brand lane. Use the shared dotted gathering orb from the homepage and footer. In authentication it gathers once, then continues a slow, decorative rotation and surface current beside the form. Keep the motion quiet enough to support reading. Keep the current Osnara logo, a concise purpose heading, labeled fields, one primary action and quiet alternate paths. For private-beta sign-up, request the approved email first, then show one pasteable email-code field and password field with visible resend and change-email actions. Keep errors adjacent and announced. The sign-up trust notice keeps its account-privacy summary and both essential details visible, followed by the privacy-policy link.

  The orb is decorative, not a new logo or proof of processing. The homepage cycles between an open particle field and the formed orb; authentication stays formed after gathering; the footer gathers once and keeps the same dotted orb moving quietly. Use the inherited approved green, with opacity tuned for legibility. Fit the entire orb and its scatter within the canvas bounds, including the shallow mobile authentication lane. Respect reduced motion with a fixed still. The Resolve entrance sharpens only the logo; panels and fields use a short, finite settle on mount. Keep fields immediately interactive and animate the form as a group so validation changes do not replay its entrance. Never delay access, blur input text, or animate validation as a loading signal. Approval and inbox control are separate checks. Do not issue an app session when verification or password setup fails, and do not imply account creation before success. Hosted Auth settings and email templates must be verified before release. The shared frame covers sign-in, sign-up and auth-error recovery; password recovery is not added by this visual adoption.

• Clear loading, error, and missing-page states

  Local pilot · D115

  Use one quiet hierarchy: short mono state label, plain-language heading, concise next-step explanation, then one primary action and an optional secondary route. Keep loading copy factual, show quiet placeholders at content anchors without invented progress, and announce status separately from silent placeholders. When drafting fails, replace the running progress panel with a plain failure section; retain stage details in a closed native disclosure. Keep the earlier conversation available on demand. Never fill progress to 100% because an error occurred. Reuse the shared action component for retry. Keep errors actionable and do not claim user data safety or successful logging without evidence.

  A missing page is distinct from an authorization decision. A loading state does not imply analysis is running. Pending labels name the operation actually running: sending an email code must not display account creation. Redacted server diagnostics use a plain-language task failure; do not display framework boilerplate or diagnostic identifiers to the user. Preserve useful client validation and unsaved non-secret form values after rejection. Project-memory review failures retain edited fact text and show plain retry guidance instead of raw exceptions. A paused drafting response keeps its explanation visible in the update dialog. Case-study sharing preserves supported identity guidance and redacts unknown technical diagnostics; share and restore errors use adjacent announced text, without another nested error box. Clear public-identity review consent after a successful save so the next change requires a fresh review. Retry uses the existing route action; navigation returns to the library. Theme and breadcrumb remain visible when available.

• Processing, review, and recovery outcomes

  Local pilot · D94, D95, D113

  Keep the shell-owned breadcrumb row stable across every recovery phase, including questions. Keep privacy compact in the location row. Keep role, company, year and overall coverage on the project overview; omit the repeated Project context disclosure and Recovering badge within the task. Lead with the current task heading and place question progress beside the question. The project breadcrumb is the persistent return action. The mobile Story Map sheet uses the existing modal layer above navigation and shared dialog focus handling; Escape or its return action restores focus, and crossing the desktop breakpoint closes the sheet. Put supporting question context in a disclosure below the task; fixture state controls stay collapsed outside the product shell. Source reading and drafting use the shared gathering presence with a named activity; optional context begins with its question and field. Instant-recovery completion uses one labeled checkmark and a primary project destination. Failure stops the motion, explains the interruption, and offers retry beside a project return.

  Draft completion does not verify evidence or publish a story. Only show saved language after successful generation; fictional completion explicitly says nothing was saved. Fixture input is text-only and retries simulate a pending state. Full case-study generation retains its existing gate. Deep-recovery running feedback uses a plain divided section and counts finished stages rather than elapsed time. Keep the mobile recovered-details action available during drafting. Completion closes any open Story Map, releases its focus trap, and focuses the completion heading before the case-study review action. Completion offers one case-study review action and a quiet project return; omit celebratory cards, badges, and invented saved-output counts. Deep recovery reuses the existing regular-weight question/form surface: one active question, optional What to include guidance, and the inline answer field share a task anchor. Do not add a filled AI avatar, a depth badge or a detached sticky composer. Keep prior questions/answers and recovered context in native disclosures below the task; retain a submitted reply while the next prompt is pending. Label session progress separately from overall Story Map coverage; its mobile quiet action uses the same overall count and existing outline icons. Writing guidance describes only the active answer field and implies neither required subtasks nor confirmed evidence. Question continuity was inspected on desktop and mobile. The deployed reskin has bounded lifecycle acceptance; exhaustive mutation/state coverage is not implied.

• Signals gather around a stable mark

  Local pilot · D93

  Use a sparse orbit around the existing Osnara mark during reading or answer processing. Listening and speaking use a soft light within the conversation canvas. Keep the question and controls fixed; always pair decorative motion with a visible state label. Stop motion when paused, finished, awaiting review, or in error. Reduced motion uses a static equivalent.

  Motion conveys activity, never completion percentage or evidence confirmation. The voice preview is simulated and does not use a microphone. Live amplitude and real processing signals remain an adoption requirement. The existing mark is retained pending separate brand exploration; the orbit is a product behavior, not a new logo.

• Sources and outputs as quiet rows

  Local pilot · D83

  Show a project source as one flat row with a consistent 40px icon slot, title, quiet provenance or preview, and any management action at the trailing anchor. Keep Add file and Add note as equal secondary controls below the source list. Source-note composers reuse visible sentence-case field labels, optional native guidance disclosure, primary Save note and quiet Cancel. Move focus into an opened editor and return it to its trigger on close; describe any attempted story update before saving. Show output type and title before Read, Copy, or Remove. Use a contained empty or failure message with a specific next action; keep pending source names visible.

  A file or note is not automatically confirmed evidence, and a generated output is not published. Source rows display facts supplied by the caller. A saved source is not a processed source: a failed analysis must not mark it Woven in. If recovered details cannot be persisted or confirmed-edit protection cannot be read, leave sources pending. Applying selected details requires confirmed write receipts; a paused or failed draft rebuild cannot report completion. Once a source write succeeds, report it as saved even if follow-up processing fails; expose pending story work separately so retry does not duplicate the source. Rejected saves retain text and keep the user on the current step. The preview states are fictional and inert; the signed-in route retains its existing upload, note, generation, and deletion actions. Project Workspace descendants use this resource pattern; opportunity context and controls have their own D103–D111 patterns. Representative authenticated source saves and rejected-write retention passed in reskin acceptance. Ambiguous transport and broader variants remain separate.

• Compact navigation with clear hierarchy

  Established direction · D67

  Pair primary destination icons and labels horizontally inside an inset, bounded dock. Use a quieter utility control at the end, matching icon weights and 48px targets. Keep the current state contained to the destination instead of filling a third of the viewport.

  Desktop keeps the sidebar. Additional admin destinations remain visible in a wrapping grid with matching page-bottom clearance. Unavailable preview destinations do not behave like working links. Christian approved the overall dock direction; the standard Figma master and its screen instances match. Preview utility and admin grid remain documented code specimens. Publication and signed-in validation are separate gates.

• Consistent status icon geometry

  Established direction · D53, D64, D66

  Needs review and Needs clarification use the same plain question mark, optically centered in a fixed 14px slot with a 1.5px drawn stroke and 8px label gap. The visible label distinguishes project review from evidence clarification.

  Do not add a circle to distinguish these states or substitute a font glyph. Sharing an icon does not merge project recovery and evidence-confirmation semantics.

• Keep orientation while context loads

  Local pilot · D61, D63

  Keep known person, project, status, navigation, and theme visible. Replace only pending question and source content with quiet placeholders at the same content anchors. Announce loading outside the busy region; decorative placeholders are silent and do not animate.

  Do not show invented progress, new evidence, or a success signal. The local preview has an explicit loading control; it does not fetch context or measure real network latency. The task surface can grow when real content appears.

• Proposal, source, then decision

  Local pilot · D39–D41, D44, D86

  After source entry, state the current step and what the user just completed before showing proposals. Attach remaining-work indicators to the step or task they describe; name the user object, such as discovery, rather than the interface selection. Keep prototype-only state controls outside the product hierarchy. Show the proposed project and its evidence boundary before an explicit review choice. A review action opens an observable summary destination, repeats every decision, and preserves a route back. Place exact source excerpts beside the task on wide screens and in a disclosure after it on narrow screens.

  Source inspection and selecting Keep do not confirm every claim or save a project. Relationships do not merge projects; the final summary must repeat a selected relationship before confirmation. A title edit cannot silently turn context or clarification into a project. Restricted metadata stays metadata; reviewer guidance is not a source quote. The real /career-import/review route uses this presentation locally, while the fictional adoption fixture performs no persistent write.

• Confirm, report, then continue

  Established direction · D44–D46, D86

  Before a consequential confirmation, repeat the exact choices and say that nothing has changed yet. Keep the choices visible through pending and failure states. On success, report created, updated, and clarification outcomes in plain language, name what changed for each item, and provide one primary destination plus a quieter way to start again. Use one checkmark in the completion header; do not repeat it on the outcome rows. Keep optional feedback below the completed task.

  Completion does not imply that every underlying claim is confirmed. A clarification-only result must not claim that the Library changed. The real /career-import/review route now presents existing confirmation and completion actions; the fictional adoption fixture simulates them without a write. Actual import, save, and reopened-completion behavior remain release checks. Optional beta feedback never blocks the next action.

• One checkmark, one resolved state

  Established direction · D46, D58

  Use a checkmark only beside visible text that names a resolved state. Evidence confirmation, story recovery, and workflow completion keep their own explicit labels because they mean different things. Use one checkmark at the highest useful level; when a parent already announces completion, child rows describe their outcomes in text. A selected option may use a scoped checkmark inside its open menu as a standard control affordance.

  Do not use checkmarks as decorative bullets, on actions that have not happened yet, for generic availability, or repeatedly across adjacent levels of the same result. A checkmark never upgrades uncertain evidence, team work, or workflow progress into a confirmed claim.

• Choose, inspect, then submit

  Established direction · D37–D39, D42, D84–D85

  Keep source selection separate from submission. Show the selected file, editable link, or pasted text, processing guidance, and one explicit action. When the selected Paste source already names the task, use the textarea placeholder for the visible prompt and retain a visually hidden associated label. Do not hide recovery guidance behind a disabled action: once someone has entered content, let the attempt reveal a specific inline correction and return focus to the field. A valid action must show progress and arrive at an observable next screen. Preserve input through a recoverable failure and provide retry or replacement.

  The fictional import study remains simulated and does not upload, analyze, or save. The signed-in /career-import route now uses this presentation with its existing upload and paste actions. A single-project URL remains on /new; the real Career Import does not claim whole-portfolio link discovery. Neither submission nor source selection confirms a project; review and confirmation remain separate. An unresolved upload response must preserve source bytes and its retained-file attempt identity. Only a confirmed failed attempt starts fresh on retry; an active attempt cannot appear as a finished review. Replaying accepted discovery must not start another model call.

• Start one project from available evidence

  Local pilot · D87

  Name one project, choose files, one project page, or memory, then show the relevant input and one explicit action. Keep the privacy boundary before file or project-page submission. Validate a project URL before creating the project; if extraction fails after creation, say the private project still exists and offer pasted page content or questions without creating a duplicate.

  A selected source is not confirmed evidence. The signed-in /new route retains its existing project creation, file upload, URL extraction, and recovery navigation; the fictional fixture stops before server actions. Career Import handles multi-project documents separately. This local presentation pilot does not validate actual upload, extraction accuracy, or project persistence.

• Task before introduction

  Established direction · D33–D34, D47–D48, D58, D60, D65

  On action-focused screens, prioritize the question, input, and next action. Identify the project once in a compact orientation row with its status. Place the remaining-task count beside the question category. Spend generous padding around the task instead of a duplicate title or large introductory headline. When the user defers a question, remove the unused empty field and keep clear resume and return actions beside the still-open task.

  Supporting evidence stays accessible alongside the task on desktop and after it in a keyboard-operable disclosure on mobile. Do not hide essential consent or safety information. Counts must reflect the actual task state; this local example has one configured question, not a completeness assessment. The compact deferred composition is reviewed in D60 Figma screens; D65 begins adoption in the real saved-project view; local saved-project navigation has been observed, while wider state coverage remains open.

• Return with context

  Local pilot · D25, D30–D31, D58–D60, D63, D65

  Carry the same person, project identity, next question, and selected theme from a list into its workspace. Connected screens read and update one shared theme preference. Return to that project expanded; after an answer is added or kept, replace the stale question with a review action. Preserve exact wording and whether it is unfinished, deferred, or explicitly kept when the user reopens the task. Name whole-project status separately from the status of a specific evidence question.

  State the persistence scope. If tab storage fails, leave exact wording visible, warn that it may be lost on refresh or navigation, and provide a safe copy/retry path. The local review and recovery examples retain text only in the same tab and origin; kept recollection does not silently confirm evidence, increase recovered-area coverage, or complete a project. D59–D60 Figma views specify the presentation, but do not implement clipboard, retry, or product behavior. D65 validates the Library return query against owned projects and restores expansion; bounded authenticated acceptance is recorded with the shipped reskin; broader state coverage remains separate.

• Generous padding, shared anchors

  Established direction · D20–D22, D27, D57

  Align expanded titles, body labels, and supporting notices to the same inner left edge. Balance the trailing arrow against the right edge. Keep related columns top-aligned. On wide Library panels, align the supporting tag row and primary action on a shared footer anchor that adapts to the taller content column.

  The Library uses 32/28/24px responsive insets and a 200ms reveal. The persistent workspace content also enters once on mount with that existing 200ms reveal: a small upward settle, no blur or delayed controls. Ordinary task updates do not replay the shell entrance. These values are contextual, not a universal control padding. Stack naturally on mobile and remove motion when reduced motion is requested.

• Outcome or next step

  Established direction · D14, D19, D26, D32

  A completed project leads with its strongest supported takeaway. An unfinished project leads with the next useful action or question. Keep remaining-task counts compact and secondary to the question, without a separate display-number block. Preserve generous content padding. Show coverage before status while unfinished; omit the redundant completed count.

  A takeaway can be qualitative. Never manufacture a metric or treat Story recovered as confirmation of every claim.

• Metadata stays separate from actions

  Established direction · D15–D18

  Place quiet, icon-free Featured metadata beside the project title. Use a distinct status indicator for recovery state and one primary action for the next step.

  Featured describes collection placement; it is not a button, completion state, or evidence endorsement. Keep its management action separate from the indicator and disclosure arrow.

• Measured outcome with context

  Local pilot · D28

  Use OutcomeComparison when a supported baseline and achieved result measure the same thing. Keep units, the explicit change, timeframe, and source alongside the result.

  The component does not calculate or verify the claim. A target is not an achieved result; a project result is not proof of individual causality.

• Story first, sources in context

  Local pilot · D23, D28, D70, D118

  Let the saved story title, subhead, and supported outcome lead before share controls and administrative notices. Keep the narrative readable, with source references near claims and a clearly labeled source trail. Use the approved inline trust treatment for that trail: quiet divider, sans-serif title and guidance, existing source chips, without a nested rounded card or shield. Source chips use neutral metadata colors; their type labels and icons carry meaning without suggesting confirmation. Distinguish individual contribution, team work, and unresolved authority.

  Show restricted-source metadata without its contents. An outcome metric needs a grounded source; do not fill an empty metric strip with an invented result. After local edits, identify source notes as describing the original draft; do not imply new verification. D70 adopts the hierarchy on the real saved-case-study route; the fictional fixture keeps edits in its tab. The inline source trail has desktop/mobile light/dark evidence; wider workflow acceptance remains separate.

• A clear shared-story reader

  Established direction · D70, D75, D76, D77, D79

  Lead with the author and story proposition, followed by role context and supported outcomes. Preserve the owner’s title wording and metric units. Keep a readable narrative column with nearby section navigation and a quiet source summary. Give the story more space than product promotion.

  Omit an empty metric strip; never manufacture a result to fill the layout. Show source counts without exposing private filenames, source text, or certification claims. Private editing controls stay out of the recipient view; any owner-return link must come from the caller. D77 confirms the visual direction and prepares the real shared route to use it. Owner access remains server-controlled. D79 verified the real local reader for its owner and a signed-out visitor, including owner return, related stories, and narrow light/dark rendering. Chrome print pagination and a webpack production build passed in D78. The shared reader is deployed with the coordinated reskin; Figma parity remains separate.

• A collection that leads into the story

  Established direction · D20–D22, D77, D80–D82

  Use the shared public masthead, theme control, reading typography, and quiet footer across a collection and its stories. Give each story one generous linked row with the exact authored title at the shared left anchor, its full subhead beneath, and project, role, organization, and year as quiet trailing context. Keep one consistent directional icon at the right inset; avoid separate topic labels when they add no navigation or decision value.

  The server owns publication eligibility and curated order. Presentation never invents metrics, reading times, biographies, or provenance guarantees. Keep qualifications visible without line clamping. Optional author fields can be absent. Empty means no featured stories in this collection, not no published work anywhere. A collection return remains reachable even when the story has no siblings. Owner edit links still require server authorization. D81 adopts this presentation locally; Christian approved the D82 hierarchy. The collection is deployed with the coordinated reskin; Figma parity remains separate.

• Explicit editing and commitment

  Local pilot · D28, D60, D71, D72, D75

  Reuse the same dialog, uppercase Mono label, and system buttons for draft regeneration; preserve the archive explanation before confirmation. Draft entry uses the quiet task-state layout, without a decorative gradient. Separate reading from editing. Place edit controls beside the content they change and group secondary history and sharing actions in the toolbar menu; avoid duplicating these controls as page-state tabs. Keep editor fields on the reading grid, with visible labels, 44px or taller controls, and explicit Save and Cancel. Header editing uses one bounded form with standard sentence-case field labels, a wrapping title and a short introduction; short section eyebrows and the metrics legend retain Mono. Keep regeneration and the story/source reading view outside active header editing, restoring them after Save or Cancel. Regeneration remains the existing secondary action in reading mode, with its confirmation step. Allow one inline editor at a time; commit fields grouped under one Save together. On narrow screens, stack metric value and description so neither is clipped. Present version history as a dated list; select a revision before offering Restore. Before sharing, show public identity and the publication boundary in one focused review dialog. Restore focus to the invoking control when an editor or dialog closes.

  Saving a draft is not publishing or evidence confirmation. Unchanged public metrics retain their source association; changing a metric clears its old association rather than transferring evidence to a new claim. The D71 fictional fixture saves in its tab only and disables restore/publish. D72 removes same-screen simultaneous edits and combines header fields into one write, and the deployed editor uses guarded writes. Hosted stale-save rejection, retained copy and authenticated saves passed scoped reskin acceptance. D60 establishes the long-answer visual direction in Figma; automatic sizing and clipboard/retry behavior remain open.

• Choices nearby, progression at the end

  Local pilot · D48, D55, D58

  Keep response-mode choices directly beneath the question. For Review and Keep, place the quieter alternative at the start and primary progression at the trailing edge of a task footer. On mobile, stack in the same reading and keyboard order, with enough space to distinguish actions.

  This is a contextual composition, not a blanket right-alignment rule. Voice session controls stay centered near the active conversation. Christian approved the coordinated reskin appearance. This contextual rule does not silently change unrelated screens.

• One question, review, then keep

  Local pilot · D23–D25, D47–D48, D55, D58, D88, D94

  Lead recovery with one contribution question and place the response choice directly beneath it. Keep project identity and progress compact. On mobile, keep the question, answer field, and next action in the first task view; put supporting project context after the task. Let the user talk it through, type, pause, or defer. Review the exact wording before Keep this answer, and return to the same expanded Library project.

  Preserved wording remains user recollection. An answer does not silently complete the story or establish personal ownership. D88 applies the task-first composition to the real quick-question phase locally; D89 covers analysis and source review, and D94 covers narrative, completion, and failure presentation locally. The deployed reskin has bounded lifecycle acceptance recorded separately; these visual specimens do not execute it. The voice route remains a simulated design study; a dictation field in the real quick-question flow is not the immersive voice experience.

• Review source interpretation before questions

  Local pilot · D47–D48, D58, D89–D90, D113

  After analyzing connected sources, retain the shell-owned project breadcrumb and compact privacy label; role, company, year, overall coverage and status stay on the project overview (D113). Do not stack a second breadcrumb, large project title, or repeated review eyebrow ahead of the source details. Show the actual details Osnara found in a readable list with nearby source references. Let the user edit a specific detail or request a follow-up about it, then continue to the open questions. Show an honest reading state without invented progress or premature completion marks.

  Coverage and model confidence are internal diagnostics, not a percentage of a person’s story or proof of ownership. Recovery selects complete original source passages; the app derives saved wording and references from validated source/unit IDs. Model-authored summaries, clipped qualifications and unsupported tradeoff interpretations cannot become recovered detail. Classify against the interview framework’s explicit evidence criteria for each area, not labels alone; research activity is not a finding, and an observed result is not automatically research. Classification remains a proposal until the user reviews it; continuing is not bulk confirmation. An inline edit must report a failed save without dropping the draft. The fictional preview keeps edits local and never analyzes or writes to an account. D89 adopts the rich-brief and sparse-coverage presentations locally; D90 tightens their orientation hierarchy. Bounded analysis and save acceptance is recorded with the shipped reskin; the Priya provider check is scoped evidence, not universal classification accuracy.

• Dictation stays inside the answer

  Local pilot · D24, D47, D93

  Keep dictation as a quiet, optional control inside the existing answer field. Give the answer an accessible name and one visible compound focus ring. Let wrapped typed drafts grow up to the existing field height limit; at narrow widths keep the answer readable above its controls. The shared field owns its outer border and focus ring; keep the inner textarea borderless and do not restyle it through generic page selectors. When recording begins, preserve the editable answer and fixed field geometry; show a compact semantic-green level indicator and a visible Listening status in a separate row. While microphone permission is pending, show the existing disabled pending control with Starting text. Stopping releases the microphone before transcription; disabling or leaving the field cancels pending voice work. Reject stale transcripts. Any error or timeout remains beside the field with typed text intact and retry available. Use the approved Osnara 8px control radius and focus treatment; do not use indigo or a full-width listening panel.

  Dictation adds text to the user’s draft; it does not create a guided voice conversation or confirm evidence. Forms that change steps must wait for active dictation/transcription to finish before advancing; use the field lifecycle notification and keep other microphone controls inactive while one field records. The user can edit and review the transcript before continuing. The immersive voice recovery remains a separate experience. Preview examples must keep microphone access disabled.

• Voice is a guided conversation

  Local pilot · D24, D36, D47–D50, D55; October21 local onboarding adaptation and gated connected pilot

  Entering voice opens a dedicated conversation surface rather than adding a microphone to a text field. Keep the exact question visible through speaking, listening, pause, processing, and review. Give the central voice control a visible label and name every state: ready, assistant speaking, listening, processing, paused, review, kept, or unavailable. Keep pause, interruption, end, and typing controls close to the active state. The conversation is one fixed canvas: the page, stage, and content panel do not scroll, the control dock stays fixed, and the primary session control keeps its position. Use compact state-specific content to fit the canvas and move focus without scrolling the page.

  Speaking is not evidence confirmation, project completion, or permission to save. The local study does not request microphone access, record audio, transcribe, speak, or write to an account. Explicit Keep retains only the reviewed text in the existing same-tab local draft; storage failure stays on the review screen. Motion describes the simulated state and has a reduced-motion equivalent; production motion must follow actual audio/session state.