Backend: Scenario create-from-UI support (validation + defaults) #58

New issue

Closed

opened 2026-06-26 00:05:16 +02:00 by myrmidex · 1 comment

myrmidex commented

2026-06-26 00:05:16 +02:00

Owner

Context

POST /api/scenarios already exists and stamps the owner (#50 Story 1). But "create a scenario from the UI" as a first-class flow may need more than the bare Post: sensible defaults (distribution_mode), the ability to seed an initial bucket set, and confirmation the create→redirect-to-show flow works end-to-end against the owner-scoped reads.

This ticket exists to make in-app scenario creation a complete, tested flow rather than assuming the existing Post is sufficient. Scope to be confirmed during tdd-scoper — it may turn out the existing Post needs nothing and this collapses into a thin frontend-only follow-up.

Scope (to validate)

Confirm POST /api/scenarios returns the created scenario IRI/id so the SPA can redirect to its show page.
Defaults: distribution_mode defaults to EVEN (already), name required (already NotBlank). Any other field the UI must supply?
OPTIONAL: a "new scenario starts with N default buckets" seed — decide if that's backend (a processor) or frontend (N follow-up POSTs). Lean frontend unless atomicity matters.
Verify create→GET /api/scenarios/{id} round-trips for the owner (no scoping surprise on a just-created row).

Depends on

Nothing hard (the Post exists); pairs with the frontend create-scenario flow.

Testing (TDD if backend changes land)

Whatever new backend behaviour is added; otherwise this is a verification-only ticket that may convert to a frontend story.

Note

Flagged as possibly-thin — run tdd-scoper to confirm whether real backend work exists here or it folds into a frontend ticket.

## Context `POST /api/scenarios` already exists and stamps the owner (#50 Story 1). But "create a scenario from the UI" as a first-class flow may need more than the bare Post: sensible defaults (distribution_mode), the ability to seed an initial bucket set, and confirmation the create→redirect-to-show flow works end-to-end against the owner-scoped reads. This ticket exists to make in-app scenario creation a complete, tested flow rather than assuming the existing Post is sufficient. **Scope to be confirmed during tdd-scoper** — it may turn out the existing Post needs nothing and this collapses into a thin frontend-only follow-up. ## Scope (to validate) - Confirm `POST /api/scenarios` returns the created scenario IRI/id so the SPA can redirect to its show page. - Defaults: distribution_mode defaults to EVEN (already), name required (already `NotBlank`). Any other field the UI must supply? - OPTIONAL: a "new scenario starts with N default buckets" seed — decide if that's backend (a processor) or frontend (N follow-up POSTs). Lean frontend unless atomicity matters. - Verify create→`GET /api/scenarios/{id}` round-trips for the owner (no scoping surprise on a just-created row). ## Depends on - Nothing hard (the Post exists); pairs with the frontend create-scenario flow. ## Testing (TDD if backend changes land) - Whatever new backend behaviour is added; otherwise this is a verification-only ticket that may convert to a frontend story. ## Note Flagged as possibly-thin — run tdd-scoper to confirm whether real backend work exists here or it folds into a frontend ticket.

myrmidex added this to the v0.3.0 milestone 2026-06-26 00:05:16 +02:00

myrmidex added the

enhancement

label 2026-06-26 00:05:16 +02:00

myrmidex self-assigned this 2026-06-26 00:05:16 +02:00

myrmidex referenced this issue

2026-06-26 00:13:19 +02:00

Port frontend features: scenario page + bucket UI + distribution #34

myrmidex referenced this issue

2026-06-27 01:10:37 +02:00

Remove unused distribution_mode field from Scenario #61

myrmidex commented

2026-06-27 13:48:34 +02:00

Author

Owner

Resolved in e0e2f25 (on release/v0.3.0).

Verdict was as the ticket suspected — thin, no production code needed. The existing POST /api/scenarios already satisfies create-from-UI (owner stamped, returns @id for redirect, name required, description optional). Landed two functional characterization tests in tests/Functional/ScenarioApiTest.php pinning the SPA contract:

testPostThenGetOnReturnedIriRoundTripsForTheOwner — create → GET the returned IRI as the same owner → 200 (guards against an owner-scope regression 404'ing the redirect target).
testPostWithDescriptionPersistsAndEchoesIt — optional description persists and is echoed.

Decisions:

Default-buckets seed → frontend N-POSTs, not a backend processor (no atomicity requirement; zero/partial bucket sets are valid states; bucket template is a UX concern).
distribution_mode was found dead (stored, never read) → spun out and removed under #61.

195 tests green, php-cs-fixer + PHPStan clean.

Resolved in `e0e2f25` (on `release/v0.3.0`). Verdict was as the ticket suspected — **thin, no production code needed**. The existing `POST /api/scenarios` already satisfies create-from-UI (owner stamped, returns `@id` for redirect, `name` required, `description` optional). Landed two functional **characterization tests** in `tests/Functional/ScenarioApiTest.php` pinning the SPA contract: - `testPostThenGetOnReturnedIriRoundTripsForTheOwner` — create → GET the returned IRI as the same owner → 200 (guards against an owner-scope regression 404'ing the redirect target). - `testPostWithDescriptionPersistsAndEchoesIt` — optional `description` persists and is echoed. Decisions: - **Default-buckets seed → frontend N-POSTs**, not a backend processor (no atomicity requirement; zero/partial bucket sets are valid states; bucket template is a UX concern). - **`distribution_mode` was found dead** (stored, never read) → spun out and removed under #61. 195 tests green, php-cs-fixer + PHPStan clean.

myrmidex closed this issue

2026-06-27 14:13:56 +02:00