A feature is a scope over shared records
A feature view filters the same product specification. It does not create a second model or copy a service into a separate artifact. If checkout and refunds use the same database, that database keeps its canonical identity in both feature scopes.
The author lists each feature in the file and references the relevant entities, relationships, views, requirements and evidence. This makes the feature catalog portable with the .ospec. The website does not hardcode the capabilities of your product.
Try a complete feature journey
Open Meridian Commerce and choose Feature → Checkout. Follow the available layers: Architecture for components, Behavior for steps and alternatives, Interactions for messages, Data for records, and Specification for obligations.
Ask what starts checkout, where an accepted intent becomes durable and how stock and payment outcomes relate to that intent. Select the objects and relationships involved. When the file contains the relevant detail, the same identities connect these different explanations.
Let filtering reduce the reading work
The selected feature scopes the canvas, navigation, outline, search, artifacts and table neighborhoods. This removes irrelevant material from the current investigation while preserving the full file. Choose Whole product when you need to widen the context again.
Feature arrangements are kept separately from the whole-product arrangement. You can organize a focused explanation without rearranging the broader architecture. Back, Forward and the route retain feature context as you explore.
Ask your agent for useful feature boundaries
Name observable capabilities rather than arbitrary folders: submitting an order, recovering a failed delivery, approving an agent action or synchronizing an offline device. Ask the agent to start from real entrypoints and trace the components and contracts that make each capability work.
Shared infrastructure may belong in several scopes. The author should include relevant endpoints for each relationship and explain gaps instead of linking to missing records. Validation checks references and scope consistency; it cannot prove that every dependency was discovered.
Use feature views before making a change
For a proposed checkout change, inspect the affected API, transaction, tables, events and requirements together. Identify where an error would be visible and which recovery behavior must remain intact. Then use the broader architecture to check dependencies outside the feature’s authored scope.
A feature scope is a presentation filter, not an access-control boundary or an exhaustive impact analyzer. Export still saves the full specification. For a deeper schema investigation, continue with table neighborhoods and exact column relationships.
Explore a fictional example, or open your own .ospec file locally.
Open 1view →