php-ruby-platform

name	php-ruby-platform
description	Deliver PHP and Ruby application-platform work across Laravel, Symfony, and Rails while keeping routing, validation, data access, jobs, and service boundaries explicit.

PHP Ruby Platform

Use this pack for PHP and Ruby platform work: Laravel applications, Symfony services, Rails apps, server-rendered products, JSON APIs, admin systems, background jobs, and convention-heavy application delivery.

Defer first-pass route choice and lane selection to ../../reference/routing-guidance.md.

This is the general PHP and Ruby family pack for the repo. Use the overlay in reference/laravel-symfony-rails.md to tune decisions for Laravel, Symfony, and Rails while keeping the same expectations for routing, validation, ORM usage, job execution, and testing conventions.

Setup posture

• Prefer modernizing, refining, or extending an existing project in place.
• Treat scaffold, create, init, or new flows as greenfield-only and explicit-request-only. Defer to reference/project-setup-policy.md.

Core focus

• Keep routing, controllers, actions, and request entry points readable from transport boundary to domain logic.
• Make validation, authorization, serialization, and error handling explicit instead of relying on framework magic alone.
• Treat ORM and data access patterns as architectural choices with visible transactions, query behavior, and ownership.
• Keep jobs, queues, mailers, and event-driven work deliberate, idempotent, and easy to trace.
• Preserve testing conventions that match how Laravel, Symfony, and Rails applications are actually structured.

Shared PHP and Ruby standards

• Keep controllers and actions thin; move durable business rules into services, domain objects, or clearly owned application layers.
• Validate at the boundary with request objects, form requests, form objects, schemas, or equivalent framework-native mechanisms.
• Make ORM usage readable so eager loading, transactions, callbacks, and query boundaries do not become hidden surprises.
• Keep queue, job, and background execution behavior explicit, including retries, idempotency, and failure handling.
• Use framework conventions on purpose, but leave enough structure that routing, validation, and data flow are still easy to audit.

Default workflow

1. Inspect the framework structure, dependency injection style, route layout, and existing test conventions.
2. Choose the framework overlay in reference/laravel-symfony-rails.md.
3. Define route contracts, validation flow, service boundaries, data access, and background-job behavior before broad implementation.
4. Implement transport logic, application services, and tests together so framework conventions stay coherent.
5. Run review skill after substantial PHP or Ruby platform changes.

Collaboration in this repo

• Use research tools or the built-in Explore behavior before editing so new work matches local controllers, services, routes, and test patterns.
• Use research tools, Context7, or equivalent knowledge retrieval when framework APIs, ORM behavior, or queue semantics need a source-of-truth check.
• Use review skill when routing, validation, data access, or job behavior changes materially.

Overlays

• reference/laravel-symfony-rails.md for routing, validation, DI or container boundaries, jobs or queues, and framework testing conventions.

Guardrails

• Do not bury domain behavior inside controllers, callbacks, helpers, or convenience traits that make request flow hard to trace.
• Do not let framework magic hide validation, transaction scope, authorization, or job retry behavior.
• Do not treat ORM entities or active record models as the only place business rules can live.