corp-v1-3darch-skills-code-agent/corp-v1-channel-scope-3darch
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
8780776ec83d6b9f1e200a1272531c932fb7cff7
corp-v1-channel-scope-3darch/SKILL.md
T

32 KiB
Raw Blame History

name, description, version, author, license, metadata
name description version author license metadata
corp-v1-channel-scope-3darch Use when operating or synchronizing a Corp v1 project's Scope channel. Owns Roadmap, Epics, Features, and Ideas; correlates all seven same-project channels; proactively improves evidence-based product scope; and records human approval before work enters Architecture solution design. 1.5.5 Hermes Agent MIT
hermes
tags related_skills
corp-v1
discord
channel
scope
roadmap
epics
features
discovery
corp-v1-main
home-v1-discord
documentation-docusaurus
corp-v1-glossary

Corp v1 Scope Channel

3D Architecture Wizzard Project Adoption

This is the primary project-adopted skill for 3D Architecture Wizzard (3darch).

Project engineering peers:

Mapped Discord channel: corp-v1-3darch-scope (1543925247361814568).

Overview

This skill owns product discovery and durable scope for a Corp v1 project's scope channel. It monitors the seven same-project channels—general, scope, architecture, ui-ux, kanban, delivery, and releases—and maintains the project documentation's top-level Scope area.

Scope owns Overview, Roadmap, Epics, Features, canonical Task records/reader pages, Ideas, and Questions. General coordinates overall project awareness but does not duplicate Scope records. Architecture performs solution work only for Features explicitly approved for solution by a human team member and remains semantic owner of requirement/task derivation, dependencies, and readiness. Hermes participates proactively by proposing and refining useful scope, but never approves its own proposals.

Load the global documentation-docusaurus skill from https://gitea.lego-cloud.eu/home-v1-skills-code-agent/documentation-docusaurus before changing documentation structure, navigation, Markdown/MDX, Docusaurus configuration, or builds.

Load the global corp-v1-glossary skill from https://gitea.lego-cloud.eu/home-v1-skills-code-agent/corp-v1-glossary whenever project documentation needs to define or explain a reusable term. Maintain one canonical definition in the project's final top-level Glossary area and link to it from the owning domain page; do not duplicate glossary-style explanations across channel documentation.

Shared Corp v1 System Login

When an authorized task requires login to a Corp v1 system being built or operated, follow the shared policy in corp-v1-main and use only the Bitwarden-injected runtime secrets named:

HL_V1_SSO_EMAIL
HL_V1_SSO_PASSWORD

Secret availability is capability, not authorization. Verify the destination origin and task purpose before login. Never print, inspect, log, hash, serialize, paste, screenshot, or persist either value; never place a value in a command line, URL, file, repository, prompt, Discord message, browser console, test fixture, CI output, or generated artifact. Never ask a human to paste a value into chat. If a variable is unavailable, report only its missing name and request Bitwarden/gateway injection. Login does not authorize account recovery, MFA or credential changes, permission changes, billing, spending, destructive operations, or access outside the approved project task.

When to Use

Use this skill when:

  • operating in corp-v1-<code>-scope;
  • running its recurring synchronization job;
  • maintaining Overview, Roadmap, Epics, Features, canonical Task reader pages, Ideas, or Questions;
  • discovering user/project problems and opportunities;
  • refining value, scope, acceptance outcomes, dependencies, or risks;
  • preparing an Epic or Feature for human Approved for Solution review;
  • reconciling scope against architecture, Kanban, delivery, or release evidence.

Do not use it to design architecture, approve solution entry, approve implementation, admit tasks to Kanban Focus, implement code, or authorize releases.

Approved Information Boundary

Inspect only:

corp-v1-<code>-general
corp-v1-<code>-scope
corp-v1-<code>-architecture
corp-v1-<code>-ui-ux
corp-v1-<code>-kanban
corp-v1-<code>-delivery
corp-v1-<code>-releases

Read enough Scope history to avoid duplicates and only relevant new activity from the other six channels. Never inspect or correlate another project's channels.

Human Approval Gate

Only a human team member may move an Epic or Feature to Approved for Solution. Hermes may propose, investigate, refine, deduplicate, identify dependencies, prepare acceptance outcomes, and recommend approval. Silence, an agent statement, CI success, delivery activity, or a forecast is not approval.

Record approver identity, decision evidence, date, resulting status, and conditions. Architecture may begin solution work only after this evidence exists.

Documentation Contract

