Draft report · October 2026

Software factories: what exists, what is missing

AI tools can write code, tests and design documents. Maintaining software for years also requires knowing what it should do, whether the delivered code does it, and which records need updating when something changes. This report compares how current products support that work. The reviewed evidence does not establish one product that covers the whole process.

An AI agent is software that uses an AI model to carry out a task, such as changing code and running tests. The picture shows four ways to use it. First, a person gives instructions one step at a time. Second, an agent completes a prepared task. Third, an agent repeats its work until it passes a check. Fourth, a software factory coordinates specialised agents that divide, build and verify work, potentially for hours or days. This report examines what that coordinated process must retain and check so the resulting software can be maintained and audited.

• 1. What a software factory has to do
• 2. What exists today
• 3. How they compare
• 4. Detailed product assessments
• 5. Method and limits
• Conclusions
• Appendix: research material

1. What a software factory has to do

An enterprise needs documentation that can be maintained for years, stays aligned with the system, and supports an evidence trail from the delivered code back to its requirements. Seven properties make those needs concrete. This comparison ends with the delivered build. Deployment and operation are outside its scope.

For example, an approved transfer design may include a reversal flow that is not implemented yet. The complete target design should include that flow and mark its implementation state. The current delivered build must still identify the earlier design version it implements. Proposed alternatives remain distinguishable from both.

For each capability, distinguish what is available, what triggers it, what a failure prevents, and how findings are resolved. Structural scripts, executable behaviour tests, AI reviews and human decisions supply different evidence. A configured workflow can meet a criterion; fixed workflows receive no preference.

Process portability requires continued execution without the original hosted factory service. A local client or worker, exported files, or a server edition of only the non-agentic core does not pass that prerequisite. An unresolved essential dependency is marked ?, rather than given partial credit. A deployable licensed runtime can qualify; changing workflow engines is not required. Model inference, repository hosts and CI integrations are listed separately so readers can see what else must remain available.

2. What exists today

The table groups the reviewed products by their main role in software delivery, showing what each group provides and where additional tools or processes are needed.

Issue-to-PR agents

These take a ticket and open a pull request. A person reviews and merges it; GitHub Copilot coding agent cannot approve or merge its own pull request. Azure Boards can hand a work item to Copilot, which opens a linked draft pull request; a person starts it, the code must be on GitHub, and there is no design step. Vendor documentation: Azure Boards and Copilot ↗

Spec workflows

Kiro writes requirements, design and tasks per feature, and those files stay behind as history. Spec Kit has a constitution and per-feature specs, with a documented living-spec option. OpenSpec keeps current specs per capability and merges each change into them. BMAD keeps a PRD, UX, architecture and specs current through its own workflows. Tessl links each spec to its code files and tests. Checks may be invoked directly or connected to supported automation. Their scope, tracking of findings and blocking enforcement must be assessed separately.

Requirements tools

Jama Connect and Siemens Polarion keep multi-level requirements, designs, risks and tests with a defined traceability model, baselines, suspect links, coverage reports and electronic signatures. Azure DevOps links work items and test cases, rolls automated test results up to requirements, and links work items to commits, builds and releases. Azure Boards can send a work item to GitHub Copilot, which writes code and opens a linked draft pull request. That handoff has no dedicated design stage. Jama and Polarion connect to development tools through integrations.

Atlassian suite

Confluence holds PRDs and decision pages, Jira holds the work, and Rovo Dev writes code from Jira items and reviews pull requests against Jira acceptance criteria. That review is an AI judgment. Test management comes from marketplace apps. Page and issue links do not establish a maintained requirement-to-design-to-code-to-test model. The reviewed sources do not establish a complete tracked reconciliation flow across those layers. Atlassian is retiring standalone Rovo Dev and moving its features into Jira. Vendor page: Rovo Dev licensing ↗

Agent orchestration

Factory.ai Missions split a goal into features and milestones and run workers with validation. Factory’s Software Factory dashboard is in private preview. Augment Cosmos describes a living spec but documents no mechanism that keeps it current. Vercel’s internal factory for its AI SDK reports 25 to 35% of weekly merged pull requests, and a person merges every one. Vendor article: Vercel ↗, Vendor page: Augment Cosmos ↗

3. How they compare

The table compares eleven product configurations against the seven criteria above. Select a product name for its chapter, or a rating for the supporting explanation and sources.

Ratings describe documented support, not percentages. ? Unverified means evidence is insufficient. Not supported requires a documented restriction. Whether checks start automatically and whether failures block delivery are described separately. No overall product scores are calculated.

Corrections to a rating: contact@softwarefactoryreport.com

More filled bars mean broader documented support. Limited covers part of a criterion; Substantial covers most of it with a specific gap; Complete meets its full definition. Three pale bars mean Not supported, based on an established restriction. ? Unverified means the evidence is insufficient. These categories are not percentages. The definitions for each criterion explain what separates the categories.

• Jama and Polarion provide controlled versioned records and traceability. Suspect flags concern changed relationships, not semantic agreement with implementation. Executable verification and delivered-build/design-version associations must be assessed separately.
• Azure DevOps can associate executed automated tests with requirements and builds. Its reviewed Boards–Copilot handoff has no dedicated design level. Build/test links alone do not identify a complete governing design baseline.
• Persistent BMAD/Tessl documents and OpenSpec’s merged capability specs earn partial documentation coverage under the stricter definition. BMAD’s optional Test Architect (TEA) coverage matrix is distinct from passed implementation-test evidence.
• The reviewed Kiro documentation explicitly describes generating property-based tests from acceptance criteria.
• Azure–Copilot requires Azure DevOps Services and GitHub; Atlassian’s Rovo workflow requires an activated Cloud site. The server-hostable core products do not make those complete bundles portable. Kiro and Tessl retain unresolved service dependencies. Factory documents a portable airgapped Droid runtime, but the complete connected QA configuration remains unverified.
• Executable specifications such as Cucumber can test required behaviour: a failing scenario is an observed mismatch to investigate. They do not by themselves identify the correct design resolution or track its completion across the full document hierarchy. Source repository: Cucumber ↗

