feat(resource): resource types, resources, skills and pools

The document's first golden rule is "the calendar belongs to the resource, not to
the doctor". Today the only thing that can be occupied is a doctor, and ClinicStaff
is a label on services and appointments with no calendar, capacity or skills. This
adds the layer underneath: anything that can be busy — doctor, operator, assistant,
device, room, bed, chair.

Two corrections to the planned schema:

- `address_id` → doctor_addresses, not `branch_id` → a new branches table. The
  branch already exists and is the address (task 01).
- UNIQUE is (doctor_id, address_id), not (doctor_id). A WeeklySchedule is per
  (doctor, clinic) but every session inside it carries its own location_id, so one
  doctor already works at several addresses within one environment. Keying on the
  doctor alone would have made that unrepresentable — and task 03 gives each
  resource its own calendar, which is exactly per-location.

Design points worth keeping:

- Resources bridge to Doctor/ClinicStaff/Room rather than absorbing them; those
  three have live consumers (appointments.doctor_id, service_item_staff, the public
  site) and subclassing would mean migrating all of them at once. At most one bridge
  column is non-null, enforced in the entity because MariaDB will not reliably
  enforce a multi-column CHECK.
- Capacity is concurrency: a three-bed injection room is one resource with capacity
  3, not three resources, so occupancy in task 06 stays a COUNT against a limit
  instead of a merge of three calendars. A person resource is refused capacity > 1.
- Skills are a table, not rules. With 50 operators and 200 services, expressing
  "who may operate what" as policy would mean 10,000 rules.
- findEligible() uses HAVING COUNT(DISTINCT …) because "skills A and B" means both;
  a plain IN would have matched a resource holding only one.
- setup/cleanup minutes occupy the resource without being part of the patient's
  appointment, and are per-resource — distinct from the existing per-doctor
  WeeklySchedule.meta.buffer_minutes, which stays untouched.

Two real bugs found by running the backfill against real data rather than fixtures:

ResourceLinker::systemType() persisted a type without flushing, so the next lookup
missed it and created a second — the run died on "Duplicate entry 'doctor-1-staff'
for key uniq_rt_tenant_code". It now keeps an identity map for the unit of work.

The command looped over every WeeklySchedule once per environment, which is
quadratic and never finished on real data. Doctors are now a single pass keyed by
the schedule's own environment. It also flushes per environment and accepts
--pair=clinic:12, so one bad row cannot close the EntityManager and abort a
fleet-wide run, and operators can re-run for a single clinic.

Staff are the one case that cannot be derived: nothing records which branch they
work at. Rather than guessing the first one and seating them in the wrong building,
multi-branch environments are skipped and reported.

88 tests, 230 assertions across tests/Resource and tests/Branch. phpstan clean on
src/Resource.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
hamed
2026-07-30 17:34:36 +03:30
co-authored by Claude Opus 5
parent 92181bacff
commit 964c09cc00
33 changed files with 3824 additions and 0 deletions
+87
View File
@@ -0,0 +1,87 @@
<?php
namespace App\Resource\Service;
use App\Auth\Entity\User;
use App\Branch\Service\BranchResolver;
use App\Doctor\Entity\DoctorAddress;
use App\Resource\Entity\ClinicResource;
use App\Resource\Entity\ResourcePool;
use App\Resource\Entity\ResourceType;
use App\Resource\Entity\Skill;
use App\Resource\Repository\ClinicResourceRepository;
use App\Resource\Repository\ResourcePoolRepository;
use App\Resource\Repository\ResourceTypeRepository;
use App\Resource\Repository\SkillRepository;
use App\Shared\Constant\ErrorCodes;
use App\Shared\Exception\AppException;
use App\Shared\Tenant\TenantOwnershipChecker;
/**
* تبدیل uuidهای درخواست به موجودیت‌های **محیط جاری**.
*
* مالکیت صریح سنجیده می‌شود و به `TenantFilter` تکیه نمی‌کنیم: جداسازی سختِ فیلتر فقط
* روی محیطِ «انتخاب‌شده» اعمال می‌شود، پس کاربری که هنوز محیطی برنگزیده، دادهٔ محیط
* دیگر را می‌دید. همان درسی که در تسک ۰۱ با `RoomCrudTest::testForeignRoomIsNotFound`
* گرفته شد ({@see docs/architecture/tenancy.md}).
*
* همه‌جا ۴۰۴ می‌دهد نه ۴۰۳ — وجود دادهٔ محیط بیگانه لو نمی‌رود.
*/
final class ResourceContext
{
public function __construct(
private readonly BranchResolver $branches,
private readonly ResourceTypeRepository $types,
private readonly ClinicResourceRepository $resources,
private readonly SkillRepository $skills,
private readonly ResourcePoolRepository $pools,
private readonly TenantOwnershipChecker $ownership,
) {}
/** @return array{0: string, 1: int} */
public function pair(User $user): array
{
return $this->branches->pair($user);
}
public function address(User $user, string $addressUuid): DoctorAddress
{
return $this->branches->resolve($user, $addressUuid);
}
public function type(User $user, string $uuid): ResourceType
{
return $this->owned($user, $this->types->findByUuid($uuid), 'نوع منبع یافت نشد');
}
public function resource(User $user, string $uuid): ClinicResource
{
return $this->owned($user, $this->resources->findByUuid($uuid), 'منبع یافت نشد');
}
public function skill(User $user, string $uuid): Skill
{
return $this->owned($user, $this->skills->findByUuid($uuid), 'مهارت یافت نشد');
}
public function pool(User $user, string $uuid): ResourcePool
{
return $this->owned($user, $this->pools->findByUuid($uuid), 'استخر منابع یافت نشد');
}
/**
* @template T of object
* @param T|null $entity
* @return T
*/
private function owned(User $user, ?object $entity, string $message): object
{
[$entityType, $entityId] = $this->pair($user);
if ($entity === null || !$this->ownership->belongsToPair($entityType, $entityId, $entity)) {
throw new AppException(ErrorCodes::ERR_NOT_FOUND_001, $message, 404);
}
return $entity;
}
}