# AGENTS.md — Agent Guidance for Event Photo Platform This repository hosts a multi-tenant event photo platform (Laravel 12, PHP 8.3, Filament 4, React 19/Vite 7 PWA). This document defines how AI agents should operate in this repo: roles, permissions, safety rules, and standard workflows. It is the single source of truth for agent behavior. Per-agent details live in docs/agents/. ## Purpose & Scope - Provide clear guardrails and playbooks so agents can assist safely with code, docs, DevOps and project hygiene. - Applies to the whole repo unless a component has an explicit per-agent policy in docs/agents/. ## Roles - Codegen Agent — implements and edits application code, tests and documentation within scoped tasks. See docs/agents/codegen.md. - Ops Agent — automates tasks around CI/CD, releases, issue hygiene, and repo maintenance. See docs/agents/ops.md. - (Optional) Docs Agent — maintains documentation quality; follow Codegen Agent rules with writing focus. ## Global Policies - Secrets & Credentials: - Never commit secrets. The local file gogs.ini (token=…) is ignored via .gitignore and must not be printed into logs. - ENV values in .env are sensitive; do not commit them or echo to build logs. - Data Protection: - Respect GDPR. Do not introduce PII logging. Legal content (Impressum, Privacy, AGB) is managed via Legal Pages resource. - Safety & Access: - Prefer least privilege. Do not alter production data or infrastructure from code without explicit human approval. - When uncertain about a destructive operation, open a PR or create an Issue with a proposal. - Source of Truth: - Keep this AGENTS.md authoritative. If per-agent docs diverge, update this file and link the rationale. ## Tools & Permissions - Languages/Frameworks: PHP 8.2+ (Laravel 12), TypeScript/JavaScript (React 19/Vite 7/Tailwind 4), Filament 4. - Dev Commands: composer, npm, vite, artisan, PHPUnit, Pint/ESLint, Docker/Compose (for dev), Playwright, Vitest, TypeScript. - Libraries: simplesoftwareio/simple-qrcode for server-side QR generation; Paddle API client (custom service) for payments; dompdf for PDF generation; spatie/laravel-translatable for i18n; minishlink/web-push for web push; firebase/php-jwt for JWT; Sentry (Laravel + Vite); Stripe (PHP + JS); Tamagui (design system); i18next (frontend i18n); vite-plugin-pwa for PWA builds. - Payment Systems: Paddle (subscriptions and one-time payments), RevenueCat (mobile app subscriptions), Stripe (legacy/integration use). - PWA Technologies: React 19, Vite 7, Capacitor (iOS), Trusted Web Activity (Android), Service Workers, Background Sync. ## Repo Structure (high-level) - docs/archive/prp/ — split PRP (authoritative). Start at docs/archive/prp/README.md. - .beads/ — bd issue tracker data (source of truth for backlog and progress). - resources/js/guest/ — Guest PWA source (React 19, offline-first, installable). - resources/js/admin/ — Tenant Admin PWA source (React 19, Capacitor/TWA ready). - resources/js/pages/ — Inertia pages (React). - docs/archive/README.md — historical PRP context. ## Standard Workflows - Coding tasks (Codegen Agent): 1) Understand scope; update or create a minimal plan. 2) Edit code/docs via small, reviewable patches; keep changes focused. 3) Add/update tests if behavior changes. 4) Update docs when public surfaces change (PRP, docs/*). 5) Propose follow-ups as Issues if out of scope. - Issue hygiene (Ops Agent): - Track backlog and follow-ups in bd; avoid duplicates by checking existing titles before creating new issues. - Avoid duplicates by checking existing titles. - Releases (Ops Agent): - Tag with semantic version; generate changelog from commits/PRs; ensure legal pages and migration notes are updated. ## Developer Utilities ### Artisan commands #### Billing & Packages - package:check-status — check event package status. - packages:migrate-legacy — migrate legacy package purchases. - paddle:sync-packages — sync packages with Paddle (push/pull/queue/dry-run). - coupons:export — export coupon redemptions. - checkout:send-reminders — send abandoned checkout reminders (dry-run supported). #### Tenant Operations - tenant:attach-demo-event — attach an existing demo event to a tenant. - tenant:backfill-invitations — backfill invitations (supports tenant filtering). - tenant:notifications:retry — retry tenant notification delivery. - tenants:retention-scan — tenant retention scanning. #### Demo & Seeds - demo:seed-switcher — seed demo switcher tenants (supports cleanup and sample photos). #### Guest Engagement - guest:feedback-reminders — send guest feedback reminders. #### Storage & Exports - storage:monitor — storage monitor. - storage:check-upload-queues — upload queue health checks. - storage:archive-pending — dispatch storage archiving. - exports:purge — purge expired data exports. - media:backfill-thumbnails — generate thumbnails for existing photos. #### Photobooth - photobooth:ingest — ingest photobooth uploads. - photobooth:cleanup-expired — deactivate expired photobooth accounts. #### Content & Assets - fonts:sync-google — sync Google Fonts to public storage. - help:sync — sync help center content. #### Metrics & Misc - metrics:package-limits — inspect/reset package limit metrics (routes/console.php). - inspire — inspiring quote (routes/console.php). - Public APIs for Guest PWA: stats/photos endpoints with ETag; likes; uploads; see docs/archive/prp/03-api.md. - Payment Integration: Paddle webhooks, RevenueCat mobile subscriptions. ## PWA Architecture - Guest PWA: Offline-first photo sharing app for event attendees (installable, background sync, no account required). - Tenant Admin PWA: Store-ready mobile app for event management (Android TWA, iOS Capacitor, OAuth2 + PKCE). - Core Features: Background upload, conflict resolution, push notifications, achievement system, emotion/task tagging. ## Constraints & Red-Lines - Do not introduce tracking beyond what is documented (anonymous session_id only for guest PWA). - Do not weaken auth, CSRF, CORS, or role checks. - Do not expand data retention without updating Privacy policy. - PWA decisions are locked: Photos only (no videos), no facial recognition, no public profiles. ## Change Management - Propose updates to this file via PR. Include: - Motivation and scope, affected agents, roll-out plan. - Links to updated docs in docs/agents/. ## References - ADR-0006: Tenant Admin PWA architecture decision. - docs/archive/prp/06-tenant-admin-pwa.md: Detailed PWA specifications. - docs/archive/prp/07-guest-pwa.md: Guest PWA requirements and features. - docs/archive/prp/08-billing.md: Payment system architecture. === === foundation rules === # Laravel Boost Guidelines The Laravel Boost guidelines are specifically curated by Laravel maintainers for this application. These guidelines should be followed closely to enhance the user's satisfaction building Laravel applications. ## Foundational Context This application is a Laravel application and its main Laravel ecosystems package & versions are below. You are an expert with them all. Ensure you abide by these specific packages & versions. - php - 8.3.6 - filament/filament (FILAMENT) - v4 - inertiajs/inertia-laravel (INERTIA) - v2 - laravel/framework (LARAVEL) - v12 - laravel/horizon (HORIZON) - v5 - laravel/prompts (PROMPTS) - v0 - laravel/sanctum (SANCTUM) - v4 - laravel/socialite (SOCIALITE) - v5 - laravel/wayfinder (WAYFINDER) - v0 - livewire/livewire (LIVEWIRE) - v3 - laravel/mcp (MCP) - v0 - laravel/pint (PINT) - v1 - laravel/sail (SAIL) - v1 - phpunit/phpunit (PHPUNIT) - v11 - @inertiajs/react (INERTIA) - v2 - react (REACT) - v19 - tailwindcss (TAILWINDCSS) - v4 - @laravel/vite-plugin-wayfinder (WAYFINDER) - v0 - eslint (ESLINT) - v9 - prettier (PRETTIER) - v3 ## Conventions - You must follow all existing code conventions used in this application. When creating or editing a file, check sibling files for the correct structure, approach, and naming. - Use descriptive names for variables and methods. For example, `isRegisteredForDiscounts`, not `discount()`. - Check for existing components to reuse before writing a new one. ## Verification Scripts - Do not create verification scripts or tinker when tests cover that functionality and prove it works. Unit and feature tests are more important. ## Application Structure & Architecture - Stick to existing directory structure; don't create new base folders without approval. - Do not change the application's dependencies without approval. ## Frontend Bundling - If the user doesn't see a frontend change reflected in the UI, it could mean they need to run `npm run build`, `npm run dev`, or `composer run dev`. Ask them. ## Replies - Be concise in your explanations - focus on what's important rather than explaining obvious details. ## Documentation Files - You must only create documentation files if explicitly requested by the user. === boost rules === ## Laravel Boost - Laravel Boost is an MCP server that comes with powerful tools designed specifically for this application. Use them. ## Artisan - Use the `list-artisan-commands` tool when you need to call an Artisan command to double-check the available parameters. ## URLs - Whenever you share a project URL with the user, you should use the `get-absolute-url` tool to ensure you're using the correct scheme, domain/IP, and port. ## Tinker / Debugging - You should use the `tinker` tool when you need to execute PHP to debug code or query Eloquent models directly. - Use the `database-query` tool when you only need to read from the database. ## Reading Browser Logs With the `browser-logs` Tool - You can read browser logs, errors, and exceptions using the `browser-logs` tool from Boost. - Only recent browser logs will be useful - ignore old logs. ## Searching Documentation (Critically Important) - Boost comes with a powerful `search-docs` tool you should use before any other approaches when dealing with Laravel or Laravel ecosystem packages. This tool automatically passes a list of installed packages and their versions to the remote Boost API, so it returns only version-specific documentation for the user's circumstance. You should pass an array of packages to filter on if you know you need docs for particular packages. - The `search-docs` tool is perfect for all Laravel-related packages, including Laravel, Inertia, Livewire, Filament, Tailwind, Pest, Nova, Nightwatch, etc. - You must use this tool to search for Laravel ecosystem documentation before falling back to other approaches. - Search the documentation before making code changes to ensure we are taking the correct approach. - Use multiple, broad, simple, topic-based queries to start. For example: `['rate limiting', 'routing rate limiting', 'routing']`. - Do not add package names to queries; package information is already shared. For example, use `test resource table`, not `filament 4 test resource table`. ### Available Search Syntax - You can and should pass multiple queries at once. The most relevant results will be returned first. 1. Simple Word Searches with auto-stemming - query=authentication - finds 'authenticate' and 'auth'. 2. Multiple Words (AND Logic) - query=rate limit - finds knowledge containing both "rate" AND "limit". 3. Quoted Phrases (Exact Position) - query="infinite scroll" - words must be adjacent and in that order. 4. Mixed Queries - query=middleware "rate limit" - "middleware" AND exact phrase "rate limit". 5. Multiple Queries - queries=["authentication", "middleware"] - ANY of these terms. === php rules === ## PHP - Always use curly braces for control structures, even if it has one line. ### Constructors - Use PHP 8 constructor property promotion in `__construct()`. - public function __construct(public GitHub $github) { } - Do not allow empty `__construct()` methods with zero parameters unless the constructor is private. ### Type Declarations - Always use explicit return type declarations for methods and functions. - Use appropriate PHP type hints for method parameters. protected function isAccessible(User $user, ?string $path = null): bool { ... } ## Comments - Prefer PHPDoc blocks over inline comments. Never use comments within the code itself unless there is something very complex going on. ## PHPDoc Blocks - Add useful array shape type definitions for arrays when appropriate. ## Enums - Typically, keys in an Enum should be TitleCase. For example: `FavoritePerson`, `BestLake`, `Monthly`. === tests rules === ## Test Enforcement - Every change must be programmatically tested. Write a new test or update an existing test, then run the affected tests to make sure they pass. - Run the minimum number of tests needed to ensure code quality and speed. Use `php artisan test --compact` with a specific filename or filter. === inertia-laravel/core rules === ## Inertia - Inertia.js components should be placed in the `resources/js/Pages` directory unless specified differently in the JS bundler (`vite.config.js`). - Use `Inertia::render()` for server-side routing instead of traditional Blade views. - Use the `search-docs` tool for accurate guidance on all things Inertia. // routes/web.php example Route::get('/users', function () { return Inertia::render('Users/Index', [ 'users' => User::all() ]); }); === inertia-laravel/v2 rules === ## Inertia v2 - Make use of all Inertia features from v1 and v2. Check the documentation before making any changes to ensure we are taking the correct approach. ### Inertia v2 New Features - Deferred props. - Infinite scrolling using merging props and `WhenVisible`. - Lazy loading data on scroll. - Polling. - Prefetching. ### Deferred Props & Empty States - When using deferred props on the frontend, you should add a nice empty state with pulsing/animated skeleton. ### Inertia Form General Guidance - The recommended way to build forms when using Inertia is with the `
` component - a useful example is below. Use the `search-docs` tool with a query of `form component` for guidance. - Forms can also be built using the `useForm` helper for more programmatic control, or to follow existing conventions. Use the `search-docs` tool with a query of `useForm helper` for guidance. - `resetOnError`, `resetOnSuccess`, and `setDefaultsOnSuccess` are available on the `` component. Use the `search-docs` tool with a query of `form component resetting` for guidance. === laravel/core rules === ## Do Things the Laravel Way - Use `php artisan make:` commands to create new files (i.e. migrations, controllers, models, etc.). You can list available Artisan commands using the `list-artisan-commands` tool. - If you're creating a generic PHP class, use `php artisan make:class`. - Pass `--no-interaction` to all Artisan commands to ensure they work without user input. You should also pass the correct `--options` to ensure correct behavior. ### Database - Always use proper Eloquent relationship methods with return type hints. Prefer relationship methods over raw queries or manual joins. - Use Eloquent models and relationships before suggesting raw database queries. - Avoid `DB::`; prefer `Model::query()`. Generate code that leverages Laravel's ORM capabilities rather than bypassing them. - Generate code that prevents N+1 query problems by using eager loading. - Use Laravel's query builder for very complex database operations. ### Model Creation - When creating new models, create useful factories and seeders for them too. Ask the user if they need any other things, using `list-artisan-commands` to check the available options to `php artisan make:model`. ### APIs & Eloquent Resources - For APIs, default to using Eloquent API Resources and API versioning unless existing API routes do not, then you should follow existing application convention. ### Controllers & Validation - Always create Form Request classes for validation rather than inline validation in controllers. Include both validation rules and custom error messages. - Check sibling Form Requests to see if the application uses array or string based validation rules. ### Queues - Use queued jobs for time-consuming operations with the `ShouldQueue` interface. ### Authentication & Authorization - Use Laravel's built-in authentication and authorization features (gates, policies, Sanctum, etc.). ### URL Generation - When generating links to other pages, prefer named routes and the `route()` function. ### Configuration - Use environment variables only in configuration files - never use the `env()` function directly outside of config files. Always use `config('app.name')`, not `env('APP_NAME')`. ### Testing - When creating models for tests, use the factories for the models. Check if the factory has custom states that can be used before manually setting up the model. - Faker: Use methods such as `$this->faker->word()` or `fake()->randomDigit()`. Follow existing conventions whether to use `$this->faker` or `fake()`. - When creating tests, make use of `php artisan make:test [options] {name}` to create a feature test, and pass `--unit` to create a unit test. Most tests should be feature tests. ### Vite Error - If you receive an "Illuminate\Foundation\ViteException: Unable to locate file in Vite manifest" error, you can run `npm run build` or ask the user to run `npm run dev` or `composer run dev`. === laravel/v12 rules === ## Laravel 12 - Use the `search-docs` tool to get version-specific documentation. - This project upgraded from Laravel 10 without migrating to the new streamlined Laravel file structure. - This is **perfectly fine** and recommended by Laravel. Follow the existing structure from Laravel 10. We do not need to migrate to the new Laravel structure unless the user explicitly requests it. ### Laravel 10 Structure - Middleware typically lives in `app/Http/Middleware/` and service providers in `app/Providers/`. - There is no `bootstrap/app.php` application configuration in a Laravel 10 structure: - Middleware registration happens in `app/Http/Kernel.php` - Exception handling is in `app/Exceptions/Handler.php` - Console commands and schedule register in `app/Console/Kernel.php` - Rate limits likely exist in `RouteServiceProvider` or `app/Http/Kernel.php` ### Database - When modifying a column, the migration must include all of the attributes that were previously defined on the column. Otherwise, they will be dropped and lost. - Laravel 12 allows limiting eagerly loaded records natively, without external packages: `$query->latest()->limit(10);`. ### Models - Casts can and likely should be set in a `casts()` method on a model rather than the `$casts` property. Follow existing conventions from other models. === wayfinder/core rules === ## Laravel Wayfinder Wayfinder generates TypeScript functions and types for Laravel controllers and routes which you can import into your client-side code. It provides type safety and automatic synchronization between backend routes and frontend code. ### Development Guidelines - Always use the `search-docs` tool to check Wayfinder correct usage before implementing any features. - Always prefer named imports for tree-shaking (e.g., `import { show } from '@/actions/...'`). - Avoid default controller imports (prevents tree-shaking). - Run `php artisan wayfinder:generate` after route changes if Vite plugin isn't installed. ### Feature Overview - Form Support: Use `.form()` with `--with-form` flag for HTML form attributes — `` → `action="/posts" method="post"`. - HTTP Methods: Call `.get()`, `.post()`, `.patch()`, `.put()`, `.delete()` for specific methods — `show.head(1)` → `{ url: "/posts/1", method: "head" }`. - Invokable Controllers: Import and invoke directly as functions. For example, `import StorePost from '@/actions/.../StorePostController'; StorePost()`. - Named Routes: Import from `@/routes/` for non-controller routes. For example, `import { show } from '@/routes/post'; show(1)` for route name `post.show`. - Parameter Binding: Detects route keys (e.g., `{post:slug}`) and accepts matching object properties — `show("my-post")` or `show({ slug: "my-post" })`. - Query Merging: Use `mergeQuery` to merge with `window.location.search`, set values to `null` to remove — `show(1, { mergeQuery: { page: 2, sort: null } })`. - Query Parameters: Pass `{ query: {...} }` in options to append params — `show(1, { query: { page: 1 } })` → `"/posts/1?page=1"`. - Route Objects: Functions return `{ url, method }` shaped objects — `show(1)` → `{ url: "/posts/1", method: "get" }`. - URL Extraction: Use `.url()` to get URL string — `show.url(1)` → `"/posts/1"`. ### Example Usage // Import controller methods (tree-shakable)... import { show, store, update } from '@/actions/App/Http/Controllers/PostController' // Get route object with URL and method... show(1) // { url: "/posts/1", method: "get" } // Get just the URL... show.url(1) // "/posts/1" // Use specific HTTP methods... show.get(1) // { url: "/posts/1", method: "get" } show.head(1) // { url: "/posts/1", method: "head" } // Import named routes... import { show as postShow } from '@/routes/post' // For route name 'post.show' postShow(1) // { url: "/posts/1", method: "get" } ### Wayfinder + Inertia If your application uses the `` component from Inertia, you can use Wayfinder to generate form action and method automatically.
=== livewire/core rules === ## Livewire - Use the `search-docs` tool to find exact version-specific documentation for how to write Livewire and Livewire tests. - Use the `php artisan make:livewire [Posts\CreatePost]` Artisan command to create new components. - State should live on the server, with the UI reflecting it. - All Livewire requests hit the Laravel backend; they're like regular HTTP requests. Always validate form data and run authorization checks in Livewire actions. ## Livewire Best Practices - Livewire components require a single root element. - Use `wire:loading` and `wire:dirty` for delightful loading states. - Add `wire:key` in loops: ```blade @foreach ($items as $item)
{{ $item->name }}
@endforeach ``` - Prefer lifecycle hooks like `mount()`, `updatedFoo()` for initialization and reactive side effects: public function mount(User $user) { $this->user = $user; } public function updatedSearch() { $this->resetPage(); } ## Testing Livewire Livewire::test(Counter::class) ->assertSet('count', 0) ->call('increment') ->assertSet('count', 1) ->assertSee(1) ->assertStatus(200); $this->get('/posts/create') ->assertSeeLivewire(CreatePost::class); === livewire/v3 rules === ## Livewire 3 ### Key Changes From Livewire 2 - These things changed in Livewire 3, but may not have been updated in this application. Verify this application's setup to ensure you conform with application conventions. - Use `wire:model.live` for real-time updates, `wire:model` is now deferred by default. - Components now use the `App\Livewire` namespace (not `App\Http\Livewire`). - Use `$this->dispatch()` to dispatch events (not `emit` or `dispatchBrowserEvent`). - Use the `components.layouts.app` view as the typical layout path (not `layouts.app`). ### New Directives - `wire:show`, `wire:transition`, `wire:cloak`, `wire:offline`, `wire:target` are available for use. Use the documentation to find usage examples. ### Alpine - Alpine is now included with Livewire; don't manually include Alpine.js. - Plugins included with Alpine: persist, intersect, collapse, and focus. ### Lifecycle Hooks - You can listen for `livewire:init` to hook into Livewire initialization, and `fail.status === 419` for the page expiring: document.addEventListener('livewire:init', function () { Livewire.hook('request', ({ fail }) => { if (fail && fail.status === 419) { alert('Your session expired'); } }); Livewire.hook('message.failed', (message, component) => { console.error(message); }); }); === pint/core rules === ## Laravel Pint Code Formatter - You must run `vendor/bin/pint --dirty` before finalizing changes to ensure your code matches the project's expected style. - Do not run `vendor/bin/pint --test`, simply run `vendor/bin/pint` to fix any formatting issues. === phpunit/core rules === ## PHPUnit - This application uses PHPUnit for testing. All tests must be written as PHPUnit classes. Use `php artisan make:test --phpunit {name}` to create a new test. - If you see a test using "Pest", convert it to PHPUnit. - Every time a test has been updated, run that singular test. - When the tests relating to your feature are passing, ask the user if they would like to also run the entire test suite to make sure everything is still passing. - Tests should test all of the happy paths, failure paths, and weird paths. - You must not remove any tests or test files from the tests directory without approval. These are not temporary or helper files; these are core to the application. ### Running Tests - Run the minimal number of tests, using an appropriate filter, before finalizing. - To run all tests: `php artisan test --compact`. - To run all tests in a file: `php artisan test --compact tests/Feature/ExampleTest.php`. - To filter on a particular test name: `php artisan test --compact --filter=testName` (recommended after making a change to a related file). === inertia-react/core rules === ## Inertia + React - Use `router.visit()` or `` for navigation instead of traditional links. import { Link } from '@inertiajs/react' Home === inertia-react/v2/forms rules === ## Inertia v2 + React Forms import { Form } from '@inertiajs/react' export default () => (
{({ errors, hasErrors, processing, wasSuccessful, recentlySuccessful, clearErrors, resetAndClearErrors, defaults }) => ( <> {errors.name &&
{errors.name}
} {wasSuccessful &&
User created successfully!
} )}
) === tailwindcss/core rules === ## Tailwind CSS - Use Tailwind CSS classes to style HTML; check and use existing Tailwind conventions within the project before writing your own. - Offer to extract repeated patterns into components that match the project's conventions (i.e. Blade, JSX, Vue, etc.). - Think through class placement, order, priority, and defaults. Remove redundant classes, add classes to parent or child carefully to limit repetition, and group elements logically. - You can use the `search-docs` tool to get exact examples from the official documentation when needed. ### Spacing - When listing items, use gap utilities for spacing; don't use margins.
Superior
Michigan
Erie
 ### Dark Mode - If existing pages and components support dark mode, new pages and components must support dark mode in a similar way, typically using `dark:`. === tailwindcss/v4 rules === ## Tailwind CSS 4 - Always use Tailwind CSS v4; do not use the deprecated utilities. - `corePlugins` is not supported in Tailwind v4. - In Tailwind v4, configuration is CSS-first using the `@theme` directive — no separate `tailwind.config.js` file is needed. @theme { --color-brand: oklch(0.72 0.11 178); } - In Tailwind v4, you import Tailwind using a regular CSS `@import` statement, not using the `@tailwind` directives used in v3: - @tailwind base; - @tailwind components; - @tailwind utilities; + @import "tailwindcss"; ### Replaced Utilities - Tailwind v4 removed deprecated utilities. Do not use the deprecated option; use the replacement. - Opacity values are still numeric. | Deprecated | Replacement | |------------+--------------| | bg-opacity-* | bg-black/* | | text-opacity-* | text-black/* | | border-opacity-* | border-black/* | | divide-opacity-* | divide-black/* | | ring-opacity-* | ring-black/* | | placeholder-opacity-* | placeholder-black/* | | flex-shrink-* | shrink-* | | flex-grow-* | grow-* | | overflow-ellipsis | text-ellipsis | | decoration-slice | box-decoration-slice | | decoration-clone | box-decoration-clone | ## Issue Tracking This project uses **bd (beads)** for issue tracking. Run `bd prime` for workflow context, or install hooks (`bd hooks install`) for auto-injection. **Quick reference:** - `bd ready` - Find unblocked work - `bd create "Title" --type task --priority 2` - Create issue - `bd close ` - Complete work - `bd sync` - Sync with git (run at session end) For full workflow details: `bd prime` ## Landing the Plane (Session Completion) **When ending a work session**, you MUST complete ALL steps below. Work is NOT complete until `git push` succeeds. **MANDATORY WORKFLOW:** 1. **File issues for remaining work** - Create issues for anything that needs follow-up 2. **Run quality gates** (if code changed) - Tests, linters, builds 3. **Update issue status** - Close finished work, update in-progress items 4. **PUSH TO REMOTE** - This is MANDATORY: ```bash git pull --rebase bd sync git push git status # MUST show "up to date with origin" ``` 5. **Clean up** - Clear stashes, prune remote branches 6. **Verify** - All changes committed AND pushed 7. **Hand off** - Provide context for next session **CRITICAL RULES:** - Work is NOT complete until `git push` succeeds - NEVER stop before pushing - that leaves work stranded locally - NEVER say "ready to push when you are" - YOU must push - If push fails, resolve and retry until it succeeds