Detailed assessments of how each product works, the configuration reviewed and the supporting evidence. Evidence reviewed through October 24, 2026. These are documentation findings, not product trials. Other products retain the earlier survey descriptions without new seven-property ratings.
Links marked ↗ open external evidence. Each link identifies whether it leads to vendor documentation, a vendor article, a source repository, research or a third-party source.
Detailed product assessments
GitHub Copilot coding agent
Assessed configuration GitHub Copilot Enterprise cloud agent started from a GitHub issue on GitHub.com, with GitHub Actions build/test workflows and branch protection configured. This assessment does not import IDE-only planning or preview integrations. Self-hosted Actions runners do not replace the GitHub cloud-agent service.
Workflow and records
Specification unit
Per issue or prompt: a session with a task checklist and one pull request. Plan mode produces a chat plan, optionally saved as Markdown.
After implementation
Session ends after merge. Branch and PR persist. Plan text does not merge into a capability spec.
Later changes to the same area
Later work starts a new session from a new issue or prompt. Persistent files are copilot-instructions.md and AGENTS.md, which are instructions, not functional specs.
Links to implementation and tests
Session reads repo context and runs tests. No persistent spec-to-code links. No spec drift detection.
A person starts a coding task. Configured repository workflows can run checks on pull requests. CLI hooks and AI code review are separate surfaces; their support does not establish the same checks in the hosted coding agent. Vendor documentation: Hooks ↗
What failure blocks
Required status checks can block merge when configured in branch protection. Administrator and role bypass depends on repository settings. A review comment or agent instruction alone is not a required check. General hooks do not establish a supplied specification-drift check. Vendor documentation: Branch protection ↗
How findings are resolved
People review the pull request and can ask for revisions or record follow-up work. Issue and review history do not establish a supplied reconciliation record for requirement/design/code disagreement.
Edition and availability
This assessment concerns the GitHub-hosted coding agent. CLI, IDE and code-review features have different event support and account policies; their capabilities should not be assumed identical. Vendor documentation: Coding agent ↗
Assessment against the seven properties
Lifecycle traceability Limited
L1 met: issue assignment starts coding and PR workflow and commits link to session logs; L2 maintained design/code relationship or version context is missing.
L1 met: repository research identifies where a task change belongs and supports a refined task plan; L2 scoped cross-layer impact and constrained alternatives are missing.
L2 met: Actions run and artifacts are commit-linked and branch rules associate required checks and reviews; L3 governing requirement/design versions and waiver association are missing.
Assessed configuration Azure DevOps Services Boards, GitHub repository/App and Copilot coding agent; configured Test Plans/Pipelines for the test-result rating. Azure DevOps Server alone is a different bundle.
Workflow and records
Documents and records
Boards: Epic -> Feature -> Requirement (User Story, Product Backlog Item, Requirement, Issue) -> Task, plus Bug; Test Plans -> Test Suites (static, requirement-based, query-based) -> Test Cases + Shared Steps/Parameters + runs/results; Repos commits/PRs/builds.
What remains after delivery
Work items persist with history, states, area/iteration paths. Test plans/suites/cases persist per cycle. Test cases reused across plans without copy. No baseline object like Jama/Polarion.
How the parts link
Parent-child links form Epic/Feature/Requirement/Task. Tested-By/Related links tie tests to requirements. Development control ties work to branches, commits, PRs, builds. Requirement-based suites auto-link cases to backlog items.
How later changes propagate
Links plus manual review. Bugs created in test auto-link to requirements/builds. No evidence of automatic suspect flagging. Coverage via board cards, Analytics, Power BI, or extensions. AI test-plan management via MCP must be prompted. Rule checks are process workflow rules, not cross-artifact consistency.
A person starts Copilot from the Boards work item. Copilot creates a linked draft pull request in GitHub. Test pipelines run according to their configured triggers; the handoff itself does not validate that work-item text matches the code. Vendor documentation: Boards handoff ↗
What failure blocks
For this handoff, merge enforcement belongs to the GitHub repository and its required checks. Azure Repos separately supports required or optional build-validation policies; those policies do not govern this GitHub pull request. Neither path establishes a supplied specification-consistency gate. Vendor documentation: GitHub protection ↗, Vendor documentation: Azure Repos policies ↗
How findings are resolved
Linked work items, bugs and test results can track corrections under configured workflows. A failed test and a requirement/document discrepancy need different investigations. The Boards handoff does not itself create a cross-layer reconciliation task.
Edition and availability
The documented Boards–Copilot integration applies to Azure DevOps Services and requires a Copilot subscription, GitHub repository and GitHub App authentication. Azure Repos is not supported for this handoff. Azure DevOps Server capabilities are separate.
Assessment against the seven properties
Lifecycle traceability Substantial
Work-item hierarchy, requirement-based suites, commits, pull requests, builds and test results provide meaningful traceability. The reviewed Boards–Copilot handoff has no dedicated design layer. Vendor documentation: End-to-end traceability ↗
Persistent work items, revision history and lifecycle states preserve parts of the system intent. An integrated requirement/design baseline, complete before implementation and identified by each delivered code version, was not established. History alone does not meet the full criterion.
The reviewed sources do not establish a supplied drift detector and tracked reconciliation loop across requirements, design and implementation. Linked bugs and failed-test follow-up address narrower findings.
Cross-service views expose associated work items, code changes, builds and test results. This is useful input to an assessment; a maintained design/constraint model with alternatives, assumptions and trade-offs was not established.
With requirement-based suites and associated automated tests configured, executable results roll up to requirements for a build. The requirements-quality view shows pass rate, failures and requirements without tests. Pipeline/repository settings determine whether failure blocks progress. Vendor documentation: Requirements traceability ↗
Work items, commits, PRs, builds, test records and configured approvals provide substantial delivery evidence. The reviewed default workflow does not establish a governing versioned design baseline for the delivered build; approvals/waivers require process configuration. Vendor documentation: End-to-end traceability ↗
Core Boards, Test Plans and Pipelines have a deployable Azure DevOps Server counterpart, but that does not make this bundle portable. The built-in Copilot handoff requires Azure DevOps Services, a GitHub repository and GitHub App authentication; Azure Repos is unsupported. The complete assessed bundle cannot move to Server alone. Vendor documentation: Handoff requirements ↗
Assessed configuration Confluence and Jira with Rovo Dev on an activated Atlassian Cloud site and connected repository. Self-managed Data Center products alone do not provide this agent workflow.
Workflow and records
Documents and records
Confluence PRD template (background, objectives, user stories, UX mockups, scope), RFC/decision pages, whiteboards; Jira Epic/Story/Task/Subtask (plus Product Discovery ideas); Rovo Dev code plan in Jira session; Bitbucket/GitHub PRs with reviews.
What remains after delivery
Confluence pages and Jira items persist and version. Whiteboard stickies convert to live Jira issues. Rovo plans live in session/Jira panel and are refinable. No single spec filename; persistence is in Confluence/Jira records.
How the parts link
Confluence PRD/RFC -> Jira Epic/Stories/Tasks breakdown -> Rovo Dev plan -> code/PR -> review against Jira acceptance criteria. Links: /jira embeds, Jira keys back to PRD, Teamwork Graph, design-to-epic mapping prompts.
How later changes propagate
AI-invoked plus automation. Rovo drafts/updates PRD from Jira, creates linked epics/stories, updates Confluence and Jira links. Jira Automations can trigger Rovo Dev. Review loop is Specs -> Implementation -> Review. Must prompt or trigger automation.
Rovo can be invoked by a person or an automation trigger. AI review judges content; Jira workflow conditions and validators check configured transition rules. The latter do not establish semantic agreement between a Confluence page and code. Vendor documentation: Agent automation ↗, Vendor documentation: Workflow rules ↗
What failure blocks
Configured validators can reject a status transition. AI suggestions and review comments are not by themselves merge gates. Workflow administrators choose the transition rules; repository merge enforcement is a separate control.
How findings are resolved
Review findings and Jira work items can carry follow-up work. The reviewed workflow does not establish retained affected-area findings and tracked rechecks that reconcile Confluence design, Jira requirements and implementation together.
Material migration limit
Jira backup and separate automation exports have different scopes; app data is excluded from the documented Jira backup. Exported records do not reproduce Rovo Cloud execution elsewhere. Vendor documentation: Jira export ↗
Edition and availability
Rovo’s Cloud services and local CLI should be distinguished from self-managed Jira and Confluence. AI access and credits depend on the subscribed service. The documented transition from standalone Rovo Dev to Jira subscriptions should not be treated as identical availability on every site. Vendor page: Rovo Dev licensing ↗
Assessment against the seven properties
Lifecycle traceability Limited
Confluence requirements/decision pages, Jira work items and repository references connect parts of the workflow. Page links and issue keys do not establish maintained cross-layer design/code/test semantics. Vendor page: Product integration ↗
Confluence page versions and Jira lifecycle states retain documents and work state. The reviewed sources do not establish one integrated approved target or a governing design-version link for each delivered build. Vendor documentation: Page versions and history ↗
Rovo Dev can compare a pull request with linked Jira acceptance criteria using AI. It reports met, missing or needing manual checking. This detects possible disagreement in a narrower scope; tracked design/document reconciliation and recheck were not established. Vendor documentation: Acceptance-criteria review ↗
The reviewed sources do not establish change/alternative assessment grounded in maintained requirement–design–code–test relationships and version baselines. AC review and general architecture assistance do not supply that model.
Rovo acceptance-criteria review is an AI assessment, not executable testing of the implementation. Requirement-linked test execution/results need a separately assessed testing integration.
Jira/Confluence document and work-management processes have self-managed Data Center editions. The assessed Rovo Dev workflow requires an activated Atlassian Cloud site/account. A local CLI does not remove that service dependency; the full AI bundle was not established as redeployable. Vendor documentation: CLI prerequisites ↗
Assessed configuration Local IDE/CLI specification workflow; optional property-based testing is IDE-specific. Kiro account, catalog and model-service dependencies remain under review; hosted sessions are not assumed portable.
Steering persists and is included by default; specs persist in repo and are version-controlled; continuous refinement supported. Per-feature specs remain as history.
How the parts link
Steering is baseline context. Workflow is requirements -> design -> tasks. Tasks map to requirements. EARS notation in requirements. Sync Files maps tasks to requirements.
How later changes propagate
Manual/AI-invoked. Edit requirements.md, then Refine design.md to update design and tasks, then Sync Files in tasks.md. Must be invoked in spec session. No auto script check found.
The reviewed docs surface property-test failures but do not establish that they block task completion. A nonzero shell-hook result can block a Pre Tool Use or Prompt Submit event; this does not establish a general completion gate.
How findings are resolved
Optional correctness testing can surface a mismatch and offer changes to the spec, implementation or test. Durable affected-area remediation records and tracking through correction and recheck were not established.
Edition and availability
Property-based testing is documented for the IDE. Hooks are supported in IDE and CLI, not Web. Cloud sessions require an account and supported subscription; model selection is from Kiro’s catalog. Vendor documentation: Available models ↗
Assessment against the seven properties
Lifecycle traceability Limited
Per-feature requirements, design and tasks are connected; optional property tests reference requirements/tasks. A maintained design-to-changed-code relationship was not established. Vendor documentation: Specs and correctness ↗
The reviewed workflow retains feature specifications. A complete integrated target description across features, with approved/implemented states and governing design versions for delivered code, was not established.
Optional property tests expose behaviour mismatches and can lead to fixing the spec, code or test. A durable affected-area remediation record tracked through correction and recheck was not established. Vendor documentation: Correctness ↗
Requirements analysis checks inconsistencies, ambiguities and gaps before design. It does not establish cross-layer affected artifacts or alternatives grounded in maintained relationships, constraints and baselines. General custom workflows do not establish a supplied assessment of this kind. Vendor documentation: Requirements analysis ↗
Optional IDE property-based tests execute against the implementation and reference requirements/tasks. A retained requirement-result report identifying the tested code revision was not established. Vendor documentation: Correctness ↗
Git can retain feature specs with code. A retained record identifying the delivered build, governing document revisions and applicable reviews/approvals/waivers was not established.
IDE/CLI run the standalone agent harness locally rather than in the hosted Web/Mobile sandbox. This moves agent execution, not the entire Kiro service: its account, runtime and catalog/inference dependencies remain. Shared workflow recipes can run on supported clients. Exported specs alone are not evidence that the complete process can move. Whether the remaining services provide only inference or essential factory control is unresolved; local execution alone earns no portability level. Vendor documentation: Execution model ↗
Assessed configuration Local toolkit and documented analysis/convergence workflows with a supported coding agent. The selected agent supplies its own model and service dependencies.
Workflow and records
Documents and records
.specify/memory/constitution.md; specs/<###>-<name>/spec.md; plan.md plus research.md, data-model.md, contracts/, quickstart.md; checklists; tasks.md.
What remains after delivery
Three persistence models: flow-forward (completed directories kept as history), living spec (spec.md is contract), flow-back (accepted discoveries maintained). specs/ is not overwritten by template refresh.
How the parts link
Constitution -> spec -> plan -> tasks -> implement -> converge. Tasks ordered per user story. Analyze reports coverage gaps with Requirement Key to task mapping. Constitution violations are CRITICAL.
How later changes propagate
Read-only AI check. /speckit.analyze reports gaps across spec/plan/tasks without editing. User fixes at source and re-runs. /speckit.converge only appends tasks. Must be invoked.
Analyze is an AI review that does not edit artifacts; converge can append remediation tasks. Neither is a default merge gate. Custom workflows can pause for human approval or stop on a failed step. The workflow and repository settings determine enforcement.
How findings are resolved
The invoked converge workflow can append remediation tasks and be rerun against the corrected implementation. Analyze reports artifact inconsistencies without editing them. Required completion or merge enforcement depends on the configured workflow. Vendor documentation: Analysis and convergence ↗
Edition and availability
The toolkit is open source. The reviewed workflow-engine documentation carries no preview label, but this research did not establish a stability guarantee for that feature. The selected coding agent has its own licensing and service constraints.
Assessment against the seven properties
Lifecycle traceability Limited
The constitution, feature specs, plans and tasks are connected. A complete maintained design-to-code-to-test relationship model was not established. Vendor documentation: Agentic SDD ↗
A living-spec maintenance option is documented alongside per-feature history. Explicit approval/implementation states and governing design-to-code version binding were not established. Vendor documentation: Evolving specs ↗
Invoked analyze reviews artifact consistency; converge compares implementation and appends remediation tasks. Re-running it supports correction and recheck. A retained record showing each finding’s disposition, correction and successful recheck was not established, so coverage is substantial rather than complete. These AI workflows are not default merge gates; enforcement is assessed separately. Vendor documentation: Analysis and convergence ↗
Specs and plans ground implementation and review. A documented assessment spanning affected cross-layer artifacts, alternatives, constraints and trade-offs was not established.
Git retains specification and implementation history. A documented delivery record tying a build to governing design versions and review/approval/waiver decisions was not established.
MIT-licensed workflow definitions, templates and checks can continue with supported coding agents on other systems, without a hosted Spec Kit factory service. Agent/model dependencies belong to the chosen tool. This score covers workflow execution, not migration of every agent session. Vendor documentation: Integrations ↗
Assessed configuration Local CLI, default spec-driven schema and optional verification skill. Beta hosted/cross-repository features and community schemas are not assumed part of the core.
Workflow and records
Documents and records
openspec/changes/<name>/proposal.md, specs/<capability>/spec.md delta, design.md, tasks.md, .openspec.yaml; openspec/specs/<capability>/spec.md main truth; changes/archive/YYYY-MM-DD-<name>/ history.
What remains after delivery
Main specs/ persists as source of truth. Per-change folder persists until archive, then moved to archive. Delta sync to main on archive after confirmation.
How the parts link
Schema defines order: proposal first, specs and design in either order, tasks needs both, apply needs tasks. Proposal Capabilities section lists capability paths. Delta ops: ADDED, MODIFIED, REMOVED, RENAMED. Scenarios use WHEN/THEN.
How later changes propagate
AI-invoked plus CLI rule check. openspec validate rejects bad deltas. /opsx:verify reports completeness. /opsx:archive warns on incomplete tasks or unsynced specs and offers sync. Must invoke commands.
Strict CLI validation can turn structural warnings into failures; archived-task validation can exit nonzero for incomplete tasks. The optional AI verification reports issues but does not itself block archive. A failed command only becomes a merge gate when repository enforcement requires it.
How findings are resolved
Optional verify reports implementation/specification issues but creates no remediation artifacts. A person or another workflow must retain findings, assign corrections and track recheck. Archive validation is not that reconciliation loop. Vendor documentation: Skills ↗
Edition and availability
The MIT CLI and workflows are documented as available. OpenSpec Stores and related cross-repository features are beta; do not extend that label to the entire product. Source repository: Source and license ↗
Assessment against the seven properties
Lifecycle traceability Limited
Capability specs, change proposals, designs and tasks are connected. Core code/test relationships were not established; community file links alone do not demonstrate tested implementation. Vendor documentation: Spec-driven schema ↗
Active change proposals describe intended changes; archive merges deltas into current capability specs. This does not by itself provide a complete integrated approved target before implementation, explicit approval states, or binding to delivered code versions. Vendor documentation: Quickstart ↗
CLI validation checks structure. Optional AI verify compares implementation to the change artifacts but is report-only and creates no remediation record; correction tracking and recheck require another workflow. Vendor documentation: Skills ↗
The invoked proposal inventories affected/new/modified capabilities and code/API/dependency impact. The design records context, constraints, decisions, alternatives, risks and trade-offs. Its scope is the documented change and referenced capability specs. A maintained affected-test map and explicit baseline binding were not established; architecture simulation is not required for full support. Vendor documentation: Spec-driven schema ↗
Current specs and archived change records can accompany code in Git. Archive history does not itself identify the governing approved design and decisions for a delivered build.
The MIT local CLI and editable workflow schemas work across supported coding assistants without a required hosted OpenSpec execution service or repository host. Selected assistants retain their own model/service dependencies. Source repository: Source and license ↗
Assessed configuration BMAD workflow documents plus the separately installed Test Architect (TEA) module. The cited workflow versions and installed module must be compatible; core-only BMAD is not the scored bundle.
PRD is owned and updated only via bmad-prd Update mode. Spine and UX via their skills. Tickets and joined plans persist. Finished work stays finished. Historical plans kept.
How the parts link
PRD is source. UX and spine derive from PRD. Specs derive from PRD plus spine and UX by reference, not copy. Tickets derive from specs. Capability and ticket IDs stay stable.
How later changes propagate
AI-invoked. Run bmad-prd Update, then update spine, then re-run bmad-spec which updates SPEC.md in place, then re-slice stories. Gates: PRD validate, spine review, breakdown approval, retrospective. Must invoke skills.
Core review reports findings; a person decides how to resolve them. TEA trace produces a requirements-coverage gate, not proof that tests passed. Test execution and repository enforcement must be configured separately. Source repository: TEA trace ↗
How findings are resolved
Invoked reviews record dated findings in plans; follow-up work and repeated review can track corrections. Retrospectives record action items, and replanning updates affected work. These are AI/human review workflows, not deterministic proof of semantic agreement. Vendor documentation: Review ↗
Edition and availability
Current installation docs distinguish stable v6.12 from v7 Preview Alpha. TEA is a separate optional module; the test-coverage score includes its documented trace capability, not a claim about core defaults. Exact workflow availability should be checked against the installed version. Vendor documentation: Versions and installation ↗
Persistent PRD, UX, architecture and plans form a system-level target; plans retain baseline revisions. Explicit proposed/approved/implemented states and the governing design version for each delivered code version were not established.
Invoked review records dated findings against the plan/baseline and supports repeated review. Retrospectives record action items and verdicts. Correction depends on the AI/human workflow rather than a deterministic semantic check. The complete retained correction/recheck record is not guaranteed by those review artifacts alone; mandatory enforcement is a separate question. Vendor documentation: Review a change ↗
Invoked replanning identifies affected tickets and stale entries, re-slices work and records decisions. Architecture workflows weigh alternatives and trade-offs against the project context. A maintained affected requirement/design/code/test map tied to baselines was not established. Vendor documentation: UX and architecture ↗
Optional TEA trace maps requirements to tests, but its gate measures coverage; passing tests are separate. Core QA executes generated tests, but the reviewed flow does not supply the combined requirement/result/code-version record. Source repository: TEA trace ↗
Plans, baseline references, dated reviews and retrospectives give partial provenance. A complete association between a delivered build, governing design versions and applicable approval/waiver records was not established. Vendor documentation: Retrospectives ↗
MIT workflow files and overrides can continue through supported coding tools on other systems without a hosted BMAD factory service. The chosen tool supplies model execution. Optional TEA is a separate module. Vendor documentation: Installation ↗
Assessed configuration Published spec-driven development tile and separately documented Verifiers. Offline tile content does not establish offline Verifier execution; the CLI, token and gateway dependencies must be checked together.
Workflow and records
Documents and records
*.spec.md with YAML frontmatter (name, description, targets); inline API contract block; [@test] links to test files; tile skills/rules/docs/scripts (requirement-gathering, spec-writer, spec-verification, spec-before-code).
What remains after delivery
.spec.md persists. Styleguide says keep specs synchronized with implementation. targets must exist. Test files persist alongside.
How the parts link
Requirement -> approved spec -> code. Spec links to implementation via targets globs and to verification via inline [@test] next to each requirement. targets is required.
How later changes propagate
Script check plus AI-invoked. validate-specs.sh checks frontmatter/structure. check-spec-links.sh checks targets and [@test] paths exist. spec-verification skill reviews sync. Must be invoked.
The spec-driven development tile’s invoked verification runs structure/link scripts, linked tests and an AI comparison. Separately, Verifiers can run locally, in CI, or through enabled pull-request review automation. Source repository: SDD tile ↗, Vendor documentation: Verifier overview ↗
What failure blocks
Tile scripts can fail on malformed specs or broken links. Verifiers use an AI judge: info/warn report findings, while error severity fails the check. Repository protection must require that check to block merge. Repeated execution of a rule does not make the AI verdict deterministic. Vendor documentation: CI enforcement ↗
How findings are resolved
The invoked SDD verification skill can identify drift, fix issues, run linked tests and recheck. A durable finding/task record and routine retention of the result were not established. Verifier CI status is a separate record of a configured rule judgment. Source repository: SDD skill ↗
Edition and availability
Verifiers were announced generally available on October 15, 2026. The published SDD tile is a separate artifact. The older closed-beta framework announcement does not establish that product’s current availability. Vendor article: GA announcement ↗
Specs persist and can be maintained in place. Explicit approval/implementation states and governing design-to-code version binding were not established.
The invoked SDD skill compares specs with code, runs linked tests, fixes issues and rechecks. Durable finding storage and tracked follow-up were not established. Newer Verifiers supply separate AI rule checks, with configurable CI enforcement. Source repository: SDD verification skill ↗
The invoked SDD verification skill actually runs linked tests and reports pass/fail. A retained requirement-result report bound to a specific code revision was not established. Source repository: SDD verification skill ↗
Versioned specs and implementation, plus retained PR verifier checks, provide partial provenance. A complete delivered-build/governing-design/review/waiver record was not established.
Vendored SDD plugin/workflow content can be executed by supported coding agents offline. This is a portable content path, not proof of full-bundle portability. Verifier CI requires TESSL_TOKEN and a configured gateway; independent Verifier execution was not established. Retaining verifier JSON alone does not settle whether the service can be removed. Vendor documentation: Vendoring ↗
Assessed configuration Configured item types, relationships, baselines, reviews and test management, with connected development/test tools where stated. Self-hosted deployment is available; code/build associations require evidence from the actual integration.
Workflow and records
Documents and records
Item types: stakeholder, system, software/hardware requirements, risks (PHA/FMEA), designs, test plans/cases/runs, defects, baselines/catalogs/branches, reviews, change requests; Traceability Information Model (TIM) defines allowed relations.
What remains after delivery
Versioned items. Baselines at milestones. Reuse catalogs with sync (shared Global ID) or branch. Audit trail. Review Center approvals persist.
How the parts link
User need -> system -> software/hardware -> design output -> test case/run/defect, plus risks. Forward and backward traceability. Live Trace Explorer scores quality, coverage, verification. Relationship rules enforce methodology.
How later changes propagate
Automatic plus AI-invoked. Upstream change flags downstream links as suspect. Impact Analysis shows direct and indirect links. Engineer reviews and clears suspect. AI generates traceable test cases from requirements when invoked.
Changes to linked requirements flag suspect relationships for review. People initiate formal reviews and workflow transitions. Suspect-link and coverage reports identify records needing attention; they do not execute the implementation. Vendor documentation: Traceability ↗
What failure blocks
Configured workflow permissions and locks restrict transitions or edits. Suspect links and missing coverage were not established as automatic completion blockers. In Cloud 9.37, an organization-admin setting blocks review finalization when reviewed items are no longer current. Vendor documentation: Review-version gate ↗
How findings are resolved
People inspect suspect relationships, decide whether linked items need correction and clear the suspect state after review. The flag records a need to inspect changed dependencies, not proof of semantic disagreement with code.
Material migration limit
Interchange ReqIFz includes embedded HTML-field attachments but excludes attachment-widget files; baseline/filter exports do not round-trip. This qualifies that export route, not the ability to redeploy Jama. Vendor documentation: Interchange limits ↗
Edition and availability
Cloud and self-hosted editions differ in administration and upgrade responsibility. Interchange and AI assistance are separately described add-ons. The Interchange export limits above should not be assumed to describe every REST or document-export route. Vendor documentation: Product and add-ons ↗
Assessment against the seven properties
Lifecycle traceability Substantial
Configured typed, directional relationships connect requirements, design, risks and verification. Code relationships depend on the connected development tools; item types and relationship rules must be configured. The reviewed evidence does not establish the complete version-aware code/build leg of that chain. Vendor article: Traceability ↗
Versioned items, lifecycle states, baselines and signed reviews preserve an approved requirement/design set before implementation. The reviewed sources do not establish the delivered code version identifying its governing design baseline. Vendor documentation: Baselines ↗
Configured upstream-field changes mark relationships suspect. People assess impact, compare versions, correct items and clear the flag. This is a freshness/review mechanism; semantic implementation disagreement and tracked recheck against code were not established. Vendor documentation: Clear suspect links ↗
Invoked impact analysis follows maintained upstream/downstream relationships and degrees of separation. It supports assessing affected scope. Explicit comparison of design alternatives, constraints and trade-offs remains human work rather than an established analysis capability. Vendor documentation: Impact analysis ↗
Requirement-linked test cases have runs, results and history, with automation imports available. A test-case version is not the tested code version; the latter depends on the test/CI integration and was not established by the reviewed native test-run documentation. Vendor documentation: Test runs ↗
Baselines, signed reviews, item history and referenced test results support audit. Identifying the delivered build and its governing design baseline requires the connected development process; that complete association was not established. Vendor documentation: Electronic signatures ↗
Licensed self-hosted deployment supports continuing the configured relationship, baseline, review and test-management process on customer infrastructure, without the hosted Jama service. The same proprietary runtime can qualify; replacing it is not required. Connected code/test systems must be configured separately. Vendor article: Deployment choices ↗
Assessed configuration Configured Polarion ALM relationships, LiveDocs/Collections and build/test integration. On-premise ALM is distinct from Polarion X. Community workflow conditions are identified separately from native suspect links.
Workflow and records
Documents and records
LiveDocs specification documents (requirements, design, risk, test specs) with paragraph-level IDs; Work Items (requirement, change, task, bug, test case, test record, risk); baselines/collections/branches; approvals/e-signatures; traceability matrices.
What remains after delivery
Versioned work items. Baselines with comparison. Live-Branches with reuse/derive. Time machine history. Audit trails and signatures gate release.
How the parts link
Stakeholder -> system -> software -> test chain (ASPICE, ISO 26262). Structural parent-child in LiveDocs. Typed links (relates_to, verifies, derived_from). Cross-project and cross-repo links.
How later changes propagate
Automatic rule-based. Changed items mark links suspect (auto_suspect). Impact and traceability analysis before change. Workflow conditions can block Done until docs/tests attached. Must review and clear. No AI propagation step documented.
Native suspect-link settings flag changed relationships; this is separate from the community condition package. People invoke workflow actions and AI content checks. Configured workflow conditions run before a status transition; functions can run afterward. Vendor page: Workflow conditions ↗
What failure blocks
Configured conditions can prevent a workflow action. The cited condition package supplies additional checks, including suspect-link and test-record conditions, as a community extension. The reviewed Copilot AI checks were not established as mandatory transition gates. Do not assume every listed condition is part of the base installation.
How findings are resolved
Suspect relationships and linked work items support review and corrective work under configured workflows. Clearing a suspect state is a review action; it does not prove the implementation was checked against the design.
Material migration limit
The 2512 project ZIP export excludes version history. This is a limit of that export route. Process portability is assessed on the deployable runtime, not this export format. Vendor article: 2512 export ↗
Edition and availability
Distinguish on-premise Polarion ALM from Polarion X SaaS. The reviewed 2512 Copilot is a paid add-on for on-premise Hybrid SaaS-type licenses using a customer Azure-hosted OpenAI model. These are version-specific findings, not a claim that all later editions have the same limits.
Assessment against the seven properties
Lifecycle traceability Complete
Configured work-item roles/rules and LiveDocs connect requirements, design, code, test cases and test records. The project must configure the relationships and development/test integrations. Vendor page: ALM ↗
Versioned LiveDocs and hierarchical release/phase Collections retain approved requirements, design and tests, including future releases. Explicit association of each delivered code revision with the governing design Collection was not established by the reviewed sources. Vendor article: Concurrent V-model Collections ↗
Native suspect links flag affected relationships for review after changes. The official SDK exposes suspect state and automatic-suspect settings; this is not dependent on the community condition package. Clearing a flag does not establish semantic detection and tracked correction/recheck across code and design. Vendor documentation: Native suspect-link API ↗
Traceability views, typed relationships and versioned Collections expose affected scope and baselines. A documented assessment of design alternatives against constraints/trade-offs was not established. Human decisions and linked modelling tools remain distinct capabilities.
Requirement-linked test cases and individual records support coverage/results. Configured build/Jenkins integration runs executable tests and imports xUnit results into Test Runs, tying verification to the build context. Missing/unexecuted coverage and failure handling depend on the configured project and gates. Vendor article: Jenkins integration ↗
Collections, LiveDocs history, signatures, code links and test records preserve audit evidence. The configured Jenkins integration polls build number/status and imports results into Test Runs, providing build-linked evidence. The reviewed material does not establish the complete association of a delivered build with governing design revisions and applicable approvals/waivers. Vendor article: Collections ↗; Vendor article: Jenkins build/test integration ↗
Licensed on-premise Polarion can continue the configured ALM workflow on customer systems without Polarion X hosting. The proprietary runtime is deployable; external build/test/model integrations remain explicit dependencies rather than a data-export score. Vendor page: Deployment choices ↗
Assessed configuration Droid with Missions, AutoWiki, the generated QA skill, the documented GitHub Actions pull-request QA workflow and pull-request review configured. Factory Enterprise Airgap is a separate runtime; the complete connected QA workflow is not established there. The private-preview Software Factory dashboard and Release stage are excluded.
Workflow and records
Documents and records
Spec Mode plan (saved Markdown to .factory/docs or ~/.factory/specs if enabled); AGENTS.md; DESIGN.md guidance; .factory/skills/; Jira/Linear/Slack tickets; PRs; Mission plans.
What remains after delivery
Saved specs persist only if Save spec as Markdown enabled. AGENTS.md persists in git. Org/user memory persists across sessions. Plans survive compaction.
How the parts link
Ticket/prompt -> Spec Mode research plan -> approval -> Normal Mode implementation -> PR. AGENTS.md/DESIGN.md are always-on governance. Spec references linked artifacts and files. No requirement ID scheme documented.
How later changes propagate
Manual/AI-invoked. Approve Spec Mode plan via ExitSpecMode to implement. No evidence of auto-flagging lower artifacts when AGENTS.md changes. Must re-invoke Droid.
Droid hooks execute on configured lifecycle events. QA can be invoked with /qa or run on pull requests through a generated workflow. QA combines agent decisions with executable browser, CLI or API tests. Vendor documentation: Hooks ↗, Vendor documentation: QA workflow ↗
What failure blocks
The QA workflow can be configured as a required or optional check. Hook enforcement depends on event and configuration. A report of failed QA is distinct from a repository rule preventing merge. These mechanisms do not establish a supplied requirements-to-specification consistency check.
How findings are resolved
QA findings can drive code fixes and another test run. That loop verifies the tested change; the reviewed sources do not establish an equivalent tracked loop for disagreements across requirements and design records.
Edition and availability
Droid CLI and enterprise hybrid/airgapped deployments are distinct from the Software Factory dashboard, documented as private preview. Dashboard deployment and export properties must be verified separately. Vendor documentation: Dashboard availability ↗
Assessment against the seven properties
Lifecycle traceability Substantial
L2 met: Mission feature criteria link to commits and each feature is validated; L3 maintained version-aware lifecycle links remain unproven.
L2 met: an approved, resumable integrated feature/milestone target is maintained; L3 selected-version states and delivered-code design binding are missing.
L1 met: Mission planning defines constraints, features and success criteria before code; L2 scoped impact plus constrained alternatives are not documented.
L2 met: documented success criteria generate executable test flows and PR reports; L3 passed/failed/missing/unverified requirement states for tested code are missing.
L2 met: PR-triggered QA artifacts/reports and PR reviews are associated with workflow commit; L3 governing requirement/design versions and waiver references are missing.
Assessed configuration The official Jules service on the AI Ultra plan, using the web app, REST API, CLI and GitHub issue workflow. Jules is in Public Beta, runs tasks in Google-hosted short-lived VMs, and paid AI Plans are limited to individual Google Accounts.
The saved product notes provide background; the seven-property ratings and their evidence follow below.
Assessed configuration Devin Enterprise with Jira Cloud and a connected code repository, using Enterprise Cloud or Customer Dedicated Deployment. In Customer Dedicated Deployment, the Devbox runs in a customer-isolated VPC while the Brain remains in Cognition Cloud; this is not a self-hosted Devin factory.
The saved product notes provide background; the seven-property ratings and their evidence follow below.
problem to plan to code and test in its own VMs to PR, plus Slack and Teams and automation triggers; plan quality depends on prompt. Source: Vendor page: https://devin.ai/ ↗
Code/security findings and PR review are not documented as code/documentation mismatch or freshness alerts; Level 1 is unproven, so use ? rather than 0.
L1 met: a Jira work item starts Devin planning and returns a linked PR; Level 2 scoped impact and constrained alternatives are not documented together.
Design doc persists as record after merge. Design PR is committed. Tickets and PRs persist per project. No named local spec folder documented.
How the parts link
Brief -> design -> tickets -> PR waves -> verification. Approved design is source of truth. Worker briefs contain unit plus relevant design sections plus design doc link.
How later changes propagate
Agent-fleet check, human-gated. Review fleet verifies every draft against approved design before human review. Nothing implements until design approved. Must run Project Builder/Cosmos workflow. No local lint script found.
AI traceability matrix plus coverage analysis and defect traceability; matrix is deterministic, quality scoring is AI. Source: Vendor page: https://copilot4devops.com/ ↗
All files persist in repo. activeContext.md changes most often. progress.md reviewed on resume. projectbrief.md is foundation and source for scope. Updated after milestones.
How the parts link
projectbrief -> productContext/systemPatterns/techContext -> activeContext -> progress. Agent must read all files at start of every task. Large detail splits to linked docs.
How later changes propagate
AI-invoked. Commands: follow custom instructions, initialize memory bank, update memory bank (reviews all files). No script consistency check found. Auto-Compact preserves context but still needs manual update.
tasks.json and complexity report persist in repo. PRD remains source. Dashboard syncs with local repo as truth. Updates via CLI mutate tasks.
How the parts link
PRD -> tasks with stable IDs and dependencies arrays -> subtasks (parentId.subtaskId such as 5.2). testStrategy per task is verification contract. next selects by dependencies and status.
How later changes propagate
CLI/AI-invoked. update, update-task, update-subtask, expand realign tasks. analyze-complexity plus complexity-report guide expansion. Must invoke commands. No auto propagation.
Additional product covered by the saved research. The notes below are not a seven-property rating.
Workflow and records
Documents and records
AGENTS.md (project briefing, @-mentions to specs/docs, glob scoping); threads (T-..., synced to ampcode.com, private/team/public, fork/continue/compact/search); file changes/PRs.
What remains after delivery
AGENTS.md persists in git. Threads persist server-side, searchable, shareable, resumable across devices. Compaction summarizes to save context.
How the parts link
Governance (AGENTS.md) informs thread. Thread holds plan and execution context. @-mentions link specs/docs/threads. No defined requirement -> spec -> task derivation with IDs.
How later changes propagate
Manual. Ask Amp to update AGENTS.md from thread. Editing a prior message reverts later file changes. No cross-artifact suspect or consistency check found. Must invoke thread actions.
Assessed configuration Open-source Agent Canvas and Agent/Automation Servers on a supported self-hosted backend, with issue-to-PR automation, QA and Git Sync. OpenHands Cloud Planning Mode beta is excluded because the reviewed sources do not establish that workflow for self-hosted Canvas.
This assessment uses the documented self-hosted Agent Canvas and Agent/Automation Servers workflow on supported backends. It includes issue-to-PR automation, QA and Git Sync. The Cloud Planning Mode beta is outside this configuration because the reviewed documentation does not show it continuing on self-hosted Canvas.
L1 met: issue acceptance criteria and dependencies feed the PR workflow and the PR links back to the issue; L2 design/code relationship or version context is missing.
Cloud Planning Mode is beta and not documented in the selected self-hosted configuration; its L1 persistent design anchor is therefore not demonstrated; no restriction supports 0.