Scope is a top-level menu item immediately before Architecture, with its own dedicated sidebar:

Overview
Roadmap
Ideas
  <CODE>-IDEA-1
  ...
Questions
  Q-0001
  ...
Epics
  <CODE>-EP-1
    Features
      <CODE>-FT-1
        Tasks
          <CODE>-TS-1
          ...
      <CODE>-FT-2
  <CODE>-EP-2
    ...

Within Epics, the exact reader hierarchy is Epics → Epic → Features → Feature → Tasks. Features and Tasks are explicit grouping/navigation levels, not flattened labels. Every Task has a separate canonical reader page nested under its owning Feature; no aggregate task list may substitute for those pages.

The project documentation's Ways of Working area must contain a separate first sidebar item named Scope explaining the ticket hierarchy, delivery statuses, exact/derived authority, roll-up, blockers, cancellation, dependencies, gates, and evidence rules.

Roadmap

Show verified current state and predicted plans at Epic and Feature level. Distinguish approved/current facts from forecasts and proposals. Include sequence or horizon, status, dependencies, material blockers, owner, and last evidence/update date.

Overview

Maintain a dedicated Overview page at canonical route /scope/overview/ as the first item in the Scope sidebar. It contains the Issue Status Matrix and is the complete operational index for every governed Idea, Epic, Feature, and Task; it is not a manually curated subset and does not replace the detailed records. Do not retain an /scope/issues/ source, route, redirect, or navigation ID.

Generate the matrix from the same validated canonical data and status selector used by Roadmap and Board views. Include every item, including DONE and CANCELLED, with at least:

ID | type | title | direct parent/resulting scope | delivery status | EXACT/DERIVED | blocked flag/reason | owner | approval gates | required children | dependencies | release/deployment evidence | last evidenced transition | canonical record link

Provide type/status totals and filters. Render exactly one semantic matrix table: it initially contains every governed record, and search/type/status controls narrow that same table. Do not add a second “complete unfiltered” disclosure or duplicate table. Keep the current table usable for print, accessibility, and no-JavaScript output. Sort deterministically by hierarchy and stable ID. Link every row to its canonical record and every relationship to the resolved target record.

Fail validation when any canonical item is absent or duplicated; a required relationship is dangling, one-sided, or double-counted; a status is invalid for the item type; status_source is missing or wrong; a derived status disagrees with the unified roll-up algorithm; a blocked item lacks a reason; or a transition/evidence link is not durable. The page must expose stale or contradictory states rather than silently filtering them out.

Any canonical status, relationship, gate, owner, blocker, or evidence change must update Overview in the same reviewed change. Acceptance requires selector/table count parity, type/status total parity, link validation, keyboard and screen-reader access, strict production build, browser console/network health, and remote exact-head readback.

Epics, Features, and Tasks

Use stable project-scoped reader IDs. Keep canonical identity and reader display identity as separate fields whenever the repository data model already distinguishes them:

Epic:    <UPPERCASE_PROJECT_CODE>-EP-<NUMBER>
Feature: <UPPERCASE_PROJECT_CODE>-FT-<NUMBER>
Task canonical ID: TASK-<ZERO_PADDED_NUMBER>
Task display ID: <UPPERCASE_PROJECT_CODE>-TS-<NUMBER>

Allocate reader numbers monotonically. Never reuse or renumber an Epic or Feature ID, a Task display ID, or a canonical record ID after rejection, deferral, deletion, or consolidation. Every Task requires explicit canonical_id: TASK-<ZERO_PADDED_NUMBER> and display_id: <UPPERCASE_PROJECT_CODE>-TS-<NUMBER> fields. Bind dependencies, links, event histories, evidence, and append-only hashes to canonical_id; use display_id only for reader-facing navigation and labels. Existing Task canonical IDs never change. Allocate canonical identity for new Tasks through the repository's canonical data model; never infer it from a sidebar label or display ID.

Minimum Epic fields:

ID | title | problem/opportunity | intended outcome | value | status | owner | Feature links | evidence

Minimum Feature fields:

ID | Epic | user/problem statement | expected value | scope | acceptance outcomes | status | owner | dependencies | risks | evidence

Each Epic page uses a concise reader card showing the unified delivery status, owner, goal, benefit, problem/opportunity, constraints, clickable child-Feature tags, and original source, followed by its Features group. Do not expose legacy aliases, decision-history tables, a separate Feature-set completeness review, or a Canonical product questions section on the reader page. Each Feature page contains title, description, value, scope, acceptance outcomes, dependencies, risks, human approval evidence, Architecture requirement/readiness traceability, and a Tasks group linking every canonical child Task page.

