System Requirements Document for astra

1. Introduction

astra (developed under the working name Genos) is an AI mobile application that acts as a highly capable, voice-first digital assistant for the device it runs on. The product intent, derived from the authoritative requirement thread, is to deliver an assistant that is:

• Conversational — it chats and messages with the user like a chatbot, comparable to Gemini.
• Voice-controllable from inside the app — the user speaks commands and astra controls the device.
• Fully device-controlling — the user can grant astra full control of the device so it acts on their behalf.
• Voice-typing — astra types messages from the user's voice, under the user's control.
• Generative — astra generates photos when needed, generates files, and creates custom files.
• A builder — astra creates mobile apps and desktop applications.
• Gesture- and voice-activatable — astra controls other apps by gestures or voice activation.
• A default digital assistant — astra is intended to be usable as the default digital assistant app in device settings on any device.
• Camera-aware — astra has camera access to scan questions.

The audience is power users and early adopters who want an assistant that feels like a tool with agency rather than a chatbot toy. Because astra carries the weight of full device control, the product must signal precision and permission, not chaos.

This document is the single source of truth for the current delivery of astra. It preserves every accepted capability, constraint, and persona from the authoritative thread and the Planning Scope contract.

2. System Overview

astra is a mobile-first AI assistant application with a companion backend that brokers AI inference, artifact generation, and device-action orchestration. The current delivery includes:

• Anonymous public entry (Landing) that explains astra and its capabilities before identity establishment.
• Identity access (Login) supporting both self-service enrollment and returning verification on one cohesive surface.
• Protected assistant workflows (Chat, Voice Control, Device Control, Dictation, Photo Generation, File Creation, App Builder, App Control, Camera Scanner, Assistant Setup), each reachable only after identity is established.

Actors. The accepted active-human catalog is closed and consists of exactly two personas: Device User and Voice/Message Author. All other participants (AI inference providers, image-generation providers, the device operating system, and the app backend) are typed non-persona actors.

Ownership. All twelve pages are application-owned custom pages. The Landing and Login surfaces are anonymously reachable; every other page requires login. Device-level actions (voice control of the device, app control, camera capture, default-assistant registration) are executed through the device operating system under permissions and authority the user grants; astra owns the interaction, the OS owns the enforcement.

Narrow exclusions. astra does not add adjacent account-management capabilities (password reset flows, social login, profile editing) beyond the self-service enrollment and returning verification required to make the accepted journeys executable. astra does not add pages, personas, or capabilities beyond the closed page and persona contracts.

2a. Product Interpretation and Delivery Boundary

astra is delivered as a first-party mobile application with an application-owned identity layer. The user establishes identity once (self-service enrollment) and verifies it on return; that identity binds durable assistant state — conversations, generated artifacts, dictation history, and device-control authority — to the correct person.

Access ownership. The Landing page is anonymously reachable and owns the first impression. The Login page is anonymously reachable and owns both enrollment and returning verification; it is the only entry point to protected state. Every protected page requires login. No protected destination owns the interaction that establishes access to itself.

Device and provider ownership. Voice capture, gesture recognition, camera capture, and app control are performed through the device operating system's permission model. astra requests and records the user's grant of authority; the OS enforces it. AI inference, image generation, and file/app artifact generation are performed by backend services that astra calls; astra owns the request, the observable result, and the recovery path.

Current vs. future. Everything described in this document is current delivery. No future-horizon capabilities are asserted in the authoritative thread; any capability not listed here is out of scope for this generation.

2b. Source Content Inventory

No reference directive in this request declares content_source authority. This section is intentionally omitted.

2c. Page Content and Component Coverage

The page inventory below is the closed, ordered page contract. Each page appears exactly once.

Landing

• Information/state: Product name ASTRA as an oversized kinetic headline; a single line of body copy describing astra as a voice-first AI assistant that can control the device, generate photos and files, build apps, and scan questions with the camera; a live "listening ring" demo (desktop) or a static ring (mobile); a persistent top bar with the wordmark left and a status dot right.
• Primary action: Enter astra (routes to Login).
• Supporting actions: None beyond the primary CTA.
• Domain entities: None persisted; presentation-only.
• Component responsibilities: Kinetic headline (staggered per-word reveal); cursor-reactive 1px grid background (disabled under reduced motion); listening-ring demo; primary CTA button (1px acid-lime border, transparent fill).
• States: Loading — headline and grid render immediately, no data fetch. Empty — not applicable. Success — CTA routes to Login. Error — not applicable (no network dependency). Recovery — not applicable.

