A Player Labs — Internal Memo

Code Workflow
Architecture

39 repos, one org, branch protection live. Here's what's done, what's left, and what needs team input.

2026-03-20 Team Discussion Rossco / Raiden / Paul / Josh
01 — Current State

39 repos. One org.
Already isolated.

All client code lives in separate repositories under the aplayerlabs GitHub organization (Team plan). Repos are already split by project — the monorepo problem is solved.

Ecommerce Eagles — 15 repos
ee-gct
ee-sss
ee-sssvend
ee-orderbook
ee-moac
ee-moac-sales
ee-mfc
ee-merch
ee-hwe
ee-twp
ee-aca
ee-rsf
ee-moc
ee-tsc
ee-apl-partnership
Advance — 2 repos
tenbot
qbuild
TPA — 3 repos
tpa
tpa-npc
tpa-link
Other Clients — 13 repos
ecm-cast
sylphist
dadcooler
hma
cm-cogs
aa-conrados-prd
wealth-diagnostic
tru
portfolio
waypoint
ag
sf
sf-board
APL Internal — 6 repos
apl-portal
apb
aplyr-xyz
colony-test-grc
colony-deploy-sandbox
quiz-demo
Advance Ecom Media Ecommerce Eagles TPA Other Clients APL Internal

The repo split is done. Branch protection is now live — staging and main are locked across all repos. Still outstanding: 2 team members need inviting, and naming/branching conventions vary across repos. IP protection handled via employment contracts and NDAs — team members need to understand the client confidentiality obligations they're bound to.

02 — What's Still Exposed

Four remaining gaps.

1
Branch Protection — DONE
  • Org ruleset "Protect staging and main" is live across all 39 repos
  • Require PR before merge to staging or main
  • No force push, no branch deletion on staging or main
  • Only "maintainers" team (Rossco) can bypass — everyone else needs a PR
2
Missing Team Members
  • Org has 2 members: rosscopaddison + AgentFlame (Josh)
  • Paul and Raiden are not in the org yet
  • No teams configured — all access is at org level
  • No permission scoping between client repos
3
Inconsistent Naming
  • EE repos use prefix: ee-gct, ee-orderbook, ee-merch
  • Advance repos don't: tenbot, qbuild (not advance-tenbot)
  • Some have client prefix, some don't: ecm-cast vs dadcooler
  • Makes it harder to filter, search, and scope permissions by client
4
Branch Strategy Drift
  • 11 repos have staging-only (no main branch at all)
  • 3 repos have main-only (no staging)
  • Default branch is inconsistent: some main, some staging
  • 2 repos have no branches whatsoever (wealth-diagnostic, sf)
5
No Client Access Path
  • Zero outside collaborators configured on any repo
  • If a client asks for their code, it's still a manual export
  • No teams means no scoped read-only access per client
  • Client handoff requires ad-hoc repo transfer
03 — How You Work Now

Your code.
Your workflow.
What changed.

Everything lives inside the aplayerlabs organisation on GitHub. That's our company. Inside it: all 39 repos, all team members, and the rules that protect production.

The daily workflow — what you actually do
1
Write code on a dev or feature branch. Push as often as you want. No restrictions. This is your workspace.
2
When it's ready, open a Pull Request to staging. A PR is a "please review and merge my changes" request. Every PR must include the live dev URL so Rossco can check the running version before merging. Don't ask for a merge without a link to click.
3
QA check on the dev URL, then merge to staging. The dev version gets checked before anything reaches a client. If something's off, the PR stays open and you fix it on your branch. Once merged, Coolify auto-deploys to the staging URL for client preview.
4
Client approves staging, then it goes to production. Staging to main is the final gate. Once merged, the production deploy happens automatically.
What you CAN do
Push to dev, feature branches, or any branch that isn't staging or main — no limits, push freely
Open Pull Requests to staging or main — this is how you request a merge
Clone and pull any repo in the organisation — you have access to everything
Staging and main
1
You can't push directly to staging or main. They trigger live deployments, so they're gated. If GitHub rejects your push, push to your branch and open a PR instead.
2
Every PR must include the live dev URL. Paste the link in your PR description so the running version can be checked before it reaches clients.
Expectations
APL has confidentiality agreements with every client. As a team member, you're bound by those agreements. Three things to know:
1
Work on your assigned projects. You have org-wide access so you can collaborate across projects when needed — use it for work.
2
Delete local repos when a project wraps. Once you're off a project, remove the local copy.
3
Client work stays inside the team. No sharing code, architecture, or business details outside APL — not in portfolios, not in side conversations, not anywhere.
If you get blocked or confused
"My push was rejected" — you probably pushed to staging or main. Push to dev or a feature branch instead, then open a PR.
"I don't know how to open a PR" — push your branch, go to the repo on GitHub, click the green "Compare & pull request" button. Select staging as the target. Done.
"Something else is broken" — message Rossco. Don't try to work around it.
How it's structured — the org, the team, the repos

aplayerlabs is our GitHub organisation — it's the company container. Everything lives inside it. Nobody outside can see our code.