4. Detailed product assessments

Select a product below to open its detailed assessment on the companion page. Each assessment describes how the product works and what records it keeps. The eleven rated products also have explanations and sources for their ratings, including how checks start, whether failures block delivery, how findings are resolved and which services or product editions are required. Additional products retain the earlier survey notes without new ratings.

Evidence reviewed through October 23, 2026. The latest audit examined all 77 ratings across eleven products. These are documentation findings, not product trials.

5. Method and limits

• Research ran in October 2026 with two separate AI research runs on different models, each instructed to prefer official documentation, repositories and changelogs, and to mark marketing-only claims as such.
• A third run fact-checked 17 specific claims against official sources. Five were corrected, including the ADR finding and the Azure Boards → Copilot link.
• Later Luna Max and Muse XHigh follow-ups examined portability, check triggers, enforcement, edition limits and the tightened seven definitions. They supplement the original survey. BMAD’s optional TEA coverage workflow and Tessl’s newer Verifiers are identified separately from earlier findings.
• The latest Luna Max and Muse XHigh audits reviewed all 77 cells, including bundle compatibility, prerequisites, triggers, enforcement and service dependencies. Their detailed findings and the supervisor’s reconciliation are preserved in the research folder. The report does not treat every raw delegated recommendation as established fact.
• Ratings judge documented behaviour, not hands-on trials. Not supported requires a documented restriction or observed failure. ? Unverified means that the reviewed evidence does not justify a definite rating. Lack of a supporting page is not proof that no configuration or integration can provide the capability.
• Delivery provenance records the delivered version, governing documents and decisions, and references test results. Requirements verification separately assesses executable test evidence for required behaviour. Neither criterion assesses deployment or production operation.
• Limited and Substantial require positive evidence of the behaviour described by that criterion. A related feature, generic AI assistance or generic Git history does not establish that capability. Complete requires the full definition in the named configuration. The categories indicate increasing support, not percentages or an overall vendor ranking.
• Trigger and enforcement are distinct: a check may run automatically yet only advise, or run on demand and block a later step. A general hook or CI integration does not establish a supplied check of specification consistency. Configurable enforcement is described without treating a fixed workflow as better.
• Process portability requires continued execution of the assessed workflow on different supported systems. Data export alone earns no score; a deployable proprietary runtime can qualify. Edition and availability are chapter details, not scored properties.
• Products change fast, and ratings reflect documentation as of October 2026. Tessl’s spec-driven framework research is distinct from its newer generally available Verifiers feature.
• Additional product chapters reuse the saved survey notes. Their coverage varies, so they are not assigned new seven-property ratings without equivalent evidence.

What separates limited, substantial and complete support

These anchors apply to the full definitions in section 1. They describe coverage, not whether a person or an event starts a check. Configuration and manual invocation do not lower a level by themselves. An essential unknown remains ? even when a neighboring component is portable or locally executable.

How to validate the claims in a product trial

The following checks have not been run. Use a small stock-reservation example with one requirement, a complete design baseline, two code revisions and executable tests. Add an approved but unimplemented expiry feature and keep a separate design alternative proposed. Record the exact edition, modules, integrations and model endpoints. Test both successful and failing paths.

For every trial, record who or what started the check, where it ran, what failure prevented, configured bypasses and whether the finding remained tracked to closure. Documentation can establish a supported configuration; these trials would demonstrate that configuration in use.

Conclusions

• Writing documents and code is only part of maintaining software. Readers also need the complete agreed design for a chosen version, test results for the delivered code, and records identifying what was delivered and who approved it.
• The reviewed products cover different parts of that work. AI tools mainly create documents and code. Requirements platforms mainly retain agreed records and the relationships between them. The reviewed sources do not establish one product that supplies the whole process.
• Keeping documents up to date does not by itself provide a complete agreed design for each software version. OpenSpec incorporates change descriptions into current specifications. BMAD and Tessl update documents that remain available after the task. Those mechanisms alone do not establish the complete approved design before coding finishes, or identify which design each delivered version implements.
• A check starting automatically does not mean its failure stops delivery. Teams must configure both when checks run and what a failure prevents. Jama and Polarion can flag relationships between records for review when a linked item changes. That flag alone does not show that the code disagrees with the design.
• Records explaining architecture decisions, such as why a particular system structure was chosen, are rarely linked into the reviewed workflows. Examples include an optional architecture-decision record format for OpenSpec and BMAD’s architecture document.
• When code and documents disagree, someone must decide what to correct, record the action and check the result again. This is the report’s meaning of tracked drift resolution. The code may need fixing, or the intended behaviour may need clarification. Automatically rewriting the documents is not required.

Appendix: research material

This appendix explains the research behind the report. It starts with studies of problems that can arise when AI agents develop software over many steps. The later tables preserve the earlier product surveys and the questions they asked. Those surveys used different criteria from the current comparison. For the current ratings, use sections 1–3 and the linked product assessments. Each finding links to the source cited during research; not every source was checked again for this revision. Products supported only by marketing claims (Warp Factories and an open-source “ai-factory”) are omitted.

A. What studies found about AI coding limits

These studies examine different tasks, models and measures of success. Their figures describe those particular tests. They do not predict the success rate of every AI coding task or establish a ranking of the products in this report.