Scope is the canonical Task record and reader-page host, while Architecture remains semantic owner of task derivation, dependencies, and readiness. Kanban and Delivery own task flow and execution evidence. Synchronize those dimensions into the Scope reader without duplicating ownership or inventing transitions. Store canonical Task identity and project-scoped display identity in explicit separate fields. During display-ID migration, preserve historic canonical identities, aliases, evidence, and append-only hashes; do not rewrite historical events or hashes solely to replace a legacy display name.

Approval is a gate, not a delivery status. Preserve Approved for Solution, implementation approval, conditions, and decision evidence in dedicated fields and append-only histories; do not overload the item's delivery status with approval language.

Ideas

Ideas are early opportunities not yet accepted as Epics or Features. Record stable local reference, title, goal, benefit, source, owner when known, unified delivery status, and resulting Epic/Feature links. Preserve provenance after promotion. The Ideas parent page and each Idea child page must be visible in the Scope sidebar and use a readable card/detail layout rather than tables. Reader metadata shows status and owner, not disposition; never present Recorded, promotion wording, or an approval gate as the delivery status.

Questions

Questions are governed product decisions, separate from delivery status and approval. Keep a Questions parent page and one sidebar-visible child page per canonical Question. Show the question, why it matters, affected scope, owner, status, answer when available, and original source without using tables.

Render affected or resulting governed records as a borderless vertical list of ordinary links, sorted deterministically by entity type and canonical ID. Every governed record is a separate list row containing exactly one full-surface anchor to that record's canonical documentation URL; never combine multiple IDs or links into one visual item, synthesize a URL from the ID, or surround the relationship section/link with card or tag borders. Each link shows entity type, canonical ID, title, and a directional cue, with underlining, row spacing, pointer cursor, enabled pointer events, keyboard focus treatment, and an accessible label. Validate every generated Idea page by counting separate anchors, requiring one unique valid target per row, proving every target route exists, and checking deployed HTML and CSS together. Label reader-facing source sections Original source, not Evidence. For Discord sources, render each link as Discord – <Channel name> – <Author> while retaining the exact source-message URL.

Published stylesheet URLs must be derived from the actual CSS byte-content hash so changed reader CSS cannot reuse an immutable cached URL. Stage the complete Pages site, verify the staged stylesheet bytes and filename hash, and atomically replace the deployed directory; never publish by deleting the live directory and copying files into it incrementally.

The Epic registry graph must not expose a View accessible data table disclosure. Keep Epic nodes keyboard-accessible, labelled, and linked to canonical records; use the detailed Epic and Feature pages as the reader surface.

Do not maintain a separate Product Register page. Overview and the canonical Epic, Feature, Idea, and Question pages are the product lookup surfaces.

Unified delivery lifecycle and roll-up

Use one delivery vocabulary across Ideas, Epics, Features, and Tasks while preserving the difference between product design/delivery and task execution.

Product items use:

Idea, Epic, Feature: IN_BACKLOG → IN_DESIGN → IN_DELIVERY → TO_BE_RELEASED → DONE

Tasks use:

Task: IN_BACKLOG → IN_PROGRESS → TO_BE_RELEASED → DONE

CANCELLED is an explicit exceptional terminal state for every item type. BLOCKED is an orthogonal flag with a reason and evidence, never a lifecycle status. Do not use READY, QUEUED, Proposed, Approved for Solution, or Approved for Implementation as delivery statuses.

Status meaning

  • IN_BACKLOG: retained but not actively designed or executed.
  • IN_DESIGN: an Idea, Epic, or Feature is actively being scoped, decomposed, or solutioned; no required implementation Task has started.
  • IN_PROGRESS: a Task is actively being implemented or validated.
  • IN_DELIVERY: implementation of a product item's governed descendant scope has started, or part of that scope is already later in the delivery chain while the complete product item has not reached TO_BE_RELEASED.
  • TO_BE_RELEASED: the complete required scope is implementation-complete and belongs to a release candidate, but release verification is not complete.
  • DONE: the complete required scope has passed its release boundary, or an explicitly non-releasable item has durable completion evidence.
  • CANCELLED: an authorized decision removed, rejected, abandoned, or superseded the item. Cancellation never means done.

Canonical relationships

Maintain one validated roll-up set at each boundary:

Idea    → directly resulting Epics and/or Features
Epic    → required child Features
Feature → required implementation Tasks

