Understand the My Architect project model
My Architect connects what the product does with the work needed to change it. The product catalog describes lasting capabilities. The work hierarchy describes outcomes and tasks. Requirements and documents explain their constraints, while claims and delivery records show who is working and what has been verified.
Product features and work items
Section titled “Product features and work items”A product feature has a stable identity and a place in the product’s areas. “Payment recovery” can remain one capability across many changes. Search that catalog before creating another feature with a similar name.
A work item describes a change: for example, adding a retry action to payment recovery. Work is organized using the project’s hierarchy preset. Its node ID is different from the product-feature ID. Explicit impact links connect work to affected capabilities; one epic can affect several features.
Specification evolution distinguishes current behavior from proposed changes and their base version. A proposal in the backlog is not automatically the current specification. Read the relevant versions and source documents when planning a change.
Requirements
Section titled “Requirements”Requirements express obligations and decisions:
| Type | Purpose |
|---|---|
| FR | Functional behavior and acceptance conditions |
| NFR | Quality requirements, with metrics and verification methods where applicable |
| SAR | Architecture decisions, their rationale, alternatives, and consequences |
| ASR | Requirements significant enough to influence the architecture |
| CON | Constraints such as external limits or mandated choices |
| OQ | Open questions that still need a decision |
Requirements may be owned by a work node or apply at project level. Links and inheritance determine their relevance to a task. Recorded statuses include draft, approved, done, and deprecated; a status alone does not prove that an external implementation satisfies the requirement.
Use scoped context to read the mandatory requirement manifest, exact versions, and explicit source gaps.
Documents, diagrams, and releases
Section titled “Documents, diagrams, and releases”Documents preserve specifications, decisions, plans, and evidence. Link the canonical source instead of copying competing versions into several tasks. Preserve a source artifact separately when a preview is derived from it.
Supported diagram types are WBS, User Story Mapping, Event Storming, and Box. WBS and story-map views help explain the hierarchy; Event Storming models behavior and open questions. Box diagrams express structural relationships. Choose the diagram that clarifies the actual task.
Releases group delivery work. A release assignment or progress rollup describes the model; it does not confirm that the release is deployed.
Claims and delivery
Section titled “Claims and delivery”The shared epic flow has four stages: queued, in-progress, review, and delivered. A coordinator claim identifies the epic’s current holder. Independent child claims let workers own separate leaf tasks without taking the coordinator’s role.
An actor label records attribution under the existing project authorization. It is not a separately authenticated human identity or a lock on source files.
Legacy hierarchy statuses, including done, remain distinct from epic delivery. Review records evidence for a specific artifact; confirmation applies the accepted delivery policy. The server checks modeled state and attributed references, while reviewers still inspect the actual results.
Follow project workflow for planning, multi-agent coordination for ownership, and verify delivery for acceptance.
Verified against app/MCP 1.11.0 and workflow plugin 2.6.0 on October 13, 2026. Confirm the connected server’s capabilities before applying a procedure.