• Instructions revealed gradually can produce code that follows the intended design less closely. The SLUMP study asked agents to implement designs from twenty machine-learning research papers. It compared giving the design all at once with revealing it through roughly sixty coding requests. The all-at-once version followed the intended design more closely on sixteen of twenty papers for Claude Code and fourteen of twenty for Codex. These counts compare the two ways of giving instructions; they do not mean that those papers were entirely unsuccessful. Research: Source ↗
• Repeated additions can make code harder to extend. SlopCodeBench asked agents to keep extending their own code across twenty programming problems. Complex code became more concentrated in difficult functions in 80% of the recorded development sequences. Redundant or duplicated code increased in 89.8%. No tested agent completed any of the twenty problems through every required stage. The study measured how code changed over successive additions, as well as whether it passed tests. Research: Source ↗
• Giving an AI more material to read does not always improve its work. An agent’s context is the instructions, documents and code available to its model while it works. The Spec Growth Engine paper cites a software-engineering test in which one model’s performance fell from 29% to 3% as the input grew from 32,000 to 256,000 tokens. Tokens are the units of text processed by a model, often words or parts of words. The figures describe that test, rather than a universal limit on useful input. Research: Source ↗
• Proposed code changes are not always accepted. A study of changes intended to improve software performance reported acceptance rates of about 73% for Codex, Claude Code and Jules, 50% for Copilot, 42% for Cursor and 30% for Devin. A pull request is a proposed code change submitted for review. Acceptance of these performance fixes does not establish equivalent results for other tasks or prove that every requirement was met. Research: Source ↗
• A long autonomous run can consume substantial model processing. OpenAI described a Codex experiment that ran for 25 hours, processed about thirteen million tokens and produced about 30,000 lines of code. Line count alone does not establish software quality. OpenAI presented the run as an experiment, not production guidance. Vendor documentation: Source ↗
• Reliability depends on the tools and controls around the AI model. A 314-page research monograph, drawing on 206 reliability records, argues that results also depend on how the agent is run, how it retains task information, how it finds relevant material, what it may change, how work is reviewed and what resources are available. Research: Source ↗
• Long-task measurements and productivity estimates have limits. METR studies how long the tasks are that AI agents can complete. It warns that its measurements for tasks longer than sixteen hours are unreliable. It also cautions that its 2026 productivity findings are unreliable because the people and tasks included are self-selected, which can bias the result. Research: Task-duration measurements ↗, Research: 2026 productivity update ↗
• One company reports useful output from its own software factory. Vercel says its factory contributed 25–35% of merged code-change proposals for its AI SDK, a toolkit for building AI applications. It also contributed over half of the fixes adapted for version 6 from other versions. The number of open issues fell from 1,022 to 844. These are Vercel’s own figures; model-processing cost was not published. Vendor article: Source ↗

B. Organisational responsibilities and approvals

These questions concern how an organisation runs its software delivery process. They are outside this report’s seven scored criteria. Who owns the current documents? Who can approve a changed requirement? Which checks only advise, and which block completion? How are exceptions, history and evidence retained and exported?

The research also considered how agents divide tasks, receive permissions, work in parallel and combine their changes. Cost and reliability figures below describe the studies and products at the time of research. Differences in models and tasks prevent a comparable effectiveness score.

• Approval and retained evidence. Approving a plan, allowing a code change to join the shared codebase and signing an agreed version of a document are different decisions. Jama, Polarion and Modern Requirements control who can review records and retain evidence for audits. Factory.ai and Augment Cosmos record agent activity. Vendor article: Jama and MCP ↗
• Parallel work. Kiro groups tasks according to which must finish before others can start, then runs independent tasks together. Jules supports up to sixty simultaneous tasks on its highest-priced tier. The reviewed sources do not establish that combining independently developed code changes also keeps their specifications consistent. Vendor documentation: Kiro best practices ↗, Source repository: Jules SDK ↗
• Cost and reliability. The research did not establish comparable, reproducible cost and reliability figures across the surveyed products. Factory.ai gives a mission cost heuristic; Cosmos and Antigravity offer spend caps. Vendor documentation: Factory missions planning ↗
• Access limits (suggested by one research run). Isolated execution environments, restricted access to credentials and lists of permitted tools limit what a factory may read or change. Vercel, Factory.ai, Cosmos and Devin document these controls; most specification tools do not.

C. Change specs and living documentation, per product

A change specification describes one proposed change. Living documentation is updated to describe the system as it should now work. This earlier survey asked which approach each product supports and what happens to the documents after a change is finished.

D. Artifact hierarchy, per product

An artifact is a retained item such as a requirement, design document, code file or test. This survey asked which kinds each product keeps, how they relate to one another and how changes move between them.

E. First survey run: six properties

This survey used the six research questions below. These are the original survey criteria, rather than the seven properties used in the main comparison. Ratings: Yes, Partial, No, Unknown, Claimed only.

• Requirements through design to code and tests: does the workflow carry requirements and constraints through each step?
• Rules for document contents: does it define what each requirement, design and specification must contain?
• Checks run by tools: do scripts check document structure, links and coverage?
• Changes to an existing system: does it handle changed requirements and feed behaviour changes from fixes back into the documents?
• Division of work between tools and AI: does it state which steps use reproducible checks and which need AI judgment?
• Human approval points: where must a person review or approve the work?

F. Second survey run: eight properties

This earlier survey used eight questions. Its table preserves the original shorthand: Y means yes, P partly, C claimed without supporting evidence, N no and U unknown. D1–D8 identify the questions below. These are not the seven criteria used in the current comparison.

1. D1: Delivery steps. Does the workflow connect requirements, design, code and tests?
2. D2: Document guidance. Does it define what the retained documents should contain?
3. D3: Repeatable checks. Do tools check document structure, relationships and consistency using defined rules?
4. D4: Later changes. Does it handle changes to an existing system and keep its documents current?
5. D5: Tools and judgment. Does it distinguish checks performed by scripts from reviews that need AI or human judgment?
6. D6: Approvals and evidence. Does it define who approves work and retain a record of those decisions?
7. D7: Parallel work. Can agents work simultaneously, and how are their changes combined?
8. D8: Long runs. What evidence is available about their cost and reliability?

G. Sources cited by the research runs

Product survey, first run (56)