When an Idea points to both an Epic and one of that Epic's Features, mark only one level as a roll-up target so the same work is not counted twice. Distinguish required children from optional, removed, or superseded children. A cancelled child may be excluded only by an explicit scope decision that updates the parent's required set; never count CANCELLED as DONE.

Deterministic parent aggregation

Derive Idea status from its validated direct resulting-item set, Epic status from required Features, and Feature status from required Tasks. Evaluate these rules in order:

  1. CANCELLED is never derived; it requires an explicit authorized item decision.
  2. If the required-child set is non-empty and every required child is DONE, the parent is DONE.
  3. Otherwise, if every required child is either TO_BE_RELEASED or DONE and at least one is TO_BE_RELEASED, the parent is TO_BE_RELEASED.
  4. Otherwise, if any required descendant has entered active or later execution—Task IN_PROGRESS, or child IN_DELIVERY, TO_BE_RELEASED, or DONE—the parent is IN_DELIVERY.
  5. Otherwise, an actively scoped, decomposed, or solutioned product item is IN_DESIGN.
  6. Otherwise, the parent is IN_BACKLOG.

An item with no validated required children cannot derive TO_BE_RELEASED or DONE; require direct evidence for the exact item. A parent must never appear less advanced than an active required child. Mark every computed status with status_source: DERIVED; exact Task transitions and direct no-child decisions use status_source: EXACT.

Transition and evidence rules

  • Product items normally move IN_BACKLOG → IN_DESIGN; they move to IN_DELIVERY when required descendant implementation starts.
  • Tasks normally move IN_BACKLOG → IN_PROGRESS → TO_BE_RELEASED → DONE.
  • A Task may move directly from IN_PROGRESS to DONE only when its outcome is explicitly non-releasable or the same evidence proves implementation and release completion; record the reason.
  • Moving the final required child can trigger deterministic parent roll-up in the same canonical change, but never fabricate missing relationships or evidence.
  • Promotion does not finish an Idea. A promoted Idea remains linked to its resulting items and follows their aggregate delivery status until their required outcome is DONE.
  • Documentation activity, approval, CI success, merge state, deployment health, or silence alone does not advance status. Every exact transition requires actor, authority, UTC date, previous and target state, conditions, and durable evidence.
  • Keep approval, blocking, acceptance evidence, version allocation, deployment, and release records separate from lifecycle status even when they supply transition evidence.
  • Preserve append-only historical approval/lifecycle events during migration. Convert old approval-shaped status fields into approval gates and establish the new delivery status with a new evidenced event; do not rewrite history.

React Flow visualization contract

When Scope documentation contains relationship-dense data, deliberately consider a read-only @xyflow/react view after loading documentation-docusaurus and its React Flow guidance. Appropriate Scope views include:

  • Epic-to-Feature composition;
  • Feature-to-Feature dependencies;
  • Feature-to-question readiness relationships;
  • Requirement-to-Feature and Architecture-Decision-to-Feature traceability;
  • roadmap sequencing and a deterministic Gantt-like timeline when approved dates and lanes exist.

Render a visualization only when the required relationships, dates, lanes, and states exist in validated canonical YAML and the graph materially improves comprehension. A small, linear, empty, or weakly connected dataset should remain a semantic table or list. A graph must not infer unapproved dependencies, dates, hierarchy, readiness, approval, critical path, or progress.

Use one typed, deterministic adapter and the same selector to produce stable nodes, edges, legends, validation warnings, and an adjacent semantic table fallback. Generated graph data, coordinates, viewport state, and client state are derived presentation data, never a second source of truth. Preserve exact relationship semantics: questions, blockers, dependencies, decisions, approval conditions, and readiness are distinct concepts and edge types.

Use Dagre for ordinary directed graphs and ELK only for complex or grouped graphs. Derive Gantt-like positions deterministically from approved dates and lanes. Use Docusaurus BrowserOnly where client-only rendering is required, while keeping the semantic fallback server-renderable, searchable, linkable, and usable if JavaScript or hydration fails.

Documentation canvases are read-only. Disable mutation affordances, including nodesDraggable={false}, nodesConnectable={false}, connection creation, deletion, and accidental persistence. Preserve keyboard navigation, meaningful accessible labels and authoritative-record links, visible focus, non-color-only meaning, reduced-motion behavior, responsive controls, and sharp styling with border-radius: 0.

