1.1
A general app reference is not enough
A request cannot rely only on the name, link, screenshot, or general idea of another app. If a reference app is provided, the request must state which parts of that reference apply, which parts do not apply, and how the requested app should differ. A reference such as "make it like Airbnb" or "copy this CRM" is ambiguous unless the request names the exact screens, interactions, navigation model, data shown, and design traits that should be used.
1.2
Navigation must be explicit
The request must describe how users move through the product. It should identify the first screen, primary navigation, secondary navigation, back behavior, modal or sheet behavior, empty-state destinations, and where each main action leads. If multiple reference screens show different navigation patterns, the request must state which pattern is authoritative.
1.3
Screens must be individually defined
Each requested screen must have a clear name and purpose. The request must describe what the screen shows, what the user can do there, what data appears there, and which states matter. A list of features is not enough when those features imply multiple screens or states.
1.4
Design references must identify the source of truth
When screenshots, Figma frames, brand files, previous app screens, and written design notes conflict, the request must identify which source wins. If no source of truth is named, OfficeOS cannot decide whether to follow the screenshot, the written note, the current app, or a new design direction.
1.5
Design contradictions must be resolved before work starts
A request is ambiguous if one screen suggests one visual system and another screen suggests a conflicting system without explaining the intended relationship. Examples include different button styles, different spacing systems, incompatible typography, conflicting color palettes, or one screen using card-based layout while another requires edge-to-edge layout. The request must either reconcile the differences or state that one screen is the canonical design reference.
1.6
Component behavior must be stated, not inferred
Interactive components must define their behavior. This includes dropdowns, filters, search, tabs, tables, drag-and-drop, pagination, uploads, notifications, destructive actions, disabled states, loading states, validation, and error handling. If a component is visible in a reference image but its behavior is not described, OfficeOS cannot infer the expected behavior from appearance alone.
1.7
Data requirements must be clear enough to build UI states
The request must identify the data needed by each screen or workflow. It should state which fields exist, which fields are required, which values can be empty, which values can repeat, and which values change after an action. If the request asks for dashboards, lists, profiles, forms, reports, or histories without defining the underlying data, the request is incomplete.
1.8
User roles and permissions must be identified
If different users see different screens, actions, or data, the request must define those user groups and their permissions. It is ambiguous to request an admin flow, customer flow, staff flow, or owner flow without stating what each role can view, create, update, delete, approve, export, or configure.
1.9
Important edge cases must be named
The request must describe any edge cases that affect implementation quality. This includes empty states, first-run states, offline or slow-network states, permission-denied states, invalid input, duplicate records, long names, missing images, partial integrations, failed payments, canceled actions, and users returning to an unfinished flow.
1.10
Acceptance criteria must be observable
Acceptance criteria must describe behavior that can be checked. Criteria such as "make it premium", "make it intuitive", "improve UX", or "make it look like the reference" are not sufficient unless they are tied to concrete screens, states, interactions, or outputs.
1.11
Priorities must be stated when scope is broad
If a request includes more work than can be treated as one clear change, it must state what is required for the first version and what can be deferred. Without priority, OfficeOS cannot decide whether to build the full flow, a narrow version, a visual prototype, or only the highest-risk part first.
1.12
Existing product behavior must be distinguished from new behavior
When changing an existing app, the request must state what should remain unchanged and what should change. If screenshots or descriptions include existing behavior, the request must clarify whether that behavior is a reference, a constraint, or something to replace.
1.13
External dependencies must be named where they affect the request
If the request depends on an API, database, analytics event, payment provider, auth provider, file storage system, or third-party dashboard, it must identify that dependency and the information needed from it. A screen that depends on external data is ambiguous when the source, fields, refresh behavior, or failure behavior are not defined.
1.14
Written instructions override assumptions only when they are specific
OfficeOS will not treat vague written instructions as a replacement for missing detail. A statement such as "use our usual layout" or "same as before" must point to a specific screen, file, document, or existing behavior. Otherwise it cannot be used as a reliable instruction.