• Vendor article: https://vercel.com/blog/building-a-software-factory-for-ai-sdk ↗
• Source repository: https://github.com/vercel/ai/pull/18033 ↗
• Vendor documentation: https://docs.augmentcode.com/cosmos/software-factory/overview.md ↗
• Vendor documentation: https://docs.augmentcode.com/cosmos/software-factory/requirements-to-ticket.md ↗
• Vendor documentation: https://docs.augmentcode.com/cosmos/software-factory/ticket-to-pr.md ↗
• Vendor documentation: https://docs.augmentcode.com/cosmos/software-factory/pr-to-merge.md ↗
• Vendor documentation: https://docs.augmentcode.com/cosmos/software-factory/signal-to-ticket.md ↗
• Vendor article: https://github.blog/news-insights/company-news/welcome-home-agents/ ↗
• Vendor documentation: https://kiro.dev/docs/specs/ ↗
• Source repository: https://raw.githubusercontent.com/github/spec-kit/main/README.md ↗
• Vendor documentation: https://docs.gitlab.com/user/duo_agent_platform/ ↗
• Vendor documentation: https://docs.gitlab.com/user/duo_agent_platform/flows/ ↗
• Vendor documentation: https://learn.microsoft.com/en-us/azure/devops/mcp-server/mcp-server-overview?view=azure-devops ↗
• Vendor documentation: https://docs.github.com/en/copilot/concepts/copilot-surfaces/copilot-on-github ↗
• Vendor article: https://github.blog/news-insights/company-news/pick-your-agent-use-claude-and-codex-on-agent-hq/ ↗
• Vendor documentation: https://support.atlassian.com/rovo/docs/use-rovo-dev-cli/ ↗
• Vendor documentation: https://support.atlassian.com/rovo/docs/check-acceptance-criteria-in-a-code-review/ ↗
• Vendor documentation: https://support.atlassian.com/rovo/docs/agent-actions/ ↗
• Vendor documentation: https://support.atlassian.com/compass/docs/what-is-compass/ ↗
• Vendor documentation: https://docs.factory.com/missions/overview.md ↗
• Vendor documentation: https://docs.factory.com/software-factory/overview.md ↗
• Vendor documentation: https://jules.google/docs/review-plan/ ↗
• Vendor documentation: https://jules.google/docs/ ↗
• Vendor documentation: https://antigravity.google/docs/getting-started.md ↗
• Vendor documentation: https://docs.devin.ai/essential-guidelines/sdlc-integration.md ↗
• Vendor documentation: https://docs.tessl.io/overview/readme.md ↗
• Vendor page: https://www.modernrequirements.com/copilot4devops/ ↗
• Vendor documentation: https://learn.microsoft.com/en-us/azure/devops/test/create-test-cases?view=azure-devops ↗
• Vendor documentation: https://support.atlassian.com/rovo/docs/create-and-edit-agents/ ↗
• Vendor documentation: https://docs.devin.ai/work-with-devin/dynamic-workflows.md ↗
• Vendor documentation: https://learn.microsoft.com/en-us/azure/devops/test/track-test-status?view=azure-devops ↗
• Vendor documentation: https://support.atlassian.com/rovo/docs/evaluate-the-performance-of-your-rovo-agent/ ↗
• Vendor documentation: https://kiro.dev/docs/hooks/ ↗
• Vendor documentation: https://docs.factory.com/missions/planning.md ↗
• Vendor documentation: https://docs.tessl.io/codifying-and-enforcing-your-skill-standards/verifiers-overview.md ↗
• Vendor documentation: https://docs.tessl.io/codifying-and-enforcing-your-skill-standards/verify-agent-changes-in-ci.md ↗
• Vendor documentation: https://docs.devin.ai/product-guides/automations.md ↗
• Vendor article: https://github.blog/changelog/2026-07-23-agent-automation-controls-in-github-issues-in-public-preview/ ↗
• Vendor documentation: https://jules.google/docs/running-tasks/ ↗
• Vendor documentation: https://support.atlassian.com/rovo/docs/work-with-rovo-dev-agents/ ↗
• Research: https://arxiv.org/abs/2608.13867 ↗
• Vendor documentation: https://support.atlassian.com/rovo/docs/agents-in-automations/ ↗
• Vendor documentation: https://jules.google/docs/code/ ↗
• Vendor documentation: https://docs.tessl.io/tutorials/setting-up-agentic-code-review.md ↗
• Research: https://metr.org/time-horizons/ ↗
• Research: https://metr.org/blog/2026-02-24-uplift-update/ ↗
• Research: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ ↗
• Source repository: https://github.com/features/copilot/agents ↗
• Vendor page: https://www.atlassian.com/software/rovo-dev ↗
• Vendor documentation: https://support.atlassian.com/rovo/docs/agents/ ↗
• Vendor documentation: https://support.atlassian.com/rovo/docs/rovo-agent-permissions-and-governance/ ↗
• Vendor documentation: https://support.atlassian.com/rovo/docs/work-with-jira-delivery-agent/ ↗
• Vendor documentation: https://support.atlassian.com/rovo/docs/use-rovo-dev-in-the-ide/ ↗
• Vendor documentation: https://support.atlassian.com/rovo/docs/rovo-dev-rollout/ ↗
• Vendor documentation: https://kiro.dev/docs/steering/ ↗
• Vendor documentation: https://docs.factory.com/autonomy-and-safety/specification-mode.md ↗

Product survey, second run (68)