Acceptance requires canonical-YAML validation, graph/table parity where a semantic table is part of the intended view, stable deterministic output, missing-reference failure or explicit warning behavior, empty/loading/error states, keyboard and screen-reader checks, production build, browser console/network health, and remote exact-head verification. The Epic registry intentionally omits the expandable table disclosure and instead requires keyboard-accessible linked nodes plus canonical detail pages. React Flow supplements the Roadmap, Epic/Feature records, and semantic tables; it never replaces governed Scope records.

Proactive Iteration Requirement

Every Scope iteration must add or materially improve at least one evidence-based scope artifact when a safe path exists: a grounded Idea, Epic, or Feature; clearer value or acceptance outcomes; dependency/risk evidence; deduplication; Roadmap reconciliation; cross-links; or a concrete unanswered product question. Never create filler to satisfy cadence.

Use evidence from all seven same-project channels. Delivery and release outcomes may expose new Ideas or required scope corrections; Architecture may expose infeasible assumptions; Kanban may expose flow or dependency problems. Preserve authority boundaries while incorporating that evidence.

Handoffs

  • Scope → Architecture: only human-approved Features with stable ID, parent Epic, value, scope, acceptance outcomes, dependencies, risks, and approval evidence.
  • Architecture → Scope: feasibility constraints, requirement implications, dependencies, and proposed scope clarifications; Architecture does not silently rewrite product scope.
  • Scope → Kanban: stable Idea/Epic/Feature identities, required-child relationships, approval gates, and unified delivery status for Board/Focus reconciliation.
  • Delivery/Releases → Scope: verified outcomes, regressions, user feedback, and follow-up opportunities that may alter the Roadmap or create Ideas.
  • Scope → General: concise overall implications, decisions requiring visibility, owners, and cross-channel blockers.

UI/UX Coordination

Scope supplies UI/UX with stable Feature identity, user problems, value, acceptance outcomes, and approval evidence. UI/UX may explore proposals but only an approved design package may become implementation-readiness evidence; Scope remains authoritative for product outcome and disposition.

Synchronization Workflow

  1. Confirm the exact project code and seven approved channel IDs.
  2. Read new activity from the other six channels and enough Scope history to avoid duplication.
  3. Separate verified facts, human decisions, proposals, forecasts, and unresolved questions.
  4. Inspect Overview, Roadmap, Ideas, Questions, the exact Epics → Epic → Features → Feature → Tasks hierarchy, every separate Task reader page, links, IDs, unified delivery statuses, required-child roll-ups, and approval evidence.
  5. Reconcile architecture feasibility, Kanban flow, delivery progress, and release outcomes against scope.
  6. Add or materially improve at least one useful evidence-based artifact, or document the exact evidence/approval blocker.
  7. Load documentation-docusaurus and the project CI/CD skill. Run only fast, dependency-free local preflight checks such as schema/parity scripts, targeted tests already available, git diff --check, and secret scanning. Do not spend the working session installing dependencies or repeatedly running the full documentation build locally when PR-triggered Gitea Actions can provide the authoritative environment.
  8. Push the smallest coherent reviewable branch early and open or refresh its PR. The PR workflow must install dependencies and run the complete canonical-data validation, tests, typecheck, strict production build, and built-site assertions without publishing. Wait for the run attached to the exact pushed SHA; inspect failed job steps and logs, fix only evidenced defects, push, and repeat until that exact head is green.
  9. Review the exact CI-green head, merge through the repository workflow, then require default-head CI/publication success and deployed remote readback before reporting completion. Never treat a local build, a stale run, or CI for another SHA as acceptance evidence.
  10. Post a concise Scope update. When verification is successful and the human did not ask for delivery evidence, report only the substantive changes and the reader-facing documentation link; omit routine test, build, CI, audit, PR, run, commit, and SHA details. Internal validation and immutable evidence remain mandatory. Include technical evidence only when requested or when a failure, blocker, or unresolved publication state makes it actionable. Handoff packets retain their explicit evidence contract. Prefer the most specific verified documentation route, and include the portal landing page when several pages changed. If default-head publication or page-body verification is still pending, say so instead of presenting the route as published, then provide the documentation link in the completion follow-up. Stay silent when no substantive result exists.

Authority and Escalation

May autonomously:

  • summarize verified same-project scope implications;
  • propose and refine Ideas, Epics, and Features;
  • maintain Roadmap mechanics, links, IDs, and evidence;
  • record explicit human decisions;
  • run read-only checks and documentation validation;
  • repair clear non-semantic documentation defects.