aplayerlabs
The organisation — owns all 39 repos. This is A Player Labs on GitHub.
COMPANY
@aplayerlabs/
aplayerteam
The team inside the org — Rossco, Josh, Paul, Raiden. Write access to all repos.
ALL REPOS
@aplayerlabs/
maintainers
Rossco only. Can bypass branch protection to merge PRs and push to staging/main.
MERGE RIGHTS
Team members
rosscopaddison
In org, in @aplayerlabs/aplayerteam + @aplayerlabs/maintainers
✓ ACTIVE
AgentFlame (Josh)
In org, in @aplayerlabs/aplayerteam
✓ ACTIVE
Paul
Needs GitHub username → invite to org → add to @aplayerlabs/aplayerteam
✗ PENDING
Raiden
Needs GitHub username → invite to org → add to @aplayerlabs/aplayerteam
✗ PENDING
The three branches — what each one means
dev
Your workspace. Push freely. Created per-project when needed.
→ *.dev.aplayerbrains.com
staging
Client preview. Merges go through a PR — QA'd before it reaches clients.
→ *.staging.aplayerbrains.com
main
Production. Final gate — only moves here after client signs off on staging.
→ PRODUCTION
04 — Side by Side

Current state vs.
locked down.

Dimension Now (39 repos, no guard rails) Target (same repos, locked down)
Repo isolation Done — 39 separate repos Done
Org ownership Done — aplayerlabs org Done
Branch protection Done — org ruleset active on all repos Done
Environments Inconsistent — some staging-only, some main-only Three-gate: dev → staging → main
Team members 2 of 4 in org All 4 members invited
Teams / scoping No teams — flat access Per-client teams with scoped access
Naming convention Mixed — ee-gct vs tenbot Consistent client-project prefix
Branch strategy 11 repos staging-only (no main): ecm-cast, ee-moac-sales, aplyr-xyz, ee-orderbook, cm-cogs, ee-moac, ee-sssvend, aa-conrados-prd, hma, ee-sss, dadcooler All repos have main + staging
Client handoff No outside collaborators Read-only access or repo transfer
Merge control Done — maintainers team bypass only Done
05 — Action Plan

Four phases.
No downtime.

Prerequisite: GitHub Team — DONE

Upgraded to GitHub Team ($4/user/month, 2 seats = $8/month). Branch protection and org rulesets are now active.

1
BLOCKED — waiting on GitHub usernames

Add members & create teams

  • Need GitHub usernames from Paul and Raiden (Josh already in as AgentFlame)
  • Once received: invite to org, add to @aplayerlabs/aplayerteam → write access to all repos
  • Per-client teams available if needed later (contractors, external collaborators) — not required for core team
2
As needed (per-project)

Branch conventions

  • Dev branches created incrementally — only when a project goes active
  • No bulk branch creation across all repos
  • Active projects get three branches: dev → staging → main
  • Decide on rename for inconsistent repos (tenbot → advance-tenbot?)
3
DONE

Branch protection + merge control

  • Org ruleset "Protect staging and main" active on all repos
  • "maintainers" team (Rossco only) can bypass — everyone else needs a PR
  • Require PR before merge to staging and main
  • Force push and branch deletion blocked on staging + main
  • dev and all other branches stay completely open
4
As needed

Client access

  • Add client contacts as outside collaborators (read-only)
  • Scope via per-client teams if needed — they only see their repos
  • Client handoff = transfer repo (one click)
06 — Decision Points

Three forks in the road.

Each one needs a team decision. Recommendations are highlighted.

DECISION 01
Rename Inconsistent Repos?
  • A Rename to client-project everywhere — tenbot → advance-tenbot, qbuild → advance-qbuild, dadcooler → jay-dadcooler CONSISTENT
  • B Leave as-is — EE already prefixed, the rest are fine without. Rename only if it causes a real problem.
  • C Prefix only where ambiguous — tenbot is fine, but add client prefix if same name could exist for multiple clients
DECISION 02 — DECIDED
Fix Repos Missing Branches?
  • A Create dev + main on all repos that are missing them, set main as default.
  • B Add branches incrementally — only when a repo is actively moving through the pipeline. CHOSEN
DECISION 03
Client Access Level
  • A No access (deliver via zip / screen share) — current approach, maximum control
  • B Read-only on request — add as outside collaborator to their repo only RECOMMENDED
  • C Collaborator — client can push changes directly (risky for most clients)
07 — Discussion

Questions for
the table.

Members Paul and Raiden need GitHub usernames for org invites. Josh is already in as AgentFlame.
Naming Do we rename tenbot → advance-tenbot and qbuild → advance-qbuild for consistency? Or is the current naming fine?
Branches — DECIDED Dev branches created incrementally — only when a project goes active. No bulk creation.
Infrastructure — DECIDED Coolify dev apps (*.dev.aplayerbrains.com) spun up per-project as needed, not bulk.
Workflow Team pushes to dev freely, Rossco merges dev → staging → main. Does the team understand this flow?
Client Access Have any clients ever asked for repo access? Is this a real need or a hypothetical?
Inactive Repos Some repos look dormant (wealth-diagnostic, sf — no branches). Archive them or leave them?
A Player Labs — Internal Memo — 2026