Login

• Information/state: Two modes on one cohesive surface — Enroll (first use) and Verify (returning). Fields: email/identifier and passphrase. Mode toggle. Inline validation messages.
• Primary action: Enroll (first use) or Verify (returning).
• Supporting actions: Switch between Enroll and Verify modes.
• Domain entities: Account (identifier, credential), Session.
• Component responsibilities: Mode toggle; credential form; submit control; inline error region; loading indicator on submit.
• States: Loading — submit control shows progress, form disabled. Empty — blank fields with placeholder guidance. Success — routes to Chat. Error — invalid credentials, duplicate enrollment, or network failure shown inline with a retry path. Recovery — user corrects input and resubmits; no state is lost.

Chat

• Information/state: Scrollable conversation transcript with the user's messages and astra's replies; timestamps; a persistent top bar with wordmark and status dot; a fixed bottom composer with a dominant circular voice button.
• Primary action: Send a message (typed or dictated) and receive astra's reply.
• Supporting actions: Start voice input (expands composer into a full-width waveform); open Camera Scanner; open Photo Generation; open File Creation; open App Builder.
• Domain entities: Conversation, Message (role, content, timestamp), Attachment reference.
• Component responsibilities: Transcript list; message bubbles (graphite surface, 8px radius); composer; circular voice button; waveform canvas; attachment chips.
• States: Loading — transcript skeleton while history loads; composer disabled during send. Empty — first-use prompt inviting the user to speak or type. Success — reply appended to transcript. Error — failed send shown with a retry affordance; failed reply shown with a retry affordance. Recovery — retry resends the same message without duplicating it in the transcript.

Voice Control

• Information/state: Listening ring (240px, 2px acid-lime ring, pulsing at 1.4s ease-in-out); live voice transcript; recent command log; status of microphone permission.
• Primary action: Speak a command to control the device.
• Supporting actions: Stop listening (vermilion interrupt control); re-issue a command; open Device Control to adjust authority.
• Domain entities: VoiceCommand (transcript, timestamp, outcome), DeviceAction.
• Component responsibilities: Listening ring; waveform canvas; live transcript region; command log; stop control.
• States: Loading — permission check on entry. Empty — no commands yet, ring idle. Success — command transcript shown and action dispatched. Error — microphone permission denied or command unrecognized, shown with a path to grant permission or retry. Recovery — user grants permission or re-speaks; log records the failed attempt.

Device Control

• Information/state: Current authority state (granted / not granted / revoked); scope description of "full control"; a live ticker log of recent device actions; permission status per capability (voice, gestures, camera, app control).
• Primary action: Grant full device control to astra.
• Supporting actions: Revoke authority (vermilion destructive control); review recent actions; open Assistant Setup.
• Domain entities: AuthorityGrant (scope, granted_at, revoked_at), DeviceAction (action, target, timestamp, outcome).
• Component responsibilities: Authority status panel; grant control; revoke control; live action ticker (200ms slide-in, fades to muted grey after 10s); permission list.
• States: Loading — authority state fetched on entry. Empty — no authority granted yet; ticker empty. Success — authority granted, ticker begins recording. Error — grant failed or OS denied, shown with retry. Recovery — user retries grant or adjusts OS permissions.

Dictation

• Information/state: Live dictated text region; listening ring; controls to start, pause, and stop dictation; a control to insert the dictated text into the target message.
• Primary action: Speak and have astra type the message.
• Supporting actions: Pause/resume dictation; discard dictated text; insert into composer.
• Domain entities: DictationSession (transcript, started_at, ended_at), DictatedText.
• Component responsibilities: Listening ring; live transcript region; start/pause/stop controls; insert control; discard control.
• States: Loading — microphone permission check. Empty — no dictation yet. Success — dictated text shown and insertable. Error — permission denied or recognition failure, shown with retry. Recovery — user re-speaks or grants permission; partial text is preserved.

Photo Generation

