2 Commits

Include renames

Author	SHA1	Message	Date
hamedandClaude Opus 5	fe48b10fb5	fix(plan): stop the segment replace from destroying segments when it rejects ... PUT /service-item/{uuid}/segments deletes and rewrites. deleteForService issues a DQL DELETE that runs immediately, and three validations — duration, occupancy and constraints — only ran afterwards, while building the new rows. A rejected request therefore deleted the service's segments and saved nothing, and the service silently fell back to "one continuous block": different duration, different resources, on every future appointment, with a 422 as the only clue. Validation now happens before the delete, and the delete plus rewrite are one transaction. A test pins it: an unknown constraint is refused and the previous two segments are still there afterwards. While in there, the caps the task asked for and never got: 20 segments and 10 requirements per segment. The availability engine evaluates resource combinations per segment per requirement, so the numbers protect the search rather than the table. They are generous — no real service reaches them, but a bad payload does. The plan response now carries patient_facing_minutes. "Set aside 90 minutes" is wrong for an appointment where 40 of them are waiting for anaesthetic to take effect, and computing it once in the backend stops each client summing it differently. A condition on a fact the request never supplies still evaluates to false — that part was right — but it now logs a warning naming the policy and listing the facts that were available. A rule that hits that line every time is effectively switched off, and nothing said so. A new policy version can no longer start in the past: yesterday's appointments were priced under the previous text, and their price trace points at the version. Backdating makes that trace describe a rule that did not exist. require_resource errors name the policy that demanded the role. Knowing a room is missing does not tell an operator which of ten active rules to look at. Six operators now have a test each. An operator that compares wrongly produces a rule that always matches or never does, and neither raises anything. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 15:01:38 +03:30
hamedandClaude Opus 5	22c89fbae4	feat(plan): multi-segment appointments with per-segment resource requirements ... Section 7 of the design document, and the reason the whole resource layer exists. A laser session is not one block: numbing cream (5 min, room + operator), waiting for it to work (30 min, room only), the laser itself (20 min, room + operator + device), aftercare (5 min, room + operator). Under the single-interval model the operator is locked for all 60 minutes while actually working 30 — half the capacity thrown away. AppointmentPlanBuilder turns (service, selected items, branch, patient) into a plan: segments with offsets, durations and resource requirements. It deliberately assigns no absolute time and no specific resource — that is the next task. This only produces the *shape* of the appointment. Segment duration comes from one of two sources. A fixed segment carries its own number; an item-driven one gets its duration from task 04's DurationCalculator, so "the laser itself" grows with two treated areas while "waiting for the cream" does not. One number could not have expressed that. Three contracts worth stating: - A service with no segment templates falls back to a single continuous segment requiring the doctor resource — exactly today's behaviour. Without it every existing service would have become unplannable overnight. - A segment with no requirements is valid: "waiting at home" consumes time but occupies nothing. - same_gender_as_patient with an unknown patient gender is a 422, not a silently dropped requirement. Dropping it quietly would route the patient to a resource the clinic said must not serve them. When no resource qualifies, the error names the role, the skill and the branch — "no female operator with the skill «Alexandrite laser» is available at «Central»" — rather than an empty result the caller has to interpret (section 10). occupancy_offset carries each requirement's setup/cleanup minutes for the availability engine. It is taken as the maximum across candidates, because the builder does not yet know which resource will be picked and under-reserving means the next appointment lands on top of the cleanup. 11 tests covering the document's reference example (offsets 0/5/35/55, total 60), item-driven scaling, the no-template fallback, all three gender-constraint outcomes, merging and both caps. 1186 tests overall. phpstan back at its 14-error baseline; slot-mode frozen contract green. The admin segments page is not built; the checklist records it with a target. The backend and preview endpoint are complete and consumable without it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 21:07:30 +03:30