Skip to content

W-072: demo-ck3 spec for the M1 features

Type: design · Size: S · Epic: E-ck3-m1 · Target: docs/specs/demo-ck3.md · Breaking: no Depends: W-004, W-008, W-017 Refs: demo-ck3 brief §4 and §5 (CK3-F01..CK3-F06), concept §8, W-008 (ecs-relations spec REL-F01..REL-F08), model W-070

Goal

Write docs/specs/demo-ck3.md with spec-format requirement groups for the six M1 features CK3-F01 to CK3-F06. Define the monthly pipeline (age, birth and death, succession, opinions, loyalty, end checks) and the month clock once in the spec, so the features reference them instead of restating them.

Decided in the brief, to carry into the spec: - Relation order for the package work items: REL-F06, REL-F07, REL-F01, REL-F02, REL-F03, REL-F04, REL-F05, REL-F08. - cascade yields level order: all rulers at depth 0 first, then their vassals. - If CK3-F04 is rated above M, split up (REL-F04, nearest crown) out of CK3-F04 into its own requirement group and feature item.

Package dependency: the M1 features depend on the ecs-relations implementation, W-061 to W-068 (REL-F01 to REL-F08), and on ecs-schedule as the spec needs it. The spec states which REL requirement each M1 requirement uses, so each feature item gets the matching Depends. The family tree uses plain koota ParentOf, not ChildOf.

Open check before writing requirements: the brief relies on symmetric, transitive, isReachable, up, cascade, Name, getPath and lookup. Confirm each is in the ecs-relations spec and in koota's public API (koota skill). If one is missing, block the spec and create a package item, per workflow.

Once the spec is approved, Triage creates one feature item per CK3 feature (M1) and makes them ready.

Steps

  • S1 (REL-F01..REL-F08): report-only check, no file changes. Confirm symmetric, transitive, isReachable, up, cascade, Name, getPath, lookup (a) are specified in the ecs-relations spec and (b) can be built on koota's public API only (koota skill, no $internal; see the spec's KL1..KL11). Note the REL group each CK3 feature uses (brief §5 table). If one is missing, mark the item blocked and flag a package item as a blocker; do not start S2; files: none (findings go to the Log)
  • S2 (CK3-F01..CK3-F06): SpecWriter writes the spec modelled on docs/specs/demo-anno.md. Define the monthly pipeline (age, birth and death, succession, opinions, loyalty, end checks) and the month clock once, in a shared section. One requirement group per feature, CK3-F01 to CK3-F06, each marking which REL requirement it uses (for Triage's Depends). Use plain koota ParentOf for the family tree (CK3-F02). Carry the decided cascade level order (CK3-F06). Add an acceptance checklist. If CK3-F04 is rated above M, split up (REL-F04) into its own group; files: docs/specs/demo-ck3.md
  • S3 (approval): user reviews and approves docs/specs/demo-ck3.md. After approval Triage creates one feature item per CK3 feature (M1); files: none

Log

  • 2026-11-02 created, follow-up of W-017 (Triage)
  • 2026-11-02 Depends changed per board review: W-071 removed (spec does not need the scaffold), W-004 added (Triage)
  • 2026-11-02 Next -> Now, state active; deps W-004, W-008, W-017 done, WIP 0 (Triage)
  • 2026-11-02 steps written: 3 steps (S1 relations check, S2 write spec, S3 approval) (Planner)
  • 2026-11-02 S1 done: all eight REL functions are in the ecs-relations spec and buildable on koota's public API (KL1..KL11); no blocker (Triage)
  • 2026-11-02 S2 done: spec docs/specs/demo-ck3.md written, Status approved (Triage)
  • 2026-11-02 S3 done: user approved the spec. Feature items created: W-083 to W-103, in Later (their Depends are Later package items) (Triage)
  • 2026-11-02 approved by the user (spec Status approved); active -> done, moved to Done on the board (Triage)