• Information/state: Prompt input; gallery of previously generated photos; generation status indicator.
• Primary action: Request a generated photo from a prompt.
• Supporting actions: Re-run a prompt; open a generated photo; save or share a generated photo.
• Domain entities: PhotoRequest (prompt, created_at), GeneratedPhoto (image reference, prompt, created_at).
• Component responsibilities: Prompt input; generate control; gallery grid; status indicator; per-photo actions.
• States: Loading — generation in progress with a progress indicator. Empty — no photos yet, prompt guidance shown. Success — photo appears in the gallery. Error — generation failed, shown with retry. Recovery — user retries the same prompt; prior photos remain.

File Creation

• Information/state: Prompt/description input for the file; file type selector; list of previously created files; preview of the selected file.
• Primary action: Generate a file from a description.
• Supporting actions: Customize the file (edit the description or type before generating); open a created file; save or share a created file.
• Domain entities: FileRequest (description, file_type, created_at), CreatedFile (name, type, content reference, created_at).
• Component responsibilities: Description input; file-type selector; generate control; file list; preview pane; per-file actions.
• States: Loading — generation in progress. Empty — no files yet, guidance shown. Success — file appears in the list and preview. Error — generation failed, shown with retry. Recovery — user edits the description and regenerates; prior files remain.

App Builder

• Information/state: Project type selector (mobile application / desktop application); description input; list of previously created projects; project detail view with generated artifacts.
• Primary action: Request creation of a mobile app or desktop application.
• Supporting actions: Choose project type; open a created project; save or export project artifacts.
• Domain entities: AppProject (name, type, description, created_at), ProjectArtifact (file reference, created_at).
• Component responsibilities: Project-type selector; description input; create control; project list; project detail view; artifact list.
• States: Loading — creation in progress. Empty — no projects yet, guidance shown. Success — project appears in the list with artifacts. Error — creation failed, shown with retry. Recovery — user edits the description and retries; prior projects remain.

App Control

• Information/state: List of controllable apps on the device; current activation mode (gesture / voice); recent control actions log.
• Primary action: Activate and control another app by gesture or voice.
• Supporting actions: Switch activation mode; open Device Control to adjust authority; review recent control actions.
• Domain entities: ControllableApp (name, package), ControlAction (app, mode, timestamp, outcome).
• Component responsibilities: App list; activation-mode toggle; control log; permission status.
• States: Loading — app list and permission status fetched. Empty — no controllable apps detected. Success — control action dispatched and logged. Error — permission denied or app not controllable, shown with retry. Recovery — user grants permission or selects another app.

Camera Scanner

• Information/state: Live camera viewfinder; capture control; captured-image preview; submission status; scanned-question result.
• Primary action: Capture a question with the camera and submit it to astra.
• Supporting actions: Retake the capture; submit the capture; open Chat to continue the conversation.
• Domain entities: ScanCapture (image reference, captured_at), ScannedQuestion (text, source capture).
• Component responsibilities: Viewfinder; capture control; preview; submit control; result region.
• States: Loading — camera permission check on entry. Empty — viewfinder active, no capture yet. Success — captured image submitted and astra's answer shown. Error — camera permission denied or submission failed, shown with retry. Recovery — user grants permission or retakes the capture.

Assistant Setup

• Information/state: Current default-assistant status; step-by-step guidance for setting astra as the default digital assistant in device settings; deep-link control to the OS settings screen.
• Primary action: Set astra as the default digital assistant.
• Supporting actions: Open OS settings; re-check status; open Device Control to review authority.
• Domain entities: AssistantRegistration (status, set_at).
• Component responsibilities: Status panel; step guidance; open-settings control; re-check control.
• States: Loading — status check on entry. Empty — not yet set as default. Success — astra confirmed as default. Error — OS rejected or step incomplete, shown with guidance. Recovery — user follows the guidance again and re-checks.

3. Functional Requirements

Each requirement is a distinct story point with provenance, lifecycle facts, and observable acceptance.

FR-1 — Conversational chat with astra (explicit) As a Device User, I should chat and message with astra like a chatbot, comparable to Gemini, so that I can get answers and assistance conversationally.

• Trigger/input: User opens Chat and sends a message (typed or dictated).
• Observable result: astra's reply appears in the transcript.
• Access state: Login required.
• Failure/recovery: Failed send or reply shows a retry affordance; retry does not duplicate the message.
• Continuation: User continues the conversation or opens another capability.

