Sinaris Product Design
Sinaris is a local-first control layer for AI coding agents. It turns project intent, design decisions, task ownership, execution evidence, and delivery confidence into durable state that humans and agents can share.
1. Product Positioning
AI coding agents are already strong at local implementation. They can inspect code, edit files, run tests, and explain changes. The hard part is not asking an agent to write another patch. The hard part is keeping real project work aligned across interruptions, multiple sessions, changing requirements, and human decisions.
Sinaris solves that coordination problem.
It is not a replacement for Cursor, Copilot, Claude Code, or other coding agents. It is the project control layer around them:
- Guide and Proposal make intent explicit.
- Design turns intent into executable work.
- Apply lets agents claim and complete one task at a time.
- Activity makes handoffs and decisions traceable.
- Evaluator tracks release confidence beyond task completion.
- Hub gives humans a live view of the project state.
2. Product Philosophy
Sinaris follows an AI-native product philosophy:
Product code provides facts, tools, state, and invariants. Agents make workflow decisions through SKILLs.
This means Sinaris should not hard-code every step an agent must take. It should expose enough structured state for the agent to decide correctly:
- what work exists;
- which work is claimable;
- what context justifies the work;
- which session owns the task;
- what user decision has arrived;
- whether assets or workspace state need maintenance;
- what evidence is required to complete the task.
The system says what happened. The SKILL says what to do next.
3. Users And Jobs
| User | Job |
|---|---|
| Solo developer | Keep an AI-built feature moving across interrupted sessions without restating context. |
| Tech lead | See what is planned, what is blocked, who owns the current task, and whether the design remains coherent. |
| Maintainer | Turn a change request into scoped work, then let agents execute safely against known boundaries. |
| Product builder | Preserve product intent and acceptance criteria while implementation moves quickly. |
The common need is shared state. Sinaris makes the project memory external to any one chat.
4. Core Product Objects
| Object | Product meaning |
|---|---|
| Project context | Confirmed goal, users, value, scope, decisions, open questions, and milestone roadmap. |
| Proposal | One concrete demand in an existing project, with recommendation and context impact. |
| Milestone | A durable product/resource boundary that can come from Guide or from a proposal. |
| Phase design | The design for a slice of work, including acceptance criteria, risks, ownership, and Apply readiness. |
| Task | A claimable unit of implementation work under a phase. |
| Agent session | A recorded host-agent session that can own work, receive events, and be resumed. |
| AgentEvent | A structured fact sent to an agent, such as assignment, continuation, decision resume, or queue availability. |
| Evaluator journey | A user-facing journey or acceptance concern used to judge release confidence. |
| Workspace | A local project root with Sinaris state, generated assets, and a registry entry. |
5. Workflow
Guide
Use Guide when the project is new or the direction is unclear.
Guide uses an ICOD-style loop: identify one important question, present context and options, ask for a decision, and record confirmed facts. The result is not a chat summary. It is the project basis that later stages can rely on.
Proposal
Use Proposal when an existing project receives a concrete new requirement, change, or idea.
Proposal avoids rewriting the whole project charter. It shapes one demand, records the recommendation, and identifies whether the project context must change before work can continue.
Design
Design turns confirmed direction into phase-level work.
The design must be sufficient for Apply to execute without inventing missing architecture or product decisions. When the design is unclear, the correct behavior is to continue the design conversation, not to push ambiguity into implementation.
Apply
Apply is the execution loop.
The agent claims one task, reads the task packet and phase context, implements within scope, verifies the result, and completes or fails with evidence. If a real decision is needed, it requests a decision instead of guessing.
Evaluator
Evaluator tracks whether product-level journeys still support shipping.
Task completion proves local work moved. It does not automatically prove the product is safe to release. Evaluator closes that gap by making important journeys explicit and reviewable.
6. Hub Surfaces
The Hub is the human control surface. It is not a second implementation of business rules.
| Surface | What it answers |
|---|---|
| Plans | What goals, proposals, milestones, and phase designs define the work? |
| Board | What can be claimed, what is owned, and what is blocked? |
| Activity | What happened, what decision is needed, and what event was sent to which agent? |
| Agents | Which sessions exist, what are they doing, can they resume, and do they have queued messages? |
| Evaluator | Which journeys matter, which runs are current, and what confidence remains? |
| Workspaces | Which local projects are registered and which need asset upgrades? |
Hub operations call application services. The UI does not reimplement readiness, claimability, ownership, or dispatch rules in JavaScript.
7. Agent Interaction Model
Sinaris interacts with agents through three channels:
- Generated assets: commands, SKILLs, hooks, and host instructions installed by
sinaris init. - Structured CLI/API contracts: JSON output, stable error envelopes, and
meta schemafor command discovery. - Structured events:
AgentEventpayloads rendered as JSON for assignment, continuation, decision resume, auto-claim wake-up, and user messages.
This model is intentional. Natural-language prompts are useful, but they are not a reliable product protocol. Sinaris uses structured facts whenever the agent needs to act on product state.
8. Continuation And Auto-Claim
Continuation is based on recorded sessions.
Sinaris can resume a known host-agent session with a structured event or resume context. It should not create replacement sessions when the contract is to continue a recorded one.
Auto-claim is also AI-native:
- product code detects that an offline, auto-claim-enabled session has claimable work;
- Sinaris records and sends a
queue.auto_claim_availableevent; - the Apply SKILL decides whether to claim and how to proceed.
The product provides the signal. The agent owns the workflow decision.
9. Workspace Asset Maintenance
Sinaris relies on generated assets because the host agent needs local instructions and commands.
Users interact with this through simple product rules:
- run
sinaris initto install assets; - run
sinaris init --forcewhen an explicit overwrite/upgrade is required; - Hub shows whether a workspace is current, missing assets, modified, unsupported, or upgradeable;
- upgrade status follows the public Sinaris tool version, not long build metadata strings.
This keeps asset maintenance understandable for non-.NET users and stable for agents.
10. Product Boundaries
Sinaris should do:
- provide durable project memory;
- make task readiness and ownership explicit;
- expose structured state to agents;
- preserve human decisions and evidence;
- resume recorded sessions when there is a valid reason;
- display runtime state and delivery confidence.
Sinaris should not do:
- replace coding agents;
- author business prose in product code;
- infer product truth from raw transcripts;
- wake agents when work is certainly unavailable;
- duplicate SKILL policy inside application services;
- let host agent Plan or Build Plan modes bypass Sinaris workflow gates.
11. Success Criteria
Sinaris is working when:
- a new agent session can understand the project without reading old chat history;
- a human can see what is planned, in progress, blocked, or ready from the Hub;
- a task cannot be claimed outside the current readiness and ownership rules;
- decisions and continuations are visible as structured activity;
- implementation evidence is recorded where it belongs;
- a tool upgrade clearly tells the user when workspace assets should be refreshed.