From 854bb0e6139f620fca81afa7b1b1c4ade08a7f72 Mon Sep 17 00:00:00 2001 From: Dan Wolfson Date: Mon, 6 Jul 2026 09:01:33 -0500 Subject: [PATCH] Add backlog items for template scan findings and Create Project consistency Cross-family scan of Dr.Egeria templates while designing Egeria Advisor's chat-driven plan editing surfaced several Link/Attach spec defects that existing validation sweeps missed (stale/copy-pasted field names and descriptions, a couple of commands missing reference fields entirely), plus a basic/advanced inconsistency in Create Project's embedded parent-relationship fields. Co-Authored-By: Claude Sonnet 5 Signed-off-by: Dan Wolfson --- BACKLOG.md | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/BACKLOG.md b/BACKLOG.md index 31e6120a..15df7ebe 100644 --- a/BACKLOG.md +++ b/BACKLOG.md @@ -5,6 +5,37 @@ Status: `open` ยท `in-progress` ยท `done` ยท `deferred` --- +## ๐Ÿ”ด High Priority โ€” Cross-family template scan found several Link/Attach spec defects that validation sweeps missed + +**Status:** open +**Added:** 2026-07-06 + +Egeria Advisor did a manual+agent-assisted scan of all `Create_*`/`Link_*`/`Attach_*` markdown templates across all 12 Dr.Egeria families (Action Author, Actor Manager, Collections, Data Designer, Digital Product Manager, External Reference, Feedback, Glossary, Governance Officer, Projects, Report, Solution Architect) while researching relationship-representation patterns for a chat-driven plan-editing feature. It surfaced several template defects that existing `validate_compact_specs` / test sweeps apparently don't catch: + +- **`Link_Term-Term_Relationship`** (Glossary): has no Term1/Term2 (or equivalent) reference fields at all โ€” only a `Relationship Type` enum. As specified, the command can't actually name which two terms to link. +- **`Attach_Comment`** (Feedback): missing its target-element reference field entirely. Sibling commands `Attach_Like`, `Attach_Rating`, `Attach_Tag` all correctly carry theirs. +- **`Link_Regulation_to_Regulator`** (Governance Officer): field names appear copy-pasted from `Link_Governed_By` โ€” still labeled `Governance Definition`/`Referenceable` rather than Regulation/Regulator-specific names. +- **`Link_Certification`** and **`Link_Regulation_Certification_Type`** (Governance Officer): field descriptions say "license type" where they should say "certification type" โ€” looks like copy-paste from the parallel `Link_License` command. +- **`Link_Data_Class_Composition`** (Data Designer): field descriptions carry text copy-pasted from the unrelated `DataValueDefinition` relationship. +- Two related "naming trap" issues worth a lint rule rather than a one-off fix: `Create_Regulation.Regulators` (Governance Officer) is typed `Simple List` (free text) even though it reads like an embedded relationship declaration; `Link_Associated_Skill_Set.Actor Name` (Actor Manager) is typed `Simple` while every sibling Link command's actor-reference field is typed `Reference Name`. + +**Open question to resolve as part of this item:** these look like authoring/copy-paste artifacts from Tinderbox rather than runtime logic bugs, so `validate_compact_specs` presumably isn't checking description-text content or field-name/type consistency against the command's own semantics โ€” worth figuring out why the existing validation sweep didn't flag any of these, and whether a targeted lint (e.g., flag a Link/Attach command with zero `Reference Name`-typed fields, or flag description text mentioning an entity type absent from the command's own name/family) would have caught them, so this class of defect doesn't require another manual full-family read to find next time. + +**Fix:** correct each of the templates above in Tinderbox (compact command JSON is Tinderbox-exported and must not be hand-edited โ€” see `CLAUDE.md`), re-export, run `refresh_specs` + `validate_compact_specs`, then propagate via the usual `gen_md_cmd_templates` / `gen_dr_help` sync to egeria-workspaces and egeria-advisor. + +--- + +## ๐ŸŸก Medium Priority โ€” `Create Project` is the odd one out for embedded Parent ID / Parent Relationship Type Name (advanced-only, not in basic) + +**Status:** open +**Added:** 2026-07-06 + +Found while researching relationship representation across families: `Create_Project`'s `Parent ID` / `Parent Relationship Type Name` / `Parent Relationship Attributes` / `Parent at End1` fields exist only in the **advanced** template (`sample-data/templates/advanced/Projects/Create_Project.md`), not the basic one โ€” even though this is a heavily-used, load-bearing feature (Egeria Advisor's plan generation relies on it to create sub-project hierarchies in a single step; see Egeria Advisor `CLAUDE.md` design rule 13). Every other advanced-only generic field (Anchor ID/Scope, Glossary Term) is genuinely power-user scaffolding, but per dwolfson: Project's parent-relationship fields are meant to be usable more broadly, and having them gated behind "advanced" for Projects specifically, while equivalent generic single-relationship-at-creation fields exist in every family's advanced tier regardless, is an inconsistency worth cleaning up rather than by design. + +**Fix:** promote `Parent ID` + `Parent Relationship Type Name` (and decide whether `Parent Relationship Attributes` / `Parent at End1` should move too, or stay advanced-only as more power-user-oriented) into the **basic** `Create_Project` template in Tinderbox, re-export, `refresh_specs`, `gen_md_cmd_templates`, then sync to egeria-workspaces/egeria-advisor. + +--- + ## ๐ŸŸก Medium Priority โ€” ServerClient missing async comment methods **Status:** open