FR-2 — In-app voice control of the device (explicit) As a Device User, I should control the device using voice control from inside the app, so that I can operate the device hands-free.

• Trigger/input: User opens Voice Control and speaks a command.
• Observable result: The command transcript is shown and the device action is dispatched.
• Access state: Login required; microphone permission required.
• Failure/recovery: Permission denied or unrecognized command shows a path to grant permission or retry.
• Continuation: User issues another command or opens Device Control.

FR-3 — Grant full device control (explicit) As a Device User, I should grant astra full control of the device, so that it can carry out actions on my behalf.

• Trigger/input: User opens Device Control and grants authority.
• Observable result: Authority state shows granted; the action ticker begins recording.
• Access state: Login required; OS permission required.
• Failure/recovery: Grant failure or OS denial shows a retry path.
• Continuation: User reviews recent actions or revokes authority.

FR-4 — Voice-driven typing (explicit) As a Voice/Message Author, I should speak and have astra type the message for me, under my control, so that I can compose text without manual typing.

• Trigger/input: User opens Dictation and speaks.
• Observable result: Dictated text appears in the live transcript region and can be inserted into the target message.
• Access state: Login required; microphone permission required.
• Failure/recovery: Permission denied or recognition failure shows a retry; partial text is preserved.
• Continuation: User inserts the text, continues dictating, or discards it.

FR-5 — Photo generation (explicit) As a Device User, I should have astra generate photos when needed, so that I can obtain images on demand.

• Trigger/input: User opens Photo Generation and submits a prompt.
• Observable result: The generated photo appears in the gallery.
• Access state: Login required.
• Failure/recovery: Generation failure shows a retry; prior photos remain.
• Continuation: User opens, saves, or shares the photo, or generates another.

FR-6 — File generation and custom file creation (explicit) As a Device User, I should have astra generate files and create custom files, so that I can obtain documents tailored to my request.

• Trigger/input: User opens File Creation, describes the file, and selects a type.
• Observable result: The created file appears in the list and preview.
• Access state: Login required.
• Failure/recovery: Generation failure shows a retry; prior files remain.
• Continuation: User opens, saves, or shares the file, or customizes and regenerates.

FR-7 — Mobile app and desktop application creation (explicit) As a Device User, I should have astra create mobile apps and desktop applications, so that I can obtain working application projects.

• Trigger/input: User opens App Builder, selects project type, and submits a description.
• Observable result: The project appears in the list with generated artifacts.
• Access state: Login required.
• Failure/recovery: Creation failure shows a retry; prior projects remain.
• Continuation: User opens the project, exports artifacts, or creates another.

FR-8 — Gesture- and voice-based app control (explicit) As a Device User, I should have astra control apps by gestures or voice activation, so that I can operate other apps through astra.

• Trigger/input: User opens App Control, selects an app, and uses gesture or voice activation.
• Observable result: The control action is dispatched and logged.
• Access state: Login required; OS permission required.
• Failure/recovery: Permission denied or app not controllable shows a retry.
• Continuation: User controls another app or switches activation mode.

FR-9 — Default digital assistant (explicit) As a Device User, I should be able to make astra the default digital assistant app in device settings on any device, so that astra is the assistant the device invokes.

• Trigger/input: User opens Assistant Setup and follows the guidance to set astra as default.
• Observable result: astra is confirmed as the default digital assistant.
• Access state: Login required; OS settings interaction required.
• Failure/recovery: OS rejection or incomplete step shows guidance to retry.
• Continuation: User re-checks status or opens Device Control.

FR-10 — Camera question scanning (explicit) As a Device User, I should have astra access the camera to scan questions, so that I can get answers to questions I photograph.

• Trigger/input: User opens Camera Scanner and captures a question.
• Observable result: The captured image is submitted and astra's answer is shown.
• Access state: Login required; camera permission required.
• Failure/recovery: Camera permission denied or submission failure shows a retry.
• Continuation: User retakes the capture or opens Chat to continue.

FR-11 — Self-service enrollment (required_inference) As a Device User, I should complete self-service enrollment before using protected assistant workflows, so that my assistant state is bound to me.

• Trigger/input: User opens Login and chooses Enroll.
• Observable result: An account is created and a session is established.
• Access state: Anonymous entry.
• Failure/recovery: Duplicate enrollment or invalid input shows an inline error with a retry.
• Continuation: User is routed to Chat.