• Vendor documentation: https://kiro.dev/docs/specs/best-practices/ ↗
• Vendor documentation: https://github.github.com/spec-kit/quickstart.html ↗
• Vendor documentation: https://learn.microsoft.com/en-us/azure/devops/release-notes/2026/sprint-268-update ↗
• Vendor documentation: https://docs.github.com/en/copilot/responsible-use/copilot-coding-agent ↗
• Source repository: https://github.com/github/spec-kit/blob/main/README.md ↗
• Vendor article: https://github.blog/news-insights/company-news/welcome-home-agents ↗
• Vendor documentation: https://support.atlassian.com/rovo/docs/work-with-rovo-dev-in-jira ↗
• Vendor page: https://www.atlassian.com/software/compass/software-catalog ↗
• Vendor documentation: https://docs.factory.ai/missions/overview ↗
• Vendor documentation: https://jules.google/docs/index.md ↗
• Third-party source: https://gigazine.net/gsc_news/en/20251119-google-antigravity ↗
• Vendor page: https://devin.ai/ ↗
• Vendor page: https://www.augmentcode.com/product/cosmos ↗
• Vendor article: https://tessl.io/blog/tessl-launches-spec-driven-framework-and-registry ↗
• Vendor page: https://copilot4devops.com/ ↗
• Vendor article: https://www.jamasoftware.com/blog/jama-connect-features-in-five-mcp ↗
• Vendor page: https://www.siemens.com/en-us/products/polarion/industrial-ai/ ↗
• Third-party source: https://newsletter.pragmaticengineer.com/p/openai-software-factory ↗
• Vendor documentation: https://docs.redhat.com/en/learn/ai-quickstarts/rh-agentic-software-factory ↗ (temporarily unavailable when checked)
• Vendor documentation: https://kiro.dev/docs/specs/correctness/ ↗
• Source repository: https://github.com/github/spec-kit/blob/main/spec-driven.md ↗
• Vendor page: https://www.jamasoftware.com/platform/jama-connect/features ↗
• Vendor documentation: https://learn.microsoft.com/en-us/azure/devops/cross-service/end-to-end-traceability?view=azure-devops ↗
• Third-party source: https://www.thoughtworks.com/en-es/radar/languages-and-frameworks/github-spec-kit ↗
• Source repository: https://github.com/nordinit/agent-hq ↗
• Vendor article: https://www.atlassian.com/blog/development/rovo-dev-in-jira-as-my-spec-driven-executor?nb=1&share=facebook ↗
• Vendor page: https://www.atlassian.com/software/compass ↗
• Vendor documentation: https://docs.factory.ai/missions/planning ↗
• Vendor documentation: https://jules.google/docs/faq/ ↗
• Vendor article: https://devin.ai/blog/introducing-devin-oncall ↗
• Third-party source: https://sddobservatory.com/frameworks/tessl ↗
• Vendor page: https://www.modernrequirements.com/copilot4devops ↗
• Vendor page: https://www.jamasoftware.com/solutions/requirements-traceability ↗
• Vendor page: https://www.modernrequirements.com/products/modern-requirements4devops-features/ ↗
• Vendor article: https://tessl.io/blog/verifiers-enforce-your-repos-rules-on-every-agent-change ↗
• Vendor documentation: http://docs.github.com/en/copilot ↗
• Source repository: https://github.com/nordinit/agent-hq/blob/main/docs/INFRASTRUCTURE.md ↗
• Vendor page: https://www.atlassian.com/software/rovo-dev/code-review ↗
• Vendor article: https://factory.ai/news/agent-readiness ↗
• Vendor page: https://jules.google/ ↗
• Vendor documentation: https://ai.google.dev/gemini-api/docs/antigravity-agent ↗
• Vendor page: https://www.cognition.ai/ ↗
• Third-party source: https://www.tmcnet.com/usubmit/-harness-acquires-augment-code-advancing-autonomous-sdlc-from-/2026/10/08/10460088.htm ↗
• Source repository: https://github.com/github/spec-kit/blob/main/docs/index.md ↗
• Vendor article: https://www.atlassian.com/blog/developer/120-prs-two-weeks-rovo-dev-in-jira ↗
• Source repository: https://github.com/google-labs-code/jules-action ↗
• Vendor documentation: https://antigravity.google/docs/ide/overview ↗
• Vendor documentation: https://tessl.io/registry/spec-driven-devlopment/spec-as-source/2.2.0/files/skills/spec-verify/SKILL.md ↗
• Vendor documentation: https://learn.microsoft.com/en-us/azure/devops/cross-service/end-to-end-traceability?view=azure-devOps ↗
• Source repository: https://github.com/github/spec-kit/blob/main/templates/commands/analyze.md ↗
• Vendor article: https://github.blog/ai-and-ml/github-copilot/how-to-orchestrate-agents-using-mission-control ↗
• Vendor documentation: https://docs.factory.ai/autonomy-and-safety/specification-mode ↗
• Vendor documentation: https://tessl.io/registry/tessl/tessl-verify ↗
• Vendor documentation: https://docs.github.com/de/copilot/concepts/agents/coding-agent/about-coding-agent ↗
• Third-party source: https://www.infoworld.com/article/4234567/hands-on-with-antigravity-2-no-ide-just-agent-chat.html ↗
• Source repository: https://github.com/google-labs-code/jules-sdk/blob/main/README.md ↗
• Source repository: https://github.com/github/spec-kit/blob/main/templates/commands/tasks.md ↗
• Third-party source: https://baeseokjae.github.io/tags/agent-first-ide/ ↗
• Research: https://arxiv.org/abs/2608.13867v1 ↗
• Research: https://arxiv.org/abs/2604.05278 ↗
• Vendor article: https://cognition.com/blog/ai-productivity ↗
• Vendor documentation: https://docs.tessl.io/ ↗
• Vendor documentation: https://developers.openai.com/blog/run-long-horizon-tasks-with-codex.md ↗
• Research: https://arxiv.org/abs/2603.17104v1 ↗
• Research: https://arxiv.org/abs/2603.24755v1 ↗
• Research: https://arxiv.org/abs/2606.27045v1 ↗
• Research: https://arxiv.org/pdf/2609.37985 ↗
• Vendor documentation: https://docs.factory.ai/agent-readiness/overview ↗

Change specs and living documentation (29)

