docs(solution-architect): ISSUE-84 fix -- correct fictional NewSolutionElementRequestBody/initialStatus docstrings

[dwolfson]

Summary

Supersedes #337 (closed — that one was opened from dwolfson:main, which drags in unrelated fork history and conflicted with PYEGERIA_ISSUES.md edits already merged upstream via #335/#336). Same fix, now on a clean branch off current upstream/main.

SolutionArchitect.create_solution_blueprint/create_solution_component (async + sync, 4 docstrings total) documented a NewSolutionElementRequestBody body class with a top-level initialStatus field as the way to set Draft status at creation. Confirmed that class and field appear in zero .http ground-truth files anywhere in this repo — never a real Egeria API surface, not merely an unmodeled one.

Following the documented shape either:

• hard-failed client-side pydantic validation (create_solution_blueprint — class literal mismatch, raising PyegeriaInvalidParameterException that reads exactly like a server-side rejection), or
• silently dropped the field and always created the element ACTIVE regardless of intent (create_solution_component — its example already used the real NewElementRequestBody class, so PyegeriaModel's extra='ignore' swallowed initialStatus with no error at all).

Also found and fixed while walking these: create_solution_blueprint's first ("no lifecycle") example body carried leftover userDefinedStatus/lifecycleStatus fields with a missing comma — invalid JSON even as a copy-paste example.

Fix: all four docstrings now document contentStatus inside properties instead — confirmed against Egeria-api-solution-architect.http's own updateSolutionBlueprintStatus example, and content_status is already a real field on ReferenceableProperties, the base class both SolutionBlueprintProperties and SolutionComponentProperties derive from. No model change needed — NewElementRequestBody.properties is a bare dict, so contentStatus already passes through untouched to the outgoing JSON.

Found via a live consumer report — trellis/Resource Explorer's BlueprintMaterializer (docs/blueprint-materialization-plan.md Phase A), tracked as egeria-python ISSUE-84 in PYEGERIA_ISSUES.md.

Testing

Verified locally (no live Egeria server access from this environment): the original repro's TypeAdapter(NewElementRequestBody).validate_python(...) call with the old shape still fails as expected; the corrected shape ({"class": "NewElementRequestBody", "properties": {..., "contentStatus": "DRAFT"}}) validates cleanly with contentStatus preserved through to the serialized JSON. Full tests/micro-tests/ suite passes clean (exit 0), no regressions.

Not live-verified against a real Egeria server — the original reporter (trellis/Resource Explorer) has live access and is best placed to confirm contentStatus: "DRAFT" at creation actually takes effect server-side before switching BlueprintMaterializer off its current ACTIVE-only workaround.

🤖 Generated with Claude Code