diff --git a/BACKLOG.md b/BACKLOG.md index 77db0989..85a69390 100644 --- a/BACKLOG.md +++ b/BACKLOG.md @@ -5,6 +5,18 @@ Status: `open` · `in-progress` · `done` · `deferred` --- +## 🟡 Medium Priority — Wrap Mandy's new engine-host View Server endpoints + +**Status:** open, waiting on Egeria (expected "in a few days" from 2026-10-14) +**Added:** 2026-10-14 + +Mandy will expose more engine-host internal APIs as View Server REST calls once her current fixes are done. That includes the per-engine "approved, unclaimed" engine-action listing, which today exists only on the metadata server's governance-context service. RE needs them to act as an engine host (ISSUE-150). When they land, check the refreshed `.http` files and Egeria's `AutomatedCurationResource` (or wherever they're added), then: +- add `AutomatedCuration` wrappers, e.g. next to `get_active_claimed_engine_actions`; +- add micro-tests that pin the URLs; +- tell the RE PR/CI session the pyegeria version. + +--- + ## 🟡 Medium Priority — Re-test deletes when the new Egeria release lands **Status:** open, blocked on Egeria (its delete fixes are in progress upstream) diff --git a/PYEGERIA_ISSUES.md b/PYEGERIA_ISSUES.md index 7c7b9877..b4e30b53 100644 --- a/PYEGERIA_ISSUES.md +++ b/PYEGERIA_ISSUES.md @@ -257,7 +257,7 @@ they're holding real port materialization until this exists server-side ### ISSUE-150: Dr.Egeria commands for an Analytic Function's Egeria declaration: a GovernanceActionType that Resource Explorer runs as an engine host, plus a synchronous path that bypasses Egeria -**Layer:** Dr.Egeria (commands over existing Action Author / governance commands) · **Status:** open, direction agreed with the owner 2026-10-13 ("a good start; we may need to review and change"), not yet built · **Found:** 2026-10-13, handed off by the Resource Explorer PR/CI session. Source: trellis `docs/extensibility-walking-skeleton-brief.md` §2c, §3a, §8. Egeria references: [Governance Action Processes (0462)](https://egeria-project.org/types/4/0462-Governance-Action-Processes/), [Survey Action Engine](https://egeria-project.org/concepts/survey-action-engine/). +**Layer:** Dr.Egeria (commands over existing Action Author / governance commands) · **Status:** open, direction agreed with the owner 2026-10-13 and **confirmed by Mandy 2026-10-14**, not yet built · **Found:** 2026-10-13, handed off by the Resource Explorer PR/CI session. Source: trellis `docs/extensibility-walking-skeleton-brief.md` §2c, §3a, §8. Egeria references: [Governance Action Processes (0462)](https://egeria-project.org/types/4/0462-Governance-Action-Processes/), [Survey Action Engine](https://egeria-project.org/concepts/survey-action-engine/). **Background (Egeria's model):** - A `GovernanceActionType` is a template for **one** action. Initiating it creates one Engine Action. @@ -324,6 +324,19 @@ they're holding real port materialization until this exists server-side 1. **One declaration, idempotent.** The manifest's qualifiers must live on the `GovernanceActionType` itself (`supportedRequestParameters` or `additionalProperties`), so Egeria, the Portal and RE all read the same declaration. That means question ids, perspectives, `purpose` (from the existing `VALID_PURPOSES` set) and `family`. Declaring is idempotent by qualifiedName: declaring twice updates, and never creates a second type. Dr.Egeria's upsert (Create→Update by qualified name) already behaves this way. 2. **Label synchronous values differently from recorded ones.** On a screen, a value computed now must be labelled "computed now · not recorded", and a stored result "last recorded ". A reader must never mistake a synchronous draw for a governed measurement. (The envelope gives the state and `measured_at`; the "recorded or not" label is the caller's, from which path it used.) 3. **State the credential tier.** User-written steps stay on the resource's read-only tier (owner ruling, 2026-10-07). A `GovernanceActionType` declared for one must say so, with a property naming the tier (e.g. `credential_tier: read_only`). **Owner: an informational key, not a control.** Egeria schedules Engine Actions the same way regardless, and never hands a step its resource credentials. The engine host does: RE's wrapper enforces read-only from the step's manifest (`StepManifest.credential_tier`). The key on the declaration is for governance visibility (whoever reviews or approves the type can see it), and for any other engine host that might run the step later. The design session confirmed this when asked (2026-10-13). It withdrew its "control" reading: the only reader other than RE's wrapper would be a second engine host, which enforces the tier itself. An Egeria-side approval step or governance rule that reads the tier would be new design nobody has asked for. + +**Mandy's answer (2026-10-14, via the owner and the RE PR/CI session); the declaration direction is confirmed, no longer provisional:** +- **Engine type:** `SurveyActionEngine` for surveys. RE may also expose services through a `GovernanceActionEngine` (general) or a `WatchdogActionEngine` (monitoring). +- **What to create:** a governance service definition for each service, of the subtype matching the engine: a **`SurveyActionService`** for a `SurveyActionEngine` (survey steps), a `GovernanceActionService` for a `GovernanceActionEngine`. Plus the `GovernanceActionExecutor` relationship to the engine element. (Owner's correction, 2026-10-14: not a plain `GovernanceService`.) +- **requestType:** the value the engine advertises, and the value it's passed when asked to execute. RE dispatches on it. +- **Guards:** standard survey guards are best practice, not mandatory. +- **Coming in a few days:** more engine-host internal APIs, including the per-engine approved-actions listing, will be exposed as View Server REST calls once her current fixes are done. pyegeria will need wrappers for them (BACKLOG.md). +- Refs: [Survey Action Engine](https://egeria-project.org/concepts/survey-action-engine/), [0461 Governance Engines](https://egeria-project.org/types/4/0461-Governance-Engines/), [0462 Governance Action Processes](https://egeria-project.org/types/4/0462-Governance-Action-Processes/). + +**What exists today for the engine side (gap 3, checked 2026-10-14):** +- The SDK can link a service to an engine: `AssetMaker` `governance-engines/{guid}/supported-governance-services/{guid}/attach`, plus `update`/`detach` (`asset_maker.py` ~1693-1813 and ~6586-6803). +- Dr.Egeria has **no** commands to create a `GovernanceEngine` (or its `SurveyActionEngine`/`GovernanceActionEngine`/`WatchdogActionEngine` subtypes) or a governance service (`SurveyActionService`/`GovernanceActionService`/...), and none for the supported-service link. Only `Link Action to Action Executor` exists (Action Author). +- These are the Dr.Egeria commands to add: `Create Governance Engine` (with an engine-type attribute), `Create Governance Service` (with a service-type attribute matching the engine: `SurveyActionService` for survey steps), and `Link Governance Service to Engine` (with requestType). Check the 0461 types and the `.http` files for the create endpoints before building. ---