• Vendor documentation: https://kiro.dev/docs/specs.md ↗
• Source repository: https://github.com/github/spec-kit/blob/bba473c2/docs/guides/evolving-specs.md ↗
• Source repository: https://github.com/fission-ai/openspec/blob/main/docs/concepts.md ↗
• Vendor documentation: https://tessl.io/registry/tessl-labs/spec-driven-development ↗
• Vendor documentation: https://docs.factory.com/autonomy-and-safety/specification-mode ↗
• Vendor page: https://www.augmentcode.com/guides/spec-driven-development-ai-agents-explained ↗
• Vendor documentation: https://docs.github.com/en/copilot/concepts/coding-agent/coding-agent ↗
• Vendor documentation: https://support.atlassian.com/rovo/docs/generate-code-from-a-work-item-in-jira/ ↗
• Vendor documentation: https://help.jamasoftware.com/ah/en/getting-to-know-jama-connect-features.html ↗
• Vendor article: https://blogs.sw.siemens.com/polarion/accelerate-and-scale-early-validation-with-polarion/ ↗
• Vendor documentation: https://docs.bmad-method.org/plan/plan-inside-an-organization/ ↗
• Historical SpecFlow documentation (no longer available)
• Vendor documentation: https://tessl.io/registry/spec-driven-development/spec-as-source ↗
• Third-party source: https://www.martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html ↗
• Source repository: https://github.com/github/spec-kit ↗
• Source repository: https://github.com/fission-ai/openspec/blob/main/docs/getting-started.md ↗
• Vendor article: https://tessl.io/blog/tessl-launches-spec-driven-framework-and-registry ↗
• Vendor documentation: https://docs.tessl.io/introduction-to-tessl/core-concepts ↗
• Vendor documentation: https://docs.augmentcode.com/cosmos/guides/getting-started-on-cosmos ↗
• Vendor documentation: https://docs.github.com/en/copilot/how-tos/use-copilot-agents/coding-agent/create-a-pr ↗
• Vendor documentation: https://docs.github.com/en/copilot/how-tos/copilot-in-your-ide/use-copilot-agents/use-plan-mode ↗
• Vendor documentation: https://support.atlassian.com/rovo/docs/atlassian-agents/ ↗
• Vendor page: https://www.atlassian.com/software/confluence/create-and-edit-with-rovo ↗
• Vendor documentation: https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/add-link?view=azure-devops ↗
• Vendor documentation: https://learn.microsoft.com/en-us/azure/devops/test/associate-automated-test-with-test-case?view=azure-devops ↗
• Vendor page: https://www.jamasoftware.com/solutions/requirements-traceability/ ↗
• Vendor article: https://blogs.sw.siemens.com/polarion/how-to-incorporate-the-correct-traceability-model-into-your-processes/ ↗
• Source repository: https://github.com/bmad-code-org/BMAD-METHOD ↗
• Vendor page: https://testautomationu.applitools.com/bdd-with-specflow/chapter4.html ↗

Artifact hierarchy (34)

• Vendor documentation: https://github.github.io/spec-kit/quickstart.html ↗
• Vendor documentation: https://openspec.dev/docs/schemas/spec-driven ↗
• Vendor documentation: https://tessl.io/registry/tessl-labs/spec-driven-development/files/docs/spec-format.md ↗
• Vendor page: https://www.augmentcode.com/solutions/large-projects ↗
• Vendor article: https://www.atlassian.com/blog/developer/rovo-dev-for-architecting-solutions ↗
• Vendor documentation: https://learn.microsoft.com/en-us/azure/devops/boards/work-items/about-work-items ↗
• Vendor documentation: https://help.jamasoftware.com/ah/en/getting-to-know-jama-connect-features/traceability-from-requirements-to-test.html ↗
• Vendor page: https://www.siemens.com/en-us/products/polarion/requirements/ ↗
• Vendor documentation: https://docs.cline.bot/features/memory-bank ↗
• Vendor documentation: https://docs.task-master.dev/capabilities/task-structure ↗
• Vendor page: https://ampcode.com/manual?preview ↗
• Vendor documentation: https://kiro.dev/docs/steering ↗
• Vendor documentation: https://kiro.dev/docs/cli/steering/ ↗
• Source repository: https://github.com/github/spec-kit/blob/main/docs/guides/evolving-specs.md ↗
• Source repository: https://github.com/github/spec-kit/blob/main/docs/reference/agentic-sdd.md ↗
• Source repository: https://github.com/Fission-AI/OpenSpec/blob/main/docs/workflows.md ↗
• Source repository: https://github.com/Fission-AI/OpenSpec/blob/main/docs/concepts.md ↗
• Vendor documentation: https://tessl.io/registry/tessl-labs/spec-driven-development/files/README.md ↗
• Vendor documentation: https://docs.bmad-method.org/plan/choose-a-planning-path/ ↗
• Vendor documentation: https://docs.bmad-method.org/plan/break-work-into-stories-and-track-it/ ↗
• Vendor page: https://www.augmentcode.com/workflows/coding/project-builder ↗
• Vendor documentation: https://docs.factory.ai/autonomy-and-safety/specification-mode.md ↗
• Vendor documentation: https://docs.factory.ai/harness/agents-md.md ↗
• Vendor page: https://factory.ai/product/droids ↗
• Vendor page: https://www.atlassian.com/software/confluence/templates/product-requirements/ ↗
• Vendor article: https://www.atlassian.com/blog/development/rovo-dev-in-jira-as-my-spec-driven-executor?nb=1 ↗
• Vendor documentation: https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/define-features-epics ↗
• Vendor documentation: https://learn.microsoft.com/en-us/azure/devops/test/test-objects-overview ↗
• Vendor documentation: https://learn.microsoft.com/en-us/azure/devops/test/create-a-test-plan ↗
• Vendor page: https://www.jamasoftware.com/jama-connect ↗
• Vendor documentation: https://help.jamasoftware.com/ah/en/manage-content/baselines/reuse-baselined-items.html ↗
• Vendor page: https://www.siemens.com/en-us/products/polarion/application-lifecycle-management-alm/ ↗
• Vendor page: https://www.siemens.com/en-us/products/polarion/qa ↗
• Vendor documentation: https://ampcode.com/docs/cli/execute-mode ↗