FR-12 — Returning verification (required_inference) As a Device User and Voice/Message Author, I should complete returning verification to resume protected conversations, artifacts, dictation, and device-control workflows, so that my durable state is restored to me.

• Trigger/input: User opens Login and chooses Verify.
• Observable result: A session is established and prior state is available.
• Access state: Anonymous entry.
• Failure/recovery: Invalid credentials or network failure shows an inline error with a retry.
• Continuation: User is routed to Chat.

FR-13 — Grant device permissions and control authority (required_inference) As a Device User, I should grant applicable device permissions and control authority before astra can perform device actions, voice-driven typing, app control, or camera scanning, so that astra can act on my behalf.

• Trigger/input: User is prompted for microphone, camera, gesture, and control permissions.
• Observable result: Permission status is recorded and the corresponding capability becomes usable.
• Access state: Login required.
• Failure/recovery: Denial shows a path to grant permission or retry.
• Continuation: User proceeds with the capability or adjusts permissions.

FR-14 — Operating-system default-assistant configuration (required_inference) As a Device User, I should complete the operating-system configuration required to set astra as the default digital assistant, so that the device invokes astra as its assistant.

• Trigger/input: User opens Assistant Setup and follows the OS configuration steps.
• Observable result: The OS registers astra as the default assistant.
• Access state: Login required.
• Failure/recovery: Incomplete configuration shows guidance to retry.
• Continuation: User re-checks status.

4. User Personas

Device User

Product context. The Device User is the person who installs astra as their default digital assistant and interacts with it by voice, gestures, or typed chat. They are the primary actor across nearly every page.

Primary goal. To have a single assistant that hears them, watches their gestures, and acts on the device — answering questions, generating photos and files, building apps, and controlling other apps — without leaving the app.

Distinct accepted responsibilities. The Device User:

• Chats with astra conversationally (FR-1).
• Controls the device by voice from inside the app (FR-2).
• Grants astra full device control (FR-3).
• Requests generated photos (FR-5).
• Requests generated and custom files (FR-6).
• Requests mobile app and desktop application creation (FR-7).
• Controls other apps by gesture or voice (FR-8).
• Sets astra as the default digital assistant (FR-9).
• Scans questions with the camera (FR-10).
• Completes self-service enrollment (FR-11) and returning verification (FR-12).
• Grants device permissions and control authority (FR-13).
• Completes OS default-assistant configuration (FR-14).

Relevant inputs or decisions. Voice commands, gesture inputs, typed messages, generation prompts, project descriptions, camera captures, permission grants, and authority grants/revocations.

Interactions with other accepted participants. The Device User interacts with the Voice/Message Author persona when dictation is used to compose messages, and with the device operating system and backend AI services as non-persona actors.

Observable success. astra responds to voice and gestures, executes device actions, produces requested photos, files, and app projects, answers scanned questions, and is registered as the device's default assistant.

Voice/Message Author

Product context. The Voice/Message Author is the user dictating content inside the app. They speak and have astra type the message for them, controlling the voice-driven text entry.

Primary goal. To produce accurate dictated text under their own control, rather than by manual typing.

Distinct accepted responsibilities. The Voice/Message Author:

• Dictates messages and has astra type them (FR-4).
• Completes returning verification to resume dictation and protected workflows (FR-12).

Relevant inputs or decisions. Spoken content, start/pause/stop decisions, and the decision to insert or discard dictated text.

Interactions with other accepted participants. The Voice/Message Author interacts with the Device User persona when the dictated text is inserted into a conversation, and with the device operating system as a non-persona actor for microphone access.

Observable success. Dictated text appears accurately in the live transcript region and can be inserted into the target message under the author's control.

5. Core User Flows

Flow 1 — Device User: First use and enrollment

1. The Device User opens astra and lands on Landing, which shows the ASTRA headline, a one-line description of astra's capabilities, and the primary CTA.
2. The Device User selects the primary CTA and is routed to Login.
3. On Login, the Device User chooses Enroll, enters an identifier and passphrase, and submits.
4. astra creates the account and establishes a session; the Device User is routed to Chat.
5. Failure/recovery: If enrollment fails (duplicate identifier or invalid input), an inline error is shown and the Device User corrects the input and resubmits.

