Repository layout and git strategy

Layout

C:\Source\IncicoV3
├── CLAUDE.md / AGENTS.md        project notes and agent instructions
├── README.md
├── netlify.toml                 website build (base = web)
├── .gitignore                   node_modules, dist, .env*, key.properties, *.keystore, Secrets.plist
├── .env.example                 names of every build-time variable, no values
├── docs/
│   ├── superpowers/specs/       dated design specs (this design's summary lives here)
│   ├── architecture/*.puml      diagrams, ASCII-only
│   ├── vectors/*.json           golden test vectors shared by both apps
│   └── coding-guidelines.md, unit-tests.md, database-principles.md, git-strategy.md (copied from Saymail, adapted)
├── mobile/
│   ├── design/                  README.md, tokens.json, i18n/, fonts/, licenses/, brand/ (no SPECIFICATION.md — this documentation site is the specification)
│   ├── android/                 Gradle project, package nl.sefaja.incico
│   └── ios/                     Incico/Incico.xcodeproj, Incico/Incico/… (sources), Incico/IncicoTests/…, release/ (build/config scripts), mac-run.ps1 (PC-side harness that runs build/test on the Mac mini)
├── supabase/                    config.toml, migrations/, functions/, tests/, seed.sql, email-templates/, deploy.ps1
├── tools/                       i18n-diff.mjs, tokens-check.mjs, lib/, test/ (vectors-check.mjs arrives in phase 3)
└── web/                         Astro site (marketing, docs, legal, account deletion page)

The Supabase project sits at the repo root rather than under web/ (Saymail’s historical placement) because the apps, not the website, are its main client.

Branches

Copied from Saymail’s docs/git-strategy.md:

• main: every commit shippable; store releases and website deploys come from here.
• develop: integration branch, always ahead of or equal to main.
• feature/<name>, fix/<name>, chore/<name> branch from and merge to develop; hotfix/<name> branches from and merges to main, then main is back-merged into develop immediately.
• Merge-based, no rebasing of shared branches. Direct pushes allowed; PRs welcome when review helps.
• Every merge into develop adds a manual-test checklist line to test.md under a ## YYYY-MM-DD heading (Saymail’s AGENTS.md rule).

What ships from where

Surface	Command	Branch
Website	Netlify auto-deploy	main (production), develop (deploy preview)
Supabase	supabase/deploy.ps1	main → production, develop → staging
Android	gradlew :app:testDebugUnitTest :app:bundleRelease then Play Console upload	main
iOS	mobile/ios/release/ios-release.sh on the Mac mini	main

Versioning

One version number for both apps, MAJOR.MINOR.PATCH, starting at 3.0.0, stored in one place (mobile/version.json) and read by Gradle and by an Xcode build phase, so the two apps never drift the way Saymail’s did (Android 3.5/27 versus iOS 1.0/23). Build numbers (versionCode, CURRENT_PROJECT_VERSION) are a monotonically increasing integer in the same file. chore(release): v3.x.y commits bump it. A mobile_releases table (as in Saymail) tells old clients when a forced update applies.

Commit messages

Conventional prefixes (feat:, fix:, chore:, docs:, test:), imperative mood, body explains why. Release commits are chore(release): v3.0.0.