# Agent Nova — Client Status Update **Date:** 8 September 2026 **Project:** Agent Nova — Jira-triggered, human-supervised Salesforce development automation **Overall status:** Phases 0–4 complete. The supervised pipeline runs end-to-end from a Jira story to a **draft GitHub pull request**. Nothing deploys to production. --- ## Headline Agent Nova can now take a qualifying Jira story, analyze it, pause for human answers if needed, produce an allowlisted Salesforce design, wait for human design approval, generate metadata, validate it against a **sandbox / lower org** (dry-run), run code review and QA, and open a **draft PR**. Humans remain in the loop at two gates: **clarification** and **design review**. Profiles, sharing-model changes, destructive deletes, and production deploys are out of autonomous scope. --- ## What this means for you | You do | The platform does | |--------|-------------------| | Label a Story/Task `agent-nova` (or move it to “Ready for Agent”) | Starts a run; ignores unrelated tickets | | Answer questions on the Jira ticket if the story is incomplete | Resumes analysis from your comment | | Review the Confluence design page and comment to approve (or `reject`) | Implements only the approved, allowlisted plan | | Review the draft PR | Code review + QA have already run; the PR is draft, not merged | --- ## Pipeline (as built) ``` Jira webhook → Requirement Analyst → (if unclear) pause → human comment → resume → Solution Architect → Confluence design page → pause for DESIGN REVIEW → human approve / reject → Salesforce Developer (SFDX under force-app) → Sandbox deploy validate (dry-run; production aliases refused) → Code Reviewer + static analysis (auto-fix up to 3 cycles) → QA Engineer (acceptance-criteria matrix + Apex tests) → Draft GitHub PR → PR_CREATED ``` A failed deploy, unfixable review, or failed QA comments on Jira and marks the run **FAILED**. No pull request is opened. --- ## Everything completed so far ### 1. Platform foundation - API (FastAPI) for Jira webhooks and run status, plus a background worker. - Orchestrator that moves each ticket through explicit workflow states, with an audit trail. - Postgres + Redis (Docker Compose) for runs, artifacts, and the job queue. - Idempotent webhooks (duplicate Jira deliveries are ignored). - Trigger rules: configured project keys only; Story/Task; one active run per issue. - All live systems are **switchable**: mock for local/CI, live via environment settings. Secrets are not stored in the repository. ### 2. Requirement Analyst - Reads the Jira issue (summary, description, acceptance criteria, comments). - Pulls relevant Confluence pages (naming, architecture standards) as context. - If the story is implementable, proceeds. If not, posts numbered questions and pauses. - Does not invent acceptance criteria. Prefers reasonable defaults over questions about layouts, record types, or naming style. - If a human has already answered on the ticket, those answers are treated as locked decisions. - Live clarification was exercised on Jira issue **AN-6** (thin description → questions posted → human-style reply → design produced). ### 3. Solution Architect and design review - Produces a Salesforce metadata plan (`design.json`) from the approved requirements. - Enforces the v1 allowlist: out-of-policy types and destructive actions are stripped; empty plans fail. - Pauses in **DESIGN_REVIEW**. A Jira comment starting with `reject` / `rejected` fails the run; any other human comment **approves** and starts implementation. - At design review, Agent Nova **creates a Confluence page** (requirements + design) and posts the URL on the Jira ticket. - Jira comments are formatted for readability (headings, lists, bold labels, clickable links). ### 4. Salesforce Developer Generates SFDX stubs under `force-app` for allowlisted types only: | Generated in v1 | Not autonomous (escalate) | |-----------------|---------------------------| | Custom fields | Profiles | | Validation rules | Sharing rules / OWD redesign | | Permission sets | Connected apps / auth providers | | Apex classes and triggers | Destructive deletes | | Record-triggered Flows | Production deployment | | Lightning Web Components | | After a failed code review, the developer can apply an LLM-driven fix pass (bounded — see below). ### 5. GitHub and Salesforce validate - Creates branch `agent-nova/`. - Commits only Salesforce metadata (`force-app`); internal summaries stay in run artifacts. - Opens a **draft** pull request (mock GitHub for CI; live GitHub API when configured). - Runs `sf project deploy start --dry-run` against a named **sandbox / DEV** org. Results are stored as `deploy.json`. - Production-like org aliases (`prod`, `production`) are refused. - Deploy failure → run fails, Jira is commented, **no PR**. ### 6. Code Reviewer and QA (Phase 4) - Static analysis (PMD CLI or mock) merged into review findings. - Code review against requirements, design, and analysis (security, bulkification, naming, test coverage, design drift). - **Blocking severities:** critical and high. Medium/low are informational. - Failed review with fixable findings → automatic fix loop, **maximum 3 cycles**. - QA builds a test matrix from acceptance criteria and Apex test results. - Metadata-only changes (fields/rules/permission sets) are not failed solely because no Apex tests ran. - Review or QA failure blocks the draft PR. ### 7. Quality and robustness (September) - Webhook comments after approve are ignored so a second Jira event cannot overwrite a successful run. - LLM outputs that use `High` vs `high` (or `Positive` vs `positive`) are normalized so runs do not crash. - 53 automated tests passing (verified 8 Sep 2026). --- ## Human control (unchanged principles) 1. **Start only when you say so** — label or status, not every ticket. 2. **Clarification gate** — incomplete stories do not proceed. 3. **Design-review gate** — no metadata is written until a human approves the plan. 4. **Allowlist** — the agent cannot quietly expand into sharing, profiles, or deletes. 5. **Lower org only** — validate is dry-run; production is out of scope. 6. **Draft PR** — merge remains a human decision. --- ## Integration status | System | What is built | Default for CI | Live switch | |--------|----------------|----------------|-------------| | Jira | Intake, comments, resume | Mock | `JIRA_PROVIDER=http` | | Confluence | Search + design-page publish | Mock | `CONFLUENCE_PROVIDER=http` | | GitHub | Branch, commit, draft PR | Mock | `GIT_PROVIDER=github` | | Salesforce deploy | Sandbox dry-run validate | Mock | `SALESFORCE_PROVIDER=cli` | | Apex tests | `sf apex run test` | Mock | `APEX_TEST_PROVIDER=cli` | | PMD | Violations into review | Mock | `STATIC_ANALYSIS_PROVIDER=pmd` | | LLM | Analyze / design / review / fix / QA | Mock | `LLM_PROVIDER=openai` | Live GitHub and sandbox smoke on a **client** story is implemented in code but not yet run jointly — it needs your credentials (see below). --- ## Timeline | Date | Milestone | |------|-----------| | 21 Aug 2026 | Platform scaffold (API, worker, database, orchestrator) | | Phase 0 | Trigger rules, metadata allowlist, access checklist | | 24 Aug | Clarification flow (live Jira AN-6), OpenAI wiring, Solution Architect | | 25 Aug | Design-review human gate + allowlist enforcement | | 26 Aug | Developer stubs + mock PR; live Confluence search | | 27 Aug | Live GitHub draft PRs; sandbox deploy validate; Apex / Flow / LWC stubs | | 31 Aug – 2 Sep | Code Reviewer, QA, PMD, Apex tests, review/fix loop | | 4 Sep | Webhook hardening, analyst guardrails, QA metadata-only handling | | 7 Sep | Confluence design-doc publisher; formatted Jira comments | --- ## Not in this release (planned next) These do **not** block a supervised demo of the current pipeline. 1. **Human review after max auto-fix cycles** — today the run fails after 3 review cycles; next we will pause for a human approve/reject instead. 2. **Configurable review threshold** — option to also block on medium-severity findings. 3. **Richer Apex / Flow / LWC** — beyond stubs, including real Apex test class generation. 4. **Client PMD / Code Analyzer ruleset.** 5. **CI pipeline** (GitHub Actions) for the Agent Nova service. 6. **Optional non-dry-run apply** to a lower org (still never production). 7. **Joint live smoke** on your GitHub repo + sandbox once credentials are available. --- ## What we need from you to go live on real tickets | Item | Why | |------|-----| | Jira project key(s), webhook URL/secret, bot account, “Ready for Agent” status (if used) | Start and resume runs on real issues | | Confluence space keys + API token | Retrieve standards and publish design pages | | GitHub SFDX repo URL + token (`contents` + `pull_requests` write) | Real branches and draft PRs | | Sandbox / DEV org with Salesforce CLI auth — **no production credentials** | Deploy validate and Apex tests | | LLM API key (OpenAI or agreed provider) | Live analyst / architect / reviewer quality | --- ## Suggested demo (30–40 minutes) 1. Create a Story with label `agent-nova` (clear field + validation-rule example). 2. If the bot asks questions, reply on the ticket. 3. Open the Confluence design page; comment on Jira to approve. 4. Confirm artifacts: `requirements.json`, `design.json`, `deploy.json`, `review.json`, `qa-report.json`. 5. Open the draft PR. Confirm the target org was a sandbox and the PR is draft. A second story with an incomplete description can show the clarification pause. --- ## Bottom line **The supervised Salesforce automation loop is built and tested.** Remaining work is hardening (review escalation, richer generation, CI) and a live run against your Jira, Confluence, GitHub, and sandbox — not a new core pipeline. We are ready to walk through a demo and, once credentials are in place, execute the first live client story.