Flow 2 — Device User: Returning verification

1. The Device User opens astra and is routed to Login.
2. The Device User chooses Verify, enters credentials, and submits.
3. astra establishes a session and restores prior conversations, artifacts, and authority state; the Device User is routed to Chat.
4. Failure/recovery: Invalid credentials or network failure shows an inline error; the Device User retries.

Flow 3 — Device User: Conversational chat

1. From Chat, the Device User types or dictates a message and sends it.
2. astra's reply appears in the transcript.
3. The Device User continues the conversation or opens another capability (Camera Scanner, Photo Generation, File Creation, App Builder).
4. Failure/recovery: A failed send or reply shows a retry affordance; retry does not duplicate the message.

Flow 4 — Device User: Voice control of the device

1. The Device User opens Voice Control; astra checks microphone permission.
2. The Device User speaks a command; the listening ring pulses and the live transcript shows the recognized command.
3. astra dispatches the device action and records it in the command log.
4. The Device User issues another command or opens Device Control to adjust authority.
5. Failure/recovery: If permission is denied or the command is unrecognized, astra shows a path to grant permission or retry; the failed attempt is logged.

Flow 5 — Device User: Granting full device control

1. The Device User opens Device Control and reviews the current authority state and permission list.
2. The Device User grants full device control; the OS permission prompt is presented.
3. astra records the grant; the authority state shows granted and the live action ticker begins recording.
4. The Device User reviews recent actions or revokes authority (vermilion destructive control).
5. Failure/recovery: If the grant fails or the OS denies it, astra shows a retry path.

Flow 6 — Voice/Message Author: Dictation

1. The Voice/Message Author opens Dictation; astra checks microphone permission.
2. The author speaks; the listening ring pulses and the live transcript region shows the dictated text.
3. The author pauses, resumes, or stops dictation.
4. The author inserts the dictated text into the target message or discards it.
5. Failure/recovery: If permission is denied or recognition fails, astra shows a retry; partial text is preserved.

Flow 7 — Device User: Photo generation

1. The Device User opens Photo Generation and enters a prompt.
2. The Device User submits the prompt; a progress indicator is shown.
3. The generated photo appears in the gallery.
4. The Device User opens, saves, or shares the photo, or generates another.
5. Failure/recovery: If generation fails, astra shows a retry; prior photos remain.

Flow 8 — Device User: File generation and custom file creation

1. The Device User opens File Creation, describes the file, and selects a file type.
2. The Device User submits the request; a progress indicator is shown.
3. The created file appears in the list and preview.
4. The Device User opens, saves, or shares the file, or customizes the description and regenerates.
5. Failure/recovery: If generation fails, astra shows a retry; prior files remain.

Flow 9 — Device User: Mobile app and desktop application creation

1. The Device User opens App Builder, selects a project type (mobile application or desktop application), and submits a description.
2. A progress indicator is shown while astra creates the project.
3. The project appears in the list with generated artifacts.
4. The Device User opens the project, exports artifacts, or creates another.
5. Failure/recovery: If creation fails, astra shows a retry; prior projects remain.

Flow 10 — Device User: Gesture- and voice-based app control

1. The Device User opens App Control and reviews the list of controllable apps and the current activation mode.
2. The Device User selects an app and uses gesture or voice activation.
3. astra dispatches the control action and logs it.
4. The Device User controls another app or switches activation mode.
5. Failure/recovery: If permission is denied or the app is not controllable, astra shows a retry.

Flow 11 — Device User: Camera question scanning

1. The Device User opens Camera Scanner; astra checks camera permission.
2. The Device User captures a question with the camera; the captured image is previewed.
3. The Device User submits the capture; astra's answer is shown.
4. The Device User retakes the capture or opens Chat to continue the conversation.
5. Failure/recovery: If camera permission is denied or submission fails, astra shows a retry.

Flow 12 — Device User: Setting astra as the default digital assistant

1. The Device User opens Assistant Setup and reviews the current default-assistant status.
2. The Device User follows the step-by-step guidance and opens the OS settings screen via the deep-link control.
3. The Device User completes the OS configuration; astra is registered as the default digital assistant.
4. The Device User re-checks status or opens Device Control to review authority.
5. Failure/recovery: If the OS rejects the configuration or a step is incomplete, astra shows guidance to retry.

