Story: Commission: counterparty
Table of Contents
This page documents a story in Sprint 22. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
Goal
Commission counterparty across all access layers: verify the Qt UI end-to-end post-NATS
migration, implement shell commands (list, add, remove — not yet implemented), implement
CLI commands (list, add, remove — not yet implemented), fix any regressions found, and add
the entity chapter to the user manual.
Wt and HTTP support are not tracked here — they're covered by the dedicated top-level commissioning stories: Wt entity UI — top-level commissioning story and HTTP entity endpoints — top-level commissioning story (both currently inbox captures).
Status
| Field | Value |
|---|---|
| State | ABANDONED |
| Parent sprint | Sprint 22 |
| Now | Abandoned — consolidated into a single capture with party and party_status. |
| Waiting on | Nothing. |
| Next | Superseded by Commission: party, counterparty, and party_status (Sprint 23). |
| Last touched | 2026-07-10 |
Acceptance
- Qt list window (MDI): loads and displays records correctly.
- Qt detail window: edit and save round-trips without error.
- Qt history window: shows change history for the entity.
- Qt delete command: removes the record; history is preserved.
- Qt eventing: a change made in one connected session appears in a second session without manual refresh.
- Shell list command: implemented and working (new implementation).
- Shell add command: implemented and working (new implementation).
- Shell remove command: implemented and working (new implementation).
- CLI list command: implemented and working (new implementation).
- CLI add command: implemented and working (new implementation).
- CLI remove command: implemented and working (new implementation).
- Manual: entity chapter documents all Qt windows, shell, and CLI commands.
- All regressions found are fixed inline or filed as captures.
- Site builds cleanly.
Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Appraise counterparty across all layers and produce evaluation checklist | DONE | 2026-07-03 | 2026-07-03 | Found counterparty is on the unified codegen model (ahead of currency in that respect — no separate _table.org), but a scoped regen attempt showed it and both child entities have substantial hand-written SQL validation never captured in the .org models; not safe to regenerate as-is. |
| Populate existing codegen facets for counterparty models | DONE | 2026-07-03 | 2026-07-03 | Populated all three models; found and fixed a real codegen template bug along the way (Validations facet was reading the wrong nested path, never worked for any entity without a legacy _table.org companion); verified against currency (zero regression). |
| Add a generic cardinality-limit-validation facet to the SQL codegen template | DONE | 2026-07-03 | 2026-07-03 | Extended the existing Validations facet with optional cardinality columns instead of a new top-level facet; adopted in both counterparty_identifier and party_identifier. Also closed the country_code gap via a new SQL paste marker. |
| Verify counterparty Qt UI end-to-end post-NATS | BLOCKED | 2026-07-04 | Verify the counterparty Qt UI (list window, detail window, history, delete, eventing) works end-to-end post-NATS migration. | |
| Implement and verify counterparty shell and CLI commands | BACKLOG | Implement/verify shell and CLI commands (list, add, remove) for counterparty. | ||
| Write counterparty documentation (manual chapter, NATS reference) | BACKLOG | Document counterparty in the user manual, following the pattern used for other commissioned entities. | ||
| File Wt and HTTP gap captures for counterparty | BACKLOG | File backlog captures for counterparty Wt UI and HTTP endpoint gaps, tracked by the dedicated top-level commissioning stories. |
Decisions
Codegen template bug found and fixed: the compiled
sql_schema_domain_entity_create.mustache read
\{\{#domain_entity.validations\}\} (flat) for the Insert-trigger
Validations facet, but org_loader.py actually stores it nested at
domain_entity.insert_trigger.validations. This meant the Validations
facet had never worked for any entity lacking a legacy _table.org
companion — every existing user (e.g. currency) still has one, and
SQL generation for a _table.org file goes through a different,
correctly-flat loader. counterparty is the first entity to exercise
the unified entity→SQL path for this facet and hit the bug. Fixed the
.org template source and re-tangled; verified zero regression on
currency before landing.
Regen must be entity-scoped, not component-scoped: use ./compass.sh
codegen entity generate <entity> --profile all (see
How do I run codegen?), not codegen regenerate --component. The
component-wide command touches every entity in the component and
surfaced ~20 unrelated entities' pre-existing drift when tried by
mistake — reverted in full, not investigated further, but worth a
dedicated cleanup story given the volume.
Resolved: both remaining gaps closed in the cardinality-limit-facet
task. country_code (didn't match any existing facet) is now a SQL
paste block via a new <<paste:UUID>> marker in the insert-trigger
template — the paste-block mechanism (:implements <UUID>, already
used for C++ repository methods) turned out to be fully generic
(any language, anywhere in the document), so no new machinery was
needed, just a new marker. The cardinality-limit check is now an
extension of the existing Validations facet (optional columns:
cardinality_limit_table, cardinality_limit_column,
cardinality_scope_column, cardinality_noun) rather than a
separate top-level facet — adopted in both counterparty_identifier
and party_identifier, its only two consumers.