Skip to content

Working With someli-project

Same rules as someli-mono-repo: do not edit code here. This is a snapshot.

What's different from someli-mono-repo

someli-mono-repo someli-project
Scope App pair only (BE + FE) All three pairs (admin, designer, app)
Created via be-main / fe-main two-branch merge one-shot six-commit import per product
Admin-pair freshness n/a byte-identical to canonical (clean)
Designer-pair freshness n/a small drift (14 FE pages, 6 BE infra files)
App-pair freshness stale (49 BE + 333 FE diffs) stale (same diffs — inherits the same snapshot)
First commit date 2026-01-20 2026-01-23

Use cases

Use case OK? Why
Reading the full platform code in a single editor Single tree, broad scope. The admin and designer pairs are accurate.
Onboarding a new engineer to the whole platform shape The directory layout under backend/ and frontend/ is itself a useful map.
Running the app-pair locally Use the canonical someli-api / someli-platform repos — the snapshot is too stale.
Running the admin or designer pair locally Possible (snapshot is close to canonical), but you might as well use the canonical repo.
Making changes and committing Lost on next snapshot refresh. Edit the canonical repo.
Pointing CI / deploy at this repo No CI here; canonical repos own the deploy pipelines.

If asked to refresh this snapshot

The pattern from git log is a per-product feat(main): add <X> commit. To redo it:

  1. Decide which products are being refreshed (probably the stale app-backend / app-frontend).
  2. From the canonical repo, archive a clean snapshot: git archive --format=tar HEAD | (cd /target/dir && tar xf -).
  3. Replace the relevant subtree under backend/ or frontend/.
  4. Commit with the existing message style: feat(main): add <product> <side>.

As before, talk to the snapshot's downstream consumers before refreshing.

Why two aggregated repos exist

Best guess from the commit history: someli-mono-repo was an earlier attempt (2026-01-20) that combined just the app pair; someli-project (2026-01-23) extended the idea three days later to also pull in the admin and designer pairs. The earlier repo was not deleted, so both now exist. The team should decide whether to retire someli-mono-repo — keeping both is a maintenance burden without clear benefit.