6. Visuals Colors and Theme

The CREATIVE DIRECTION is authoritative for this section. The muse is Yugo Nakamura; the headline concept is "Interaction as intelligence — a living instrument you speak into."

Color tokens (dark mode):

No gradients, no glass, no blue.

Typography:

• Headings: Space Grotesk at 600–700 weight, letter-spacing -0.02em. Display sizes: 56px mobile, 80px tablet, 128px desktop (clamp with viewport).
• Body: Inter Tight at 15px mobile, 16px tablet, 17px desktop; normal weight; 1.55 line-height.
• Micro-labels: Space Grotesk 500 at 11px, uppercase, tracking 0.12em.
• Scale: 1.333 modular — 56/40/28/20/16/13/11.

Shape language: Flat, crisp, slightly mechanical. 4px radius on controls, 8px on panels. Never pill-shaped, never soft. The listening indicator is a perfect circle with a 2px ring that pulses in scale and opacity. Buttons are rectangular with a 1px border and a solid fill on press. No blobs, no organic curves, no drop shadows except a single 1px hairline on elevated panels. Everything aligns to a visible 8px grid.

Layout: Full-viewport, single-column mobile-first composition. The landing hero is a full-bleed dark field with an oversized kinetic headline occupying the top 60% of the viewport and the primary CTA pinned to the bottom safe area. On desktop (1280px), the hero becomes a 12-column grid: headline spans columns 1–8, and a live listening-ring demo sits in columns 9–12, vertically centered. The chat screen uses a fixed bottom composer with the voice input as the dominant control. Voice Control and Device Control use a two-column layout on desktop: left column is the status/control panel, right column is a live log of recent actions. All pages use a persistent top bar with the wordmark left and a status dot right.

Imagery: The interface is the imagery — no photography, no illustration, no 3D renders. Visual interest comes from generative, procedural elements: the voice waveform, the listening ring, the device-control log as a live ticker, and a subtle animated grid in the landing hero background. Icons are 1.5px stroke, geometric, monochrome.

7. Signature Design Concept