Fact-check (16)

• Vendor documentation: https://kiro.dev/docs/specs/correctness.md ↗
• Vendor documentation: https://openspec.dev/docs/quickstart ↗
• Vendor article: https://www.jamasoftware.com/blog/better-product-development-tips-for-traceability/ ↗
• Vendor documentation: https://learn.microsoft.com/en-us/azure/devops/boards/github/work-item-integration-github-copilot?view=azure-devops ↗
• Vendor page: https://www.atlassian.com/licensing/rovo-dev ↗
• Vendor documentation: https://docs.factory.ai/software-factory/overview ↗
• Third-party source: https://intent-driven.dev/blog/2026/04/29/spec-driven-development-with-adr ↗
• Vendor documentation: https://help.jamasoftware.com/en/manage-content/coverage-and-traceability/relationships.html ↗
• Vendor documentation: https://docs.github.com/en/enterprise-cloud@latest/copilot/concepts/agents/coding-agent/about-coding-agent ↗
• Vendor documentation: https://tessl.io/registry/tessl-labs/spec-driven-development/files/skills/spec-verification/SKILL.md ↗
• Source repository: https://github.com/cucumber/docs/blob/main/content/docs/guides/overview.md ↗
• Vendor documentation: https://help.jamasoftware.com/ah/en/manage-content/baselines.html ↗
• Vendor documentation: https://help.jamasoftware.com/ah/en/collaborating-with-your-team/electronic-signatures.html ↗
• Vendor documentation: https://help.jamasoftware.com/ah/en/manage-content/exporting-data-to-a-document/office-templates/create-a-coverage-report.html ↗
• Vendor article: https://blogs.sw.siemens.com/polarion/mastering-concurrent-v-model-development-with-polarion-collections ↗
• Vendor documentation: https://learn.microsoft.com/en-us/azure/devops/pipelines/test/requirements-traceability?view=azure-devops ↗

Portability follow-up (20)

• Vendor documentation: https://docs.github.com/copilot/concepts/agents/coding-agent/about-coding-agent ↗
• Vendor documentation: https://support.atlassian.com/rovo/docs/install-and-run-rovo-dev-cli-on-your-device/ ↗
• Vendor documentation: https://support.atlassian.com/rovo/docs/switch-between-large-language-models-in-rovo-dev-cli/ ↗
• Vendor documentation: https://docs.factory.ai/enterprise/privacy-and-data-flows ↗
• Vendor article: https://www.jamasoftware.com/blog/self-hosted-and-cloud-flexible-deployment-options-for-your-requirements-management-with-jama-software/ ↗
• Vendor documentation: https://support.jamasoftware.com/hc/en-us/articles/28473133955853-Analyzing-Jama-Connect-Data-in-External-Business-Intelligence-Tools ↗
• Vendor article: https://blogs.sw.siemens.com/polarion/polarion-alm-2512-whats-new-and-noteworthy/ ↗
• Vendor documentation: https://kiro.dev/docs/how-kiro-works/ ↗
• Vendor documentation: https://kiro.dev/docs/web/setup/ ↗
• Vendor documentation: https://kiro.dev/docs/models/available-models/ ↗
• Vendor documentation: https://github.github.com/spec-kit/integrations/index.html ↗
• Source repository: https://github.com/Fission-AI/OpenSpec ↗
• Source repository: https://github.com/Fission-AI/OpenSpec/blob/main/SECURITY.md ↗
• Vendor documentation: https://openspec.dev/docs/cli ↗
• Source repository: https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE ↗
• Vendor documentation: https://docs.bmad-method.org/start/install-bmad/ ↗
• Vendor documentation: https://docs.bmad-method.org/customize/customize-bmad/ ↗
• Vendor documentation: https://docs.tessl.io/reference/configuration ↗
• Source repository: https://github.com/tesslio/cli/blob/main/LICENSE.md ↗
• Vendor documentation: https://docs.tessl.io/reference/workspaces ↗

Check lifecycle, Luna (14)

• Vendor documentation: https://kiro.dev/docs/specs/analyze-requirements/ ↗
• Vendor documentation: https://kiro.dev/docs/hooks/actions/ ↗
• Vendor documentation: https://kiro.dev/docs/cloud-sessions/ ↗
• Vendor documentation: https://github.github.com/spec-kit/reference/agentic-sdd.html ↗
• Vendor documentation: https://github.github.com/spec-kit/reference/workflows.html ↗
• Source repository: https://github.com/Fission-AI/OpenSpec/blob/main/docs/cli.md ↗
• Source repository: https://github.com/Fission-AI/OpenSpec/blob/main/skills/openspec-verify-change/SKILL.md ↗
• Source repository: https://github.com/Fission-AI/OpenSpec/blob/main/docs/supported-tools.md ↗
• Vendor documentation: https://docs.bmad-method.org/build/review-a-change/ ↗
• Vendor documentation: https://docs.bmad-method.org/build/test-completed-work/ ↗
• Source repository: https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise/blob/main/docs/how-to/workflows/run-trace.md ↗
• Source repository: https://github.com/tesslio/spec-driven-development-tile ↗
• Vendor documentation: https://docs.tessl.io/codifying-and-enforcing-your-skill-standards/verifiers-overview ↗
• Vendor documentation: https://docs.tessl.io/codifying-and-enforcing-your-skill-standards/verify-agent-changes-in-ci ↗

Check lifecycle, Muse (0)

Tightened criteria, Luna Max (8)

