amaa-prrd-trdd-kanban

Overview

The ARCHITECT (AMAA) layer of the PRRD / TRDD / Kanban model. ARCH owns the design column — the only column with a 1→N (split) and N→1 (group) topology. A proto-TRDD comes in from ORCH; one or more fully-designed TRDDs land in dispatch.

This skill is the ARCHITECT judgment layer only — it owns no mechanics. Every pillar operation goes through the core ama-* skills in ai-maestro-plugin: ama-kanban-render (see the board), ama-trdd-find (search), ama-trdd-write (author), ama-trdd-update (edit fields), ama-trdd-transition (move a card), ama-prrd-get / ama-prrd-find (read rules), ama-prrd-propose (propose a rule), ama-proposal-approvals (approve/refuse). What lives here is the split / group / pass-through decision, which no core skill can make for you.

ARCH self-mandates all within-team design work — pass-through, split, group, setting design frontmatter — writing min-approval-requirement: none, mandate: true, mandated-by: self and proceeding immediately. No approval round-trip exists to wait for.

Higher requirements (chief-of-staff / manager / user) apply to force-superseded outside a normal split, editing TRDDs already past design, and anything crossing a team/project, release, baseline or governance boundary. File those to design/proposals/ and MOVE ON — D1 never-block: you do not spin-wait on an approver, ever.

approval-tier: N is deprecated, decode-only, never written on a new TRDD; name the governance title instead. Legacy files migrate on next touch, never in a mass rewrite. A file carries exactly one of the two.

Prerequisites

• The core ama-* skills from ai-maestro-plugin are available — they carry the mechanics, the 17-column transition rules, and the approval vocabulary.
• The project PRRD exists and design/tasks/ is present.
• A proto-TRDD sits in the design column awaiting ARCH.

Instructions

1. Read the proto-TRDD body (the paraphrased user request).
2. Set task-type: (feature / bugfix / refactor / docs / infra / security / artifact / spike / audit).
3. Set severity: and effort: from judgment.
4. Set release-via: (publish for tools/packages, deploy for services, none for internal-only).
5. Set test-requirements:, audit-requirements:, review-requirements: (which test/scan/review types are mandatory).
6. If artifact-producing, set artifact-kinds:; set runtime-targets: (platforms that must pass) and impacts: (install / dependencies / config / migration / public-api / ci-pipeline). 6b. Set the approval fields on every TRDD you author: min-approval-requirement: (the governance title — none for in-scope design work), and when you are issuing it on your own authority, mandate: true + mandated-by: self. Record the no-round-trip line in ## Approval log. Never write approval-tier:.
7. Identify NPT children — prerequisites that must complete BEFORE the parent's dev. Author each as a separate TRDD; link via npt:. Each child is depth-1: derived: true, derived-kind: npt, parent-trdd: set, and its own npt:/eht: EMPTY. Siblings order via blocked-by:.
8. Identify EHT children — consequence-handling tasks that must complete BEFORE the parent's complete. Link via eht:; same depth-1 field set with derived-kind: eht. 8b. Completion gate. The parent reaches column: complete only when every id in npt: ∪ eht: sits in a terminal column (complete/published/live/superseded). Otherwise it is blocked, with blocked-by: naming the open children and pre-block-column: recording where it was. "Complete pending EHTs" is not a state — the parent's own tests going green is not completion.
9. Decide topology: pass-through (#4 design → dispatch), 1→N split (#5 parent → superseded, N children to dispatch), or N→1 group (one combined TRDD supersedes the inputs).
10. Write the body: ## STATE (if multi-session), ## Acceptance criteria (testable bullets), ## Design notes, ## Out of scope; cite rules in relevant-rules:.
11. Move on: pass-through sets column: dispatch, assignee: null, bumps updated:. On split/group, mark the parent/inputs column: superseded with superseded-by: [<child-refs>].