Requires human approval for:

  • moving an Epic or Feature to Approved for Solution;
  • materially accepting/rejecting product scope;
  • changing governance, architecture, implementation, version, or release decisions;
  • permissions, credentials, spending, external contact, or irreversible/high-impact work.

Common Pitfalls

  1. Treating General as the authoritative owner of Scope records.
  2. Approving a proposal because nobody objected.
  3. Creating Epics or Features without evidence, value, acceptance outcomes, owner, or dependencies.
  4. Using generic IDs instead of project-scoped stable IDs.
  5. Treating Scope's canonical Task reader pages as ownership of derivation/readiness, which remains with Architecture, or of flow, which remains with Kanban/Delivery.
  6. Mixing approved/current state with predictions in the Roadmap.
  7. Ignoring Architecture, Kanban, Delivery, or Releases evidence.
  8. Inspecting another project's channels.
  9. Posting repetitive status instead of improving durable documentation.
  10. Claiming completion without build and remote readback evidence.
  11. Keeping a complete documentation build local by default instead of delegating dependency installation, full validation, typecheck, tests, and production build to PR-triggered Gitea Actions.
  12. Reading only a PR badge or latest run without proving the run's head_sha equals the pushed candidate SHA.
  13. Treating approval names as delivery statuses instead of separate gates.
  14. Marking an Idea DONE merely because it was promoted, rather than rolling up its governed resulting items.
  15. Deriving a parent from an incomplete, duplicated, or unvalidated child set.
  16. Counting a cancelled child as done or silently excluding it without an explicit scope decision.
  17. Moving a parent to TO_BE_RELEASED while any required child remains in backlog, design, active delivery, or progress.
  18. Flattening the reader hierarchy by placing Features directly under an Epic or Tasks outside their owning Feature's Tasks group.
  19. Rewriting historic canonical identities, evidence, or append-only hashes solely to adopt <UPPERCASE_PROJECT_CODE>-TS-<NUMBER> display IDs.
  20. Reporting a merged documentation PR as the latest work without giving the reader a direct link to the verified documentation portal page.
  21. Spamming a successful Scope completion with routine CI, test, PR, run, commit, or SHA details when the human asked only for the outcome and documentation link.

Verification Checklist

  • Only the seven same-project channels were inspected.
  • Scope appears immediately before Architecture with its own sidebar.
  • Sidebar order is Overview, Roadmap, Ideas with child pages, Questions with child pages, then the exact Epics → Epic → Features → Feature → Tasks hierarchy.
  • Ways of Working starts with a separate Scope page explaining the ticket hierarchy and governed statuses.
  • Ideas and Questions use table-free parent/child pages; no Product Register page exists.
  • Roadmap distinguishes verified current state from predicted plans.
  • Epics, Features, and Tasks use stable project-scoped IDs and valid parent-child links; Task display IDs use <UPPERCASE_PROJECT_CODE>-TS-<NUMBER>.
  • Every Epic has an explicit Features group; every Feature has an explicit Tasks group; every Task has a separate canonical Scope reader page.
  • Scope hosts Task readers, Architecture owns derivation/dependencies/readiness, and Kanban/Delivery own flow.
  • Display-ID migration preserves historic canonical identities, evidence, aliases, and append-only hashes.
  • Ideas preserve provenance when promoted.
  • Every item uses the governed status vocabulary for its type; approval, blocking, and release evidence remain separate fields.
  • Idea, Epic, and Feature roll-ups use complete validated required-child sets with no ancestor/descendant double counting.
  • Every derived status follows the ordered aggregation rules and is labelled DERIVED; exact transitions are labelled EXACT.
  • No parent is TO_BE_RELEASED or DONE while a required child is earlier than that aggregate permits.
  • At least one useful artifact was improved, or an exact evidence/approval blocker was recorded.
  • No Epic or Feature entered Approved for Solution without explicit human evidence.
  • Architecture handoff contains value, scope, acceptance outcomes, dependencies, risks, and approval evidence.
  • Documentation build, links, and remote readback passed.
  • Every latest-work update that reports a merged documentation PR includes the relevant verified documentation portal link.
  • A successful unrequested completion report contains only substantive changes and documentation links; technical delivery evidence appears only on request or for an actionable exception.
  • When React Flow is used, its graph and semantic table share one canonical-YAML selector and pass accessibility, build, browser, and remote exact-head checks.
  • Completed work includes exact message, path, commit, URL, or run evidence.
Reference in New Issue View Git Blame Copy Permalink