# Tee Time Master — Engineering

## Mission And Ownership

Engineering owns booking reliability, course adapters, fairness controls, application security,
data protection, observability, and product delivery.

Joshua Bing is the human owner for Engineering decisions and the final approver for production
deployments, production writes, course enablement, credential changes, and security-sensitive work.

## Product And Technical Responsibilities

- maintain the customer application and booking services;
- protect own-account credential handling;
- build and verify course adapters;
- enforce fairness and anti-hoarding rules;
- stop safely at course security and identity controls;
- provide clear booking, failure, and manual-handoff outcomes;
- maintain payment and notification integrations;
- operate production observability and incident response; and
- give Growth and Support accurate product-readiness information.

## Example Technical Environment

| Area                            | Standard                                   |
| ------------------------------- | ------------------------------------------ |
| Primary repository              | GitHub repository `teetimemaster/platform` |
| Public website repository       | GitHub repository `teetimemaster/website`  |
| Default branch                  | Protected `main`                           |
| Languages                       | TypeScript and SQL                         |
| Application stack               | React, Bun services, Vite                  |
| Datastores                      | PostgreSQL and Redis                       |
| Edge and delivery               | Cloudflare and managed application hosting |
| Error tracking                  | Sentry                                     |
| Product analytics               | PostHog                                    |
| Roadmap and technical decisions | Notion                                     |
| Technical issue tracking        | GitHub Issues                              |
| Environments                    | Local, preview, staging, production        |

## Source-Control And Review Rules

- Use short-lived branches and pull requests into protected `main`.
- Every production change requires a pull request and at least one reviewer.
- Security, credentials, privacy, payments, fairness, tenant isolation, or destructive behavior
  requires Joshua's review.
- Required checks are type checking, linting, unit tests, integration tests for touched booking
  paths, and a production build.
- Pull requests explain customer impact, failure behavior, rollout, and rollback.
- Secrets, production customer data, and production credentials never enter source control or test
  fixtures.

## Engineering Preferences

- Prefer the smallest reversible end-to-end change.
- Reuse trusted services for commodity capabilities; build custom systems for booking, fairness,
  credential safety, and product differentiation.
- Add an abstraction only when real reuse or a clear safety boundary justifies it.
- Review behavior, failure modes, security, tenant isolation, observability, rollout, and rollback—not
  only syntax.
- Accept reversible internal inconvenience; do not accept silent booking, payment, credential,
  fairness, or customer-data risk.
- Reliability and security regressions block feature release. Narrow scope before weakening a
  control.
- Use staging, a narrow production cohort, health checks, and a tested rollback before broad
  enablement.
- Record architecture decisions when ownership, schema, security, integration boundaries, or
  irreversible operational behavior changes.

## Security And Data Rules

- Scope every customer read and write to the internal customer UUID.
- Encrypt course credentials at rest.
- Never write passwords, full card data, secrets, or course credentials to logs.
- Use course credentials only for the authorized customer's own account.
- Delete stored course credentials when the customer disconnects the account.
- Stop and alert on CAPTCHA, multi-factor prompts, identity checks, unexpected legal terms, or
  unsafe course responses.
- Keep a tamper-evident record of consequential booking and credential operations without storing
  the secret itself.
- Use the managed secret store and least-privilege service access.

## Human Approval Boundaries

Engineering may inspect, implement, test, stage, and prepare. Joshua must approve:

- production deployments and rollbacks;
- production data writes or schema migrations;
- secret rotation and access-control changes;
- encryption or credential-handling changes;
- enabling a new course adapter or expanding its production cohort;
- fairness-control changes;
- destructive recovery actions; and
- customer-facing incident communication.

## Engineering Metrics

Product metrics:

- Watch-to-match rate;
- match-to-successful-booking rate;
- time from release to booking attempt;
- manual-handoff rate; and
- fairness exceptions.

Engineering metrics:

- course-adapter success rate;
- production error rate;
- change failure rate;
- mean time to recovery; and
- verified course-adapter coverage.

## Workflow: Ship A Change

**Trigger:** An approved issue has an owner and acceptance criteria.  
**Inputs:** Issue, relevant business context, source code, and test fixtures.  
**Owner:** Engineering.

1. Confirm scope, affected invariants, customer impact, failure modes, and rollback.
2. Implement the smallest complete change and update tests and operating documentation.
3. Run every required check.
4. Obtain code review and the additional human review required for sensitive work.
5. Verify the change in preview and staging.
6. Present release scope, health checks, observation window, and rollback for approval.
7. After approval, deploy progressively and observe.
8. Roll back and escalate when a health or customer guardrail fails.
9. Record the release outcome and follow-up work.

**Success:** The change meets acceptance criteria and stays healthy for the observation window.  
**Failure:** Preserve evidence, stop expansion, and use the approved rollback rather than improvising
in production.

## Workflow: Onboard A Course Adapter

**Trigger:** Qualified demand exists and authorized test access is available.  
**Inputs:** Course rules, booking flow, release window, authorized test account, fairness rules, and
stop conditions.  
**Owner:** Engineering.

1. Review the course's rules, terms, booking flow, and hard controls.
2. Document supported actions and explicit stop conditions.
3. Implement against authorized non-production access.
4. Verify booking, supported cancellation, idempotency, fairness, notifications, and manual handoff.
5. Document limitations, Support guidance, metrics, cohort, and rollback.
6. Obtain Joshua's approval for production enablement.
7. Enable only the approved cohort and observe before expansion.

**Success:** The adapter behaves safely and reliably without bypassing course controls.  
**Failure:** Stop automation and alert the user when a hard control or unexpected state appears.

## Workflow: Respond To A Production Incident

1. Declare severity, incident owner, affected scope, and stop conditions.
2. Stabilize with the smallest reversible control while preserving evidence.
3. Determine verified customer, booking, payment, fairness, privacy, and security impact.
4. Obtain approval for destructive recovery, credential actions, or external communication.
5. Recover and observe the defined health window.
6. Complete a blameless review with timeline, contributing factors, corrective owners, due dates,
   and verification.

Support receives only verified customer guidance. No one speculates publicly about cause or scope.

## Documentation

For material changes, record the decision, owner, alternatives, security and customer impact,
failure behavior, rollout, rollback, and verification evidence. Repeated incidents and product
limitations must update the relevant Support guidance.

See [Organization](../organization.md), [Integrations](../integrations.md), and
[Organization Workflows](../workflows.md).