Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/paramveer-cyber/Deployaar/llms.txt

Use this file to discover all available pages before exploring further.

The pipeline is the core of Deployaar. Every feature you submit travels through seven sequential steps — from a single line of plain English to a reviewed, mergeable GitHub pull request. Each step has a defined input, a processing stage driven by AI or sandboxed code execution, and a clear output that becomes the input for the next step. No step is skipped, and every transition is tracked as a status change on the feature request record.

​
The Seven Steps

1

Intake

A user submits a feature request through the dashboard at dashboard/feature-requests. Before the request enters the pipeline, the clarification service performs an AI-powered gate check. The AI compares the incoming request against recent feature request titles in the same project to detect near-duplicates and reject “education” style questions (e.g., “how do I add a button in React”). Only genuine, novel feature requests proceed. Rejected requests are returned immediately with an explanation.Input: Plain-English request title and description
Output: Validated feature request record in clarifying status
2

Spec (PRD Generation)

Once a request passes the intake gate, packages/services/prd expands it into a full, structured Product Requirements Document. The AI is given the original feature request plus any clarification conversation that followed, and is instructed to write for engineers who will implement the feature. The PRD is broken into seven concrete sections using structured output extraction.PRD sections generated:
  • Problem Statement — clear articulation of the problem being solved
  • Goals — measurable, bulleted list of what this feature achieves
  • Non-Goals — explicit list of what this feature will not do
  • User Stories — in As a [user], I want [goal] so that [reason] format
  • Acceptance Criteria — concrete, testable criteria for “done”
  • Edge Cases — error states and failure modes to handle
  • Success Metrics — how success is measured after shipping
Input: Validated feature request + clarification thread
Output: Persisted PRD record; feature request moves to prd_pending
3

Tasking

After the PRD is approved, packages/services/feature-task sends the full PRD context to an AI acting as a senior engineering lead. The AI breaks the PRD into between 5 and 20 ordered, implementation-ready engineering tasks. Tasks are verb-first (e.g., “Implement X”), ordered from infrastructure and data layer work through to UI, and stored with a position field so the coding agent can execute them in sequence.This step is triggered automatically by the prd/approved Inngest event via the on-prd-approved workflow function.Input: Approved PRD with all seven sections
Output: Ordered list of engineering tasks in backlog status
4

Agent Execution

This is the core of Deployaar. packages/services/coding-agent provisions an E2B sandbox, clones the linked GitHub repository into /home/user/repo, builds a repository index for orientation, and launches an autonomous AI agent. The agent is given the full clarification thread, PRD, and ordered task list as its system prompt, and runs a generateText loop with three tools at its disposal.The agent reasons about task dependencies, implements each task in order, and runs a single TypeScript verification pass (pnpm exec tsc --noEmit) after completing all tasks. When all tasks are done the agent emits a <task_summary> XML block, which acts as the termination signal.Every tool call is wrapped in step?.run() for Inngest checkpointing, so agent work survives worker restarts mid-task. Sandbox state is also persisted: if a run is interrupted, the sandbox is reconnected by ID rather than re-cloned.
The agent loop is bounded at MAX_ITERATIONS = 40 steps via stopWhen: [isStepCount(40)]. If the agent reaches this limit without emitting a <task_summary>, the run is marked failed and the sandbox is killed. This prevents runaway execution and runaway AI SDK costs.
Input: Ordered engineering tasks, cloned repo, PRD context
Output: All changed files written to the E2B sandbox, ready to push
5

Ship

Once the agent loop completes, the coding agent service uses packages/services/github (Octokit + GitHub App) to push the modified files to a feature branch named deployaar_<featureRequestId> and open a pull request against the repository’s default branch. The PR title is prefixed [Deployaar] and the body contains the agent’s <task_summary> content plus a ShipFlow-Feature tracking tag.Input: Modified files in sandbox, feature branch name
Output: Open GitHub pull request with prNumber recorded on the agent run
6

Review

When GitHub delivers the pull request webhook, Deployaar’s on-pull-request-received Inngest function fires. It validates that the PR branch matches the deployaar_<uuid> pattern, fetches the review context (diff, file contents, PR metadata) at the project’s configured depth, and calls packages/services/pull-request-review to run an AI code review.Review depth is configured per-project and controls how many import hops of context are gathered:
DepthImport hopsDescription
shallow0Diff only — no additional context files fetched
depth_11Diff plus files directly imported by changed files
depth_22Diff plus two levels of import context
depth_33Full import-graph context — deepest cross-file analysis
The review produces a verdict (passed or needs_work), a summary, and a list of categorised issues with severity levels (critical, major, minor, suggestion).Input: Pull request diff, head SHA, review depth
Output: Review record with verdict and issue list; feature request moves to in_review
7

Merge

A human team member reviews the AI’s code review findings, resolves any blocking issues, and approves the pull request. Depending on the organisation’s settings, merge may be manual or triggered by an auto-merge policy. Once merged, the feature request lifecycle is marked complete (shipped).Input: Approved pull request on GitHub
Output: Code merged to default branch; feature request status → shipped

​
Feature Request Lifecycle States

Every feature request carries a status field that transitions through the pipeline. The full set of states, sourced from packages/database/models/enums.ts, is:
StatusMeaning
clarifyingRequest has been submitted and is awaiting clarification Q&A
prd_pendingClarification is complete; PRD generation has been triggered or is underway
planningPRD has been approved; task generation is pending
in_developmentEngineering tasks have been generated and/or the coding agent is running
in_reviewA pull request has been opened and AI review is underway or complete
fix_neededReview returned needs_work; issues must be resolved before re-review
approvedPull request has been approved by a human reviewer
shippedPR has been merged; feature is complete
rejectedFeature request was rejected at intake or at a later stage
State transitions are enforced in the service layer. Attempting to advance a feature request out of sequence (e.g., approving a PRD that hasn’t been generated) returns a 400 Bad Request.

​
Clarification Gate

Before a feature request enters PRD generation, the clarification service (packages/services/clarification) runs an AI-powered review of the request. The service acts as a senior product manager and uses a two-phase approach:
  1. Question generation — the AI examines the feature title, description, and the existing clarification thread, then asks the single most important clarifying question it needs answered to write a high-quality PRD. If it already has enough information, it returns null for the question.
  2. Reply loop — the user answers the question through the dashboard. The AI can ask follow-up questions. When the thread is sufficiently complete, the user calls completeClarification, which transitions the status to prd_pending and fires the feature-request/clarification.complete Inngest event to kick off PRD generation.
The gate catches two categories of problematic requests:
  • Near-duplicates — AI compares the new title against recent titles in the same project
  • Education questions — requests phrased as “how do I…” rather than “add this feature to my product”

​
Agent Tools

The coding agent has exactly three tools. All tool handlers are implemented in packages/services/coding-agent/index.ts using the Vercel AI SDK tool() helper with Zod input schemas.
ToolInputDescription
terminalcommand: stringRuns a shell command inside /home/user/repo in the E2B sandbox. Returns combined stdout and stderr. Used for git operations, pnpm add, and the TypeScript verification command.
readFilespaths: string[]Reads one or more file contents from the sandbox, relative to /home/user/repo. Returns an array of { path, content } objects. Missing files return a [File not found] marker.
createOrUpdateFilesfiles: Array<{ path: string; content: string }>Writes or overwrites files in the sandbox. Paths are relative to /home/user/repo. Used by the agent to implement code changes.
For a deeper look at how the coding agent reasons about task order, handles TypeScript errors, and signals completion, see the Coding Agent deep dive.

Build docs developers (and LLMs) love

Get started for freeTalk to us