[Work model] Add minimal item types and optional parent hierarchy after the model ADR

[Chris0Jeky]

Delivery

Completed by #2932 (true archive/restore), #2949 (Task/Epic/Spike), and #2965 (same-board hierarchy). Final hierarchy merge: 86c6f1bdf9914b7809e77183187b8e94659acc39; Required CI 34540544226 passed at reviewed head 2d0fa2116a003bbe72fe5c193f55ffa0448de6c6. The closure receipt records proof, limits and separately tracked follow-ups. Optional confirmed subtree archive is outside the delivered default-detach scope.

Original problem and evidence

Current Card has no work-item type or parent relation: backend/src/Taskdeck.Domain/Entities/Card.cs:6-55 and docs/architecture/DATA_MODEL.md:216-234. Dogfooding needs a small distinction between tasks, epics, and spikes plus parent/child decomposition. Typed arbitrary relations, templates, recurrence, and multi-board placement are separate concepts.

Scope

After the canonical work-model ADR is Accepted:

• Add the smallest accepted WorkItemType set.
• Add one optional parent relation on the Card-compatible path.
• Enforce same-owner/scope rules, cycle prevention, and a documented depth policy.
• Expose type and parent in API/UI, proposal diff/apply, audit, export/import, deletion, MCP, and realtime.
• Preserve existing card IDs and default all existing records to the accepted task-compatible type.

Non-goals

• No typed non-hierarchical relation table.
• No multiple parents, graph database, or cross-project hierarchy unless explicitly accepted.
• No templates, recurrence engine, custom fields, work logs, or multi-board canonical item.
• No Workspace/Project migration in this slice.

Acceptance

• The issue is not started until the model ADR records the first types and hierarchy boundary.
• Existing cards migrate deterministically and retain IDs, board/column placement, history, and exports.
• Parent cycles and forbidden cross-boundary links fail server-side with stable errors.
• Proposal preview and apply support type/parent changes with exact parity.
• Deleting/archiving a parent has explicit child behavior and no silent cascade.
• API, UI, audit, export/import/account deletion, MCP, realtime, migration bootstrap, and rollback tests pass.

Cross-cutting impact

Surface	Requirement
Data/migration	Reversible EF Core/SQLite migration with safe defaults and indexes
API/UI	Backward-compatible DTOs and progressive-disclosure controls
Proposal/review/apply	New operations validated in preview and executor
Provenance/audit/actor	Parent/type changes and spawned work remain attributable
Permissions/security	Server-side scope and cycle validation
Export/import/deletion	Round-trip hierarchy and defined parent deletion behavior
MCP/agent	Reads and proposal-only writes; no direct agent mutation
Realtime/concurrency	Board invalidation and optimistic conflict behavior
Tests	Domain, application, API, migration, export, MCP, frontend, and E2E

Dependencies and release

Depends on #2084 and its Accepted canonical work-model ADR. Related to #1947. v0.4, Priority III. ADR-0060 is Accepted; the maintainer clarified true archive/restore and a depth limit of three links/four levels on September 10.

Compatibility and rollback

The migration must retain the current Card contract and provide a tested down path before release.

[Chris0Jeky]

Blocking condition satisfied — ADR-0060 now records the first types and the hierarchy boundary

