Skip to content
Autosplash Documentation

Reporting Bugs & Tracing Issues

Mutual

Overview

Section titled “Overview”

This page explains how issues should be reported, investigated, and attributed within the Autosplash codebase.

Because the platform contains both inherited functionality and features implemented during the V and Bruno engagement, the existence of a bug alone does not indicate when—or by whom—it was introduced. Repository history should always be treated as the authoritative source when determining implementation lineage.

How to Report a Bug

Section titled “How to Report a Bug”

A useful bug report contains enough information for another developer to reproduce the issue without additional context.

Example bug report consisting of a screenshot together with a written description of the issue.

For general platform issues, include as much information as possible:

  • URL where the issue occurred
  • Description of the issue
  • Action being performed
  • Expected behavior
  • Actual behavior
  • Screenshot or screen recording
  • Steps taken before the issue occurred

For technical reports submitted by developers, additionally include:

  • Laravel log output
  • Browser console errors
  • Relevant file and line number (where known)
  • Reproduction steps
  • Timestamp of occurrence
  • Screen recording where appropriate

Providing complete information significantly reduces the time required to reproduce and diagnose an issue.

Investigation Workflow

Section titled “Investigation Workflow”

Before modifying code, issues should be investigated in a structured order:

  1. Reproduce the issue consistently.
  2. Review repository history using git log.
  3. Identify the commit that originally introduced the behavior.
  4. Use git blame where appropriate to determine implementation lineage.
  5. Verify whether the issue exists on staging as well as production.
  6. Determine whether the affected functionality belongs to the inherited platform or work completed during the V and Bruno engagement.
  7. Escalate to the appropriate owner if necessary.

If an issue only occurs in production, investigation should begin with:

  1. Database contents
  2. Infrastructure configuration
  3. Environment variables

before assuming an application-level defect.

How Responsibility is Traced

Section titled “How Responsibility is Traced”

Implementation responsibility is determined by the first commit introducing the behavior, not necessarily the most recent author shown on a file.

This distinction is important because the legacy repository contains merge and rebase operations that may attribute ownership of files to developers who did not originally implement the underlying functionality.

Unless Git history demonstrates otherwise, inherited components should initially be treated as legacy behavior rather than regressions introduced during the V and Bruno engagement.

Repository history should therefore be considered the authoritative source for implementation lineage.

Issues Potentially Within the V and Bruno Scope

Section titled “Issues Potentially Within the V and Bruno Scope”

The implementation completed during the engagement is intentionally well isolated from the legacy application.

Examples include:

  • Guest booking flow
  • Guest Booking Controller
  • Coupon service layer
  • Stripe webhook implementation
  • Infrastructure and deployment tooling introduced during the engagement
  • Other documented service-layer abstractions

If investigation strongly indicates that an issue originates from functionality implemented during the engagement, contact details can be found in the Key People & Contacts page:

Key PeoplePrimary contact points for different areas of the Autosplash platform.

Technical enquiries related specifically to the V and Bruno implementation may also be sent to:

vladimir@vandbruno.net

Infrastructure & Third-Party Services

Section titled “Infrastructure & Third-Party Services”

The following categories are considered infrastructure or operational concerns rather than defects introduced during the engagement:

  • PHP version incompatibilities
  • Server configuration
  • Environment variables (.env)
  • DNS
  • Amazon S3 configuration
  • Expired API credentials
  • New hosting environments
  • General DevOps configuration

Similarly, behaviour resulting from changes to third-party providers—including Stripe, Firebase, Twilio, Google Maps, or similar integrations—is outside the original implementation scope.

Support for these systems is available only under a separate maintenance agreement.

SSL certificate renewal is the only infrastructure-related exception that may be handled separately.

Known Inherited Behaviours

Section titled “Known Inherited Behaviours”

Several inherited architectural characteristics remain intentionally unchanged because they fell outside the agreed project scope.

Examples include:

  • Background execution through exec("php artisan ...")
  • Controller-heavy legacy architecture
  • Limitations of the existing membership implementation
  • A mixed architecture combining legacy components with newer service-layer abstractions

These behaviours are documented elsewhere throughout this documentation and should not automatically be treated as regressions.

Responsibility After Handover

Section titled “Responsibility After Handover”

Following project handover:

  • Operational responsibility for the platform belongs to Autosplash.
  • Future contractors are responsible for changes introduced during their own engagements.
  • V and Bruno assume no ongoing maintenance responsibility outside separate written agreements.

Repository history should always be reviewed before attributing responsibility for any reported issue.