• Vendor documentation: https://kiro.dev/docs/workflows/patterns/ ↗
• Vendor documentation: https://kiro.dev/docs/workflows/ ↗
• Vendor documentation: https://kiro.dev/docs/models/ ↗
• Vendor documentation: https://github.github.com/spec-kit/guides/evolving-specs.html ↗
• Vendor documentation: https://openspec.dev/docs/skills ↗
• Vendor documentation: https://docs.bmad-method.org/plan/design-ux-and-architecture/ ↗
• Vendor documentation: https://docs.bmad-method.org/build/finish-an-epic/ ↗
• Source repository: https://raw.githubusercontent.com/tesslio/spec-driven-development-tile/main/skills/spec-verification/SKILL.md ↗

Tightened criteria, Muse XHigh (30)

• Vendor documentation: https://docs.github.com/copilot/how-tos/use-copilot-agents/coding-agent/integrate-coding-agent-with-azure-boards ↗
• Vendor documentation: https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent ↗
• Vendor article: https://github.blog/changelog/2026-03-18-configure-copilot-coding-agents-validation-tools ↗
• Vendor documentation: https://docs.github.com/en/copilot/concepts/agents/code-review ↗
• Vendor page: https://azure.microsoft.com/en-us/products/devops/server ↗
• Vendor documentation: https://support.atlassian.com/rovo/docs/enable-code-reviews ↗
• Vendor documentation: https://support.atlassian.com/rovo/docs/check-acceptance-criteria-in-a-code-review ↗
• Vendor documentation: https://confluence.atlassian.com/doc/page-history-and-page-comparison-views-139379.html ↗
• Vendor page: https://www.atlassian.com/software/confluence/jira-integration ↗
• Vendor documentation: https://docs.factory.com/enterprise/privacy-and-data-flows ↗
• Vendor documentation: https://docs.factory.com/enterprise/airgapped-deployment ↗
• Vendor documentation: https://docs.factory.com/software-factory/automated-qa ↗
• Vendor documentation: https://help.jamasoftware.com/en/manage-content/coverage-and-traceability/relationships/clear-suspect-links.html ↗
• Vendor documentation: https://help.jamasoftware.com/ah/en/manage-content/coverage-and-traceability/run-impact-analysis.html ↗
• Vendor documentation: https://help.jamasoftware.com/ah/en/getting-to-know-jama-connect-features/change-management.html ↗
• Vendor documentation: https://help.jamasoftware.com/ah/en/test/test-runs/execute-a-test-run.html ↗
• Vendor documentation: https://help.jamasoftware.com/ah/en/reviews-in-jama-connect/approver-tasks/sign-a-review-electronically.html ↗
• Vendor documentation: https://support.jamasoftware.com/hc/en-us/articles/38854126953101-Can-Jama-Connect-be-installed-on-Amazon-EKS-or-Azure-AKS ↗
• Vendor documentation: https://support.jamasoftware.com/hc/en-us/articles/46702937210125-Version-9-37-Cloud ↗
• Vendor page: https://www.siemens.com/en-us/products/polarion/application-lifecycle-management-alm ↗
• Vendor page: https://www.siemens.com/en-us/products/polarion/requirements ↗
• Vendor page: https://www.siemens.com/en-us/products/polarion/polarion-x ↗
• Vendor article: https://blogs.sw.siemens.com/polarion/accelerate-and-scale-early-validation-with-polarion ↗
• Vendor article: https://blogs.sw.siemens.com/polarion/a-deeper-dive-into-collections ↗
• Vendor article: https://blogs.sw.siemens.com/polarion/interconnecting-your-engineering-elements ↗
• Vendor article: https://blogs.sw.siemens.com/polarion/polarion-alm-2512-whats-new-and-noteworthy ↗
• Vendor page: https://extensions.polarion.com/extensions/462-workflow-function-and-condition-package ↗
• Vendor article: https://blogs.sw.siemens.com/polarion/mastering-concurrent-v-model-development-with-polarion-collections/ ↗
• Vendor article: https://blogs.sw.siemens.com/polarion/polarion-alm-20-r1-whats-new-and-noteworthy/ ↗
• Vendor article: https://blogs.sw.siemens.com/polarion/polarion-alm-2304-whats-new-and-noteworthy/ ↗

77-cell audit, Luna Max (3)

• Vendor documentation: https://openspec.dev/docs/supported-tools ↗
• Source repository: https://github.com/bmad-code-org/bmad-method ↗
• Vendor documentation: https://docs.tessl.io/reference/cli-commands ↗

77-cell audit, Muse XHigh (9)

• Vendor article: https://github.blog/changelog/2025-10-28-copilot-coding-agent-now-supports-self-hosted-runners ↗
• Vendor documentation: https://support.atlassian.com/rovo/kb/How-Rovo-customer-data-is-handled/ ↗
• Vendor page: https://www.atlassian.com/software/rovo/pricing ↗
• Vendor page: https://www.atlassian.com/migration/rovo-connectors-data-center ↗
• Vendor documentation: https://support.atlassian.com/organization-administration/docs/connect-jira-data-center-to-rovo ↗
• Vendor documentation: https://support.atlassian.com/organization-administration/docs/connect-confluence-data-center-to-rovo ↗
• Vendor documentation: https://help.jamasoftware.com/ah/en/test/test-runs.html ↗
• Vendor documentation: https://docs.github.com/en/copilot/how-tos/use-copilot-agents/coding-agent/customize-the-agent-environment ↗
• Vendor page: https://www.jamasoftware.com/platform/jama-connect/integrations ↗

Audit reconciliation and validation protocol (3)

• Vendor documentation: https://testdrive.polarion.com/polarion/sdk/doc/javadoc/com/polarion/alm/tracker/model/IWorkItem.html ↗
• Vendor documentation: https://support.industrysoftware.automation.siemens.com/docs_general/polarion/manuals/polarion_qa_benefit_guide.pdf ↗
• Vendor page: https://www.siemens.com/en-us/products/polarion/ ↗