ADR-0060 was ratified by the maintainer in-session on 2026-08-29 (guided-walkthrough reply q-2 B, decision map map:v1:3b5e90e6a5e9b97b362dbe5d8412b699b742818a054edd8443515fc2c2dfe3e7, recorded on #2084). This issue's acceptance line 1 — "The issue is not started until the model ADR records the first types and hierarchy boundary" — is now satisfied. The recorded rulings that bind this slice:

• first-item-types = A — the first item types are Task, Epic, Spike. All existing cards default to Task. Bug, Decision, and Ongoing are deferred; ongoing remains a lifecycle notion, not a type. The schema-v2 triage type (action / decision / question) is a different axis and must define its own mapping rather than reuse this set.
• hierarchy-boundaries = A — same board only, one optional parent, a hard depth cap of 3, a server-side cycle check, and type-agnostic: any admitted type may parent any admitted type, per ADR-0060's rule that item type is independent of either relationship. Cross-project hierarchy is recorded as "no", vacuously while no Project entity exists. Maintainer scope note: this ruling goes to an architecture review targeted at v0.3.0 or later ([Architecture review] Multi-board work-item identity and hierarchy boundaries (v0.3.0 or later) #2187) and holds until that review records a change.
• parent-lifecycle = A — this is the explicit rule your acceptance line 5 ("Deleting/archiving a parent has explicit child behavior and no silent cascade") demanded:
  • Default is detach, never cascade. Deleting or archiving a parent clears the child's parent pointer; children keep their IDs, board, column, history, and exports.
  • A cascade-archive of the subtree is permitted only as an explicit, user-confirmed action — a prompt that names the affected count. Never silent, and never on delete (maintainer scope note: "with ability to cascade through a prompt").
  • Because detach is a derived mutation of every child, proposal preview, apply, and audit must list the child pointer changes. Today ProposeArchiveCardExecutor summarizes only the single parent operation, so preview/apply parity has to be extended to those child pointer changes in this slice.
• compat-path = A — stages 1-3 of the ADR-0060 ladder are executable direction: additive columns/tables on the Card path, a tested down path, and card IDs preserved in place (board JSON import mints fresh IDs, so the preservation claim binds in-place migrations only). Stage 4-5 work stays behind an ADR amendment, consistent with this issue's "No Workspace/Project migration in this slice" non-goal.
• multi-board-identity = A — one item is exactly one board and one column through v0.3, so no multi-board canonical item enters this slice.

Prerequisite: #2185

The archive half of the parent-lifecycle rule cannot be proven on top of the shipped archive path. #2185 records that an approved-and-applied archive-card proposal operation is a silent no-op (OperationHandlerRegistry.ArchiveCardAsync builds an UpdateCardDto with IsBlocked = true and a null BlockReason, which CardService.UpdateCardAsync ignores). A real card-archive state and handler must exist and be proven before child behavior is defined on top of it. Delete-side child behavior is not blocked by #2185.

Nothing above is implemented; these are recorded rulings.

[Chris0Jeky]

v0.3 RC deck reply applied (2026-08-30, deck map map:v1:bec0a8dd8ba5839bc4816da9e46371e89fc866c5bc936add3d9aceb414dd9138). q-3 = B: moved to the v0.4 milestone (now v0.4 — Hosted Open Beta + Work Model + Every Artefact). ADR-0060/0062 rulings are unchanged; only the timing moved. The one v0.3 exception is the minimal multiple-assignments sub-slice of #2093, filed as #2240.

[Chris0Jeky]

Head-start material (2026-09-02, v0.3/v0.4 acceleration bundle re-pass under #2376, follow-up to #2348).

Curated head-start: docs/analysis/2026-08-30-acceleration-bundle/issues/2087-item-types-and-parent-hierarchy.md (lands with the #2348 follow-up PR). It carries the child-slice ladder, an architecture table where every "exists" row names the real type on main, a test plan and the edge cases.

Corrections to claims in this issue and its comments

• The 2026-08-29 ruling comment says ArchiveCardAsync passes a null BlockReason that CardService ignores. That was fixed by commit c7f865674 (PR fix(proposals): make archive card outcome visible #2216): the handler now passes OperationHandlerRegistry.ArchiveCardBlockReason, so card.Block(reason) runs. The operation is no longer silent — but it still maps archive onto blocked, Card has no archive state, and [Backend][Proposals] Archive-card proposal operations apply as a silent no-op (IsBlocked=true with null BlockReason is ignored) #2185 stays open. The parent-lifecycle archive prerequisite therefore holds for a different reason than the comment gives; delete-side detach is not blocked.
• The depth convention is undecided. ADR-0060 says "a hard depth cap of 3" without saying whether 3 counts nodes or edges. Record it on this issue before the validator is written.
• Error codes. ErrorCodes (Domain/Exceptions/DomainException.cs) is a closed 15-member PascalCase set and ResultExtensions.ToHttpStatusCode maps anything unknown to 500. Cycle/depth/scope failures must map onto ValidationError (400) or Conflict (409), or extend the set deliberately.
• Export round-trip is not free. ImportCardDto(Title, Description, ColumnName, Position, DueDate, Labels) has no card id and resolves its column by name, so a parent reference has nothing to point at. A card key in the board JSON contract is a shared-contract prerequisite.
• Scope on BoardId, not owner. Card has no owner field and Board.OwnerId is Guid? — two nulls compare equal.
• Proposal operations dispatch on (targetType, actionType) string pairs, not a work-item.* namespace; ProposalOperationInputValidator accepts any identifier-like token, so a new verb must land in ProposalOperationContractValidator and OperationHandlerRegistry in the same PR.

First startable slice: WM-TYPE-01-contract — WorkItemType, Card.ParentCardId, additive migration + down path, and a pure hierarchy validator. Nothing blocks it; ADR-0060 already fixes every value it encodes.
Blocked: the cascade-archive slice, behind #2185. Export behind the card-key decision. Everything else behind 01 and the shared-file freeze (Card.cs, CardDto, proposal registry, EF snapshot, types/board.ts).

Reference candidates (archived verbatim, adoption only under the RECONCILIATION.md admission contract): candidates/dotnet/WorkHierarchyRules.cs + its tests, testing/test-vectors/hierarchy-cases.json (case names only — no fixtures), diagrams/work-model.svg, architecture/WORK_MODEL_IMPLEMENTATION_BLUEPRINT.md (now carries a validation preface).

[Chris0Jeky]

Alpha dependency audit at main a1f7979: #2185 is closed through #2410 (a32b481), with proposal archive deliberately reported as Block plus the generated reason. Card still has no archive lifecycle. The old #2185 open-prerequisite wording is therefore stale; closure does not supply a real archive/restore contract for this hierarchy.

Two decisions remain before a coherent hierarchy implementation: whether parent archive means that explicit proposal Block operation or a real Card archive/restore lifecycle, and whether depth 3 counts levels or links. These have been sent to the maintainer in the active Alpha session. No schema/validator implementation is claimed and no existing lease is taken.

CLAUDE_SYNC_PACKET
canonical truth changes: no files changed; reconcile this dependency note when the rulings are recorded
issue/project changes: #2087 remains pending; no promotion or closure
architecture/decision impact: parent-lifecycle semantics and depth convention await explicit ruling
manual validation still needed: none for this source audit
human actions: the two rulings above; existing OUTSTANDING_TASKS.md decisions remain open

[Chris0Jeky]

Maintainer rulings recorded from the active Alpha session, 2026-09-10:

1. Parent archive uses a TRUE card archive and restore lifecycle. The current proposal operation that marks a card blocked is not the intended hierarchy substrate.
2. Maximum hierarchy depth is THREE parent-child links, hence FOUR levels total.

The existing same-board, one-parent, type-agnostic and default-detach rulings remain. Children keep IDs/history; no silent archive/delete cascade. #2185 stays closed for its previously accepted Block-preview/audit repair. Alpha will first prepare a bounded archive/restore child under this issue, then build hierarchy on that real lifecycle. No hierarchy implementation or release approval is claimed by this decision receipt.

CLAUDE_SYNC_PACKET
canonical truth changes: ADR-0060 should record these two rulings in the implementing PR; STATUS only changes with tested delivery
issue/project changes: #2087 decisions resolved; archive prerequisite child to be scoped separately
architecture/decision impact: true card archive/restore, and depth measured in links
manual validation still needed: future implementation proof
human actions: these two specific questions are answered; unrelated OUTSTANDING_TASKS.md items remain open