The public entry (Landing) is a full-bleed near-black field (#0B0B0C) with a 1px line grid that subtly shifts by 2px with cursor movement. The dominant element is the headline ASTRA set in Space Grotesk 700 at 128px on desktop (56px mobile), left-aligned, spanning columns 1–8. Below it, a single line of body copy in Inter Tight at 17px, max-width 480px, describing astra as a voice-first assistant that controls the device, generates photos and files, builds apps, and scans questions. The primary CTA is a rectangular button with a 1px acid-lime (#E8FF47) border and transparent fill, pinned to the bottom-left of the hero on desktop and to the bottom safe area on mobile. To the right (desktop only), a live listening-ring demo — a 240px circle with a pulsing 2px lime ring — sits in columns 9–12, vertically centered. The composition is asymmetric, editorial, and unmistakably not a SaaS hero: no centered headline, no gradient blob, no blue button.

The concept recomposes only accepted content and controls: the headline, the descriptive line, the CTA, and the listening-ring affordance that astra uses across Voice Control and Dictation.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: expressive Hero Dimensionality: layered_2d

Landing Hero Motion Brief

• Focal subject: The ASTRA kinetic headline and the live listening-ring demo.
• Input → transformation → outcome thesis: Cursor movement over the hero shifts the 1px background grid by 2px, and the listening ring pulses continuously at 1.4s ease-in-out — the interface visibly responds to the user's presence, communicating that astra hears and reacts, without introducing any behavior beyond the accepted voice-activation affordance.
• Motion vocabulary: Staggered per-word headline reveal (opacity + 12px translateY, 200ms each, 40ms stagger); continuous 1.4s ease-in-out ring pulse; 120ms hover background/text swap on desktop; 80ms scale-to-0.97 on mobile tap; 240ms crossfade with 16px slide on page transitions. No bounce, no elastic, no spring.
• Composed first frame: Near-black field with the static 1px grid, the ASTRA headline at full opacity, the descriptive line, the bottom-pinned CTA, and the listening ring at its resting scale — a complete, readable composition before any motion begins.
• Reduced-motion state: The grid becomes static, the headline appears without stagger, and the listening ring renders as a static 2px lime circle. All content remains fully readable and the CTA remains operable.

9. Non-Functional Requirements

• NFR-1 — Mobile-first delivery (explicit): astra is an AI mobile app; the primary experience is a mobile-first, single-column composition that scales to tablet and desktop viewports.
• NFR-2 — Device permission enforcement (explicit): Voice control, gesture control, camera access, and app control depend on device operating-system permissions; astra must surface permission state and provide a recovery path when permission is denied.
• NFR-3 — Full device control authority (explicit): astra must record and display the user's grant of full device control, and must provide a revoke control.
• NFR-4 — Durable assistant state (required_inference): Conversations, generated artifacts, dictation history, and authority state must persist across sessions and be restored on returning verification.
• NFR-5 — Identity continuity (required_inference): Protected workflows must be bound to the correct authenticated user; the Login surface must support both enrollment and returning verification.
• NFR-6 — Readable text and controls at all viewports (explicit, from creative direction): Headlines, wordmarks, labels, numbers, and card text and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (e.g., font-size: clamp(...)) to fit; no other element may cover any part of them.
• NFR-7 — Reduced-motion support (explicit, from creative direction): Under prefers-reduced-motion, the cursor-reactive grid becomes static, the headline appears without stagger, and the listening ring renders as a static circle; all content remains readable and operable.
• NFR-8 — No generic SaaS template (explicit, from creative direction): The generic indigo/blue-on-white SaaS template is forbidden; the palette, typography, and shape language defined in Section 6 are binding.

10. Tech Stack

• Mobile client: React Native (mobile-first, with responsive layouts scaling to tablet and desktop viewports).
• Backend: Python / FastAPI, extending a single shared backend process for AI inference brokering, artifact generation, and device-action orchestration.
• Storage: Persistent storage for accounts, sessions, conversations, generated artifacts (photos, files, app projects), dictation history, and authority state.
• Containerization: Docker / docker-compose for the backend service.
• AI services: Backend integration with AI inference, image-generation, and file/app artifact generation providers, invoked by astra on the user's behalf.

No additional services, containers, or ingress routes are introduced beyond what the accepted workflows require.

11. Assumptions and Constraints

Assumptions:

• [Assumption — required_inference] The device operating system exposes permission prompts and a default-assistant registration mechanism that astra can invoke; astra owns the interaction and the OS owns enforcement.
• [Assumption — required_inference] AI inference, image generation, and file/app artifact generation are performed by backend services that astra calls; astra owns the request, the observable result, and the recovery path.
• [Assumption — required_inference] A single cohesive Login surface supports both self-service enrollment and returning verification, as specified by the page contract.

Constraints:

• Genos is an AI mobile app. (explicit)
• Voice control of the device happens from inside the app. (explicit)
• Device control is granted by the user to the AI and is described as full control. (explicit)
• Voice-driven typing is controlled by the user of the AI. (explicit)
• Genos is intended to be usable as the default digital assistant app in the settings on any device. (explicit)
• Genos requires access to the camera to scan questions. (explicit)
• The closed persona catalog is exactly Device User and Voice/Message Author; no additional personas are created. (required_inference)
• The closed page contract is exactly the twelve pages listed in Section 2c; no pages are added, removed, merged, split, renamed, or reordered. (required_inference)
• No adjacent account-management capabilities (password reset, social login, profile editing) are added beyond self-service enrollment and returning verification. (required_inference)

12. Glossary

• astra — The AI mobile assistant application described in this document (developed under the working name Genos).
• Device User — The accepted persona who installs astra as their default digital assistant and interacts with it by voice, gestures, or typed chat.
• Voice/Message Author — The accepted persona who dictates content inside the app and has astra type the message under their control.
• Listening ring — The 240px circular affordance with a 2px acid-lime ring that pulses at 1.4s ease-in-out, used as the primary voice-activation control.
• Voice waveform — The full-width canvas that reacts to real input amplitude, expanding from the circular voice button when active.
• Device control authority — The user's grant of full control to astra, recorded and revocable on the Device Control page.
• Default digital assistant — The device operating-system role that astra can be registered as, configured through Assistant Setup.
• Artifact — A generated output of astra: a photo, a file, or a mobile/desktop application project.
• Dictation — The voice-driven typing capability owned by the Dictation page, controlled by the Voice/Message Author.
• Scan capture — A camera image of a question, captured on the Camera Scanner page and submitted to astra.