Where are we at with this project currently? Can you review local branches and where things are at there and then compare to remote (ie: are we behind any? how many ahead are we? do we need to merge our feature branches still?)

next steps

• Merge feature branches into staging when appropriate.
• Push feature branches to remote or set up upstream tracking if needed.

key decisions

• Feature branches are based on origin/staging, not origin/master, so staging is the correct merge target.
• The admin dashboard and Sentry branches are not pushed; they exist only locally across three worktrees.

open questions

• What is the intended merge order for the stacked feature branches?
• Should the crash-probe-patches-fos stash on master be restored or dropped?

next steps

—

key decisions

• Moved branch from separate worktree to main checkout to leverage existing .env instead of creating a minimal env for the worktree.
• Removed stale Herd symlink manually after herd unlink failed, then recreated it from the main checkout.

open questions

—

next steps

• Check the .env file for DASHBOARD_ADMIN_EMAILS and DASHBOARD_PASSWORD values, ensuring no extra spaces or quotes.
• Verify values via 'php artisan config:get dashboard.admin_emails' and 'dashboard.password'.
• Perform a successful login test after correcting .env.
• Push staging to origin after login is confirmed working.

key decisions

• Reverted temporary auth bypass and DB fallback code in favor of production-style env-based authentication.
• Merged feature/admin-dashboard into staging via fast-forward instead of creating a merge commit.

open questions

• Why did the exact credentials not match the config? Could be whitespace in .env, incorrect env key, or caching?
• Does the user need to configure the database connection for dashboard metrics to display real data?

next steps

• Optional CI/code review before push.

key decisions

• Do not copy .env from sentry worktree (none existed).
• Ensure Composer install is run after merging branches with new dependencies.

open questions

—

next steps

• Remove 'sentry/sentry-laravel' from the 'dont-discover' list or manually register only the base ServiceProvider.
• Update config/sentry.php with DSN, traces_sampler, before_send callbacks.
• Update App\Observability\Sentry to stop calling \Sentry\init().
• Keep custom SentryTracingMiddleware, queue listeners, Guzzle tracing.
• Resolve potential conflict between custom TestSentry command and package's sentry:test.
• Run full test suite to verify no regressions.

key decisions

• Let the sentry-laravel base ServiceProvider own client registration and config loading, rather than calling \Sentry\init() manually.
• Retain custom HTTP/queue tracing middleware and listeners to avoid duplicate transactions with the package's tracing ServiceProvider.
• Disable the Tracing ServiceProvider auto-discovery to prevent duplicate transaction creation.
• Keep all TDR-specific observers (app.source, app.runtime, per-op sampling, queue context) via traces_sampler and before_send in config/sentry.php.
• Preserve the existing env variable names (SENTRY_DSN, SENTRY_TRACES_SAMPLE_RATE) for backward compatibility.

open questions

• How exactly to exclude only the Tracing ServiceProvider from auto-discovery while permitting the base ServiceProvider?
• Will the package's SetRequestMiddleware conflict with existing request handling or custom SentryTracingMiddleware?
• Does the package's built-in sentry:test command duplicate our custom TestSentry command?

next steps

—

key decisions

• Manually register Sentry\Laravel\ServiceProvider in config/app.php while disabling package discovery to exclude Tracing\ServiceProvider.
• Sentry::boot() no longer calls \Sentry\init(); it relies on the Laravel provider for SDK initialization.
• isEnabled() guard checks hub->getClient() !== null before proceeding, making empty SENTRY_DSN a true no-op.
• traces_sampler and before_send callbacks are configured in config/sentry.php referencing Sentry class static methods.

open questions

—