Someli — Code Overlap Matrix¶
This is the source-cited inventory of where the same code lives in more than one repo. Read this before doing cross-repo work; a fix in one repo often needs to be propagated to the siblings (and sometimes you'll discover it was already fixed in one of them).
All paths are relative to someli-gh/.
1. The shared-skeleton pattern¶
someli-api, designer-api, and Someli-admin-api all use the same Express bootstrap skeleton. They were forked from someli-api at different times. The shape is:
<repo>/
├── conf.js # re-exports process.env
├── server.js # boots Express + Socket.IO + MySQL, then mounts routes/routes.js
├── modules/dbDriver/lib/mysql.js # callback-based MySQL pool wrapper
├── actions/actions.js # generic CRUD layer
├── routes/routes.js # one giant file registering hundreds of endpoints
├── helper/ # flat folder of utility modules
└── job_*.js # standalone PM2-runnable scripts
(someli-dashboard-be is a trimmed version of this skeleton — same idea, but only the dashboard slice.)
The skeleton lives in three forks that have drifted independently. The table below quantifies the drift.
2. helper/ overlap — Someli-admin-api vs someli-api¶
Someli-admin-api/helper/ contains 10 files. All 10 share filenames with someli-api/helper/. Of those:
| File | diff line count (someli-api ↔ Someli-admin-api) |
Interpretation |
|---|---|---|
ragProcess.js |
0 | identical — safe to treat as shared |
revokeToken.js |
0 | identical |
tokenGenerator.js |
0 | identical |
webScraping.js |
0 | identical |
stockImage.js |
49 | lightly forked |
index.js |
63 | lightly forked (different re-exports) |
basic.js |
119 | meaningfully diverged |
constants.js |
163 | meaningfully diverged |
aiLogics.js |
396 | heavily diverged — each repo has its own AI logic |
helper.js |
856 | heavily diverged — likely contains the bulk of the per-product business logic |
Source: diff <someli-api/helper/X> <Someli-admin-api/helper/X> | wc -l for each file in Someli-admin-api/helper/.
Action items implied by this table:
- tokenGenerator.js, revokeToken.js, ragProcess.js, webScraping.js should be extracted to a shared npm package — they are byte-identical, and divergence is a real risk.
- aiLogics.js and helper.js divergence is large enough that fixes need to be considered per-repo. Don't assume a fix in one applies to the other.
3. modules/dbDriver overlap¶
modules/dbDriver/lib/mysql.js exists in someli-api, designer-api, and Someli-admin-api. The files differ slightly between designer-api and someli-api. Treat as drifting copies.
4. actions/actions.js overlap¶
Both someli-api/actions/actions.js and designer-api/actions/actions.js provide the same generic CRUD methods (getAll, insertData, updateData, deleteData, fetchAll, customQuery). The designer-api copy is a slightly older fork. Sample diff at line ~285 shows the someli-api copy has been hardened to handle null data and recursive object stringification; the designer-api copy has not.
5. Background jobs — someli-api vs designer-api¶
designer-api has 57 job_*.js files; someli-api has 108. Zero file names overlap. Inspecting the files:
someli-apijobs target the runtime social-media pipeline: publishing (job_facebook_publish.js,job_instagram_publish.js,job_linkedin_publish.js,job_tiktok_content_publish.js), token refresh (job_refresh_fb_token.js), insight aggregation, post validation, paddle webhooks, etc.designer-apijobs target the template / content library content factory: industry-specific generators (job_auto_garge_ceramic_coating.js,job_disability_insurance.js,job_It_cyber_security.js,job_uae_estate.js, …), schedulers (job_schedule_dynamic.js,job_schedule_organization.js), and template validators (job_check_color_with_json.js,job_check_temp_valid.js).
Despite no filename overlap, the internal boilerplate of every designer-api job is identical: dotenv → node-cron → sync-mysql connect → cron.schedule(…) → handler that issues raw SELECT … LIMIT N queries and processes rows. This is the same pattern as the older someli-api jobs. There is room to extract a shared job-base module.
Implication: designer-api is best thought of as a second PM2 worker pool that shares a database with someli-api. The split between them is what kind of work, not what data.
6. Polotno editor fork — someli-platform/polotno-editor vs Someli-Designer/polotno-editor¶
Both customer FE and designer FE bundle their own React + MobX-State-Tree + Polotno editor. They started from the same source and diverged. Concrete differences (sample from diff -rq):
- Renamed file:
brandkitpanel.js(customer) vsbrandkitPanel.js(designer) — same purpose, casing differs - Only in
someli-platform/polotno-editor/:aiContent/,aiImage.js,common/,customTextSection/,favouritesPannel.js,helper/,ImageLibraryPanel.js - Only in
Someli-Designer/polotno-editor/:alltemplatesPanel.js,CustomPageControls.js,CustomWorkspace.js,helper.js - Diverged:
App.js,app.css,carousaltemplatesPanel.js,customUploads.js,icons.js,index.html
Both produce a polotno-bundle.js artifact at their repo root. The customer FE's bundle is 221 KB; the designer FE's is 50 KB (much smaller — the designer's editor is narrower in scope).
Implication: There is no "Polotno editor library" — there are two cousins. Treat each as its own codebase. If a Polotno bug is reported, fix it in the affected fork first; only port to the other if the bug clearly exists there too.
7. Dashboard analytics service — someli-api/dashboard/ vs someli-dashboard-be/¶
someli-dashboard-be/ is a near-copy of someli-api/dashboard/. Differences (diff -rq):
README.md— different (the standalone has its own dev README)routes/index.js— differsserver.js— differs
The standalone repo also has its own mock/ directory used when NODE_ENV=development. The in-process copy in someli-api/dashboard/ does not have this mock layer.
Production runs the in-process copy (mounted into someli-api/server.js at /auth per someli-api/CLAUDE.md). The standalone is for local-dev / future-extraction.
8. someli-mono-repo and someli-project snapshots¶
These two repos are read-only aggregations of the canonical repos. They are kept in git, but they are not auto-synced from the canonical sources; each is the state of an ad-hoc copy at some past date.
| Snapshot path | Mirrors canonical | Drift (file diffs) | Snapshot date (last commit) |
|---|---|---|---|
someli-mono-repo/backend/ |
someli-api/ |
49 file diffs | 2026-01-20 |
someli-mono-repo/frontend/ |
someli-platform/ |
333 file diffs | 2026-01-20 |
someli-project/backend/app-backend/ |
someli-api/ |
49 file diffs (same as above) | 2026-01-23 |
someli-project/frontend/app-frontend/ |
someli-platform/ |
333 file diffs (same as above) | 2026-01-23 |
someli-project/backend/admin-backend/ |
Someli-admin-api/ |
0 — identical | 2026-01-23 |
someli-project/frontend/admin-frontend/ |
admin_console_R/ |
0 — identical | 2026-01-23 |
someli-project/backend/designer-backend/ |
designer-api/ |
6 file diffs (Dockerfile, nginx.conf, push.sh, deploy_image.py, .dockerignore, routes/routes.js) | 2026-01-23 |
someli-project/frontend/designer-frontend/ |
Someli-Designer/ |
14 file diffs (Dockerfile + 13 editor .vue pages) |
2026-01-23 |
Source: diff -rq excluding node_modules, .git, .nuxt, dist, .yarn, lockfiles, doc/, CLAUDE.md, .env*, prebuilt polotno-bundle.*, temp_video_* directories.
Rule: never edit inside someli-mono-repo/ or someli-project/. If they need updating, regenerate from canonical.
9. Canonical-vs-cloned (within this audit's environment)¶
This audit was performed on a workspace where two copies of someli-api and someli-platform coexist:
/home/nino/src/someli/someli-api(canonical working copy)/home/nino/src/someli/someli-gh/someli-api(newer clone)/home/nino/src/someli/someli-platform(canonical working copy)/home/nino/src/someli/someli-gh/someli-platform(newer clone)
The cloned someli-gh/someli-platform is identical to the canonical (same HEAD: 380b2144).
The cloned someli-gh/someli-api is 7 commits ahead of the canonical (d02e2141 vs 8825ecdd). The 7 commits are all small fixes:
d02e2141 Merge PR #1618 from new/axios_version_changes1
56e2fcd0 fix: update axios dependency version to 1.15.0
e4fa35db fix: update publish key retrieval to use configuration file
33940689 fix: correct uid extraction logic in PDF generation process
f2ad2f45 feat: refactor codeChild iteration to use for loop and add debug logging
80a90d67 fix: simplify image source assignment by removing unnecessary base64 conversion
a956405d feat: add support for retrieving images from the Image Library in PDF generation
Concrete file diffs in someli-api (cloned vs canonical, ignoring node_modules, .git, .nuxt, .yarn, lockfiles):
package.json—axiosbumped from^1.9.0to^1.15.0job_carousel_pdf.js— 55 lines of diff (the PDF generation feature work above)slack_notifications_post_disconnect.js— small refactor to readPUBLISH_KEYfrom./confinstead of directly fromprocess.env, plus a newconsole.logat startup- Only-in-canonical (working files that aren't in git):
CLAUDE.md,doc/,.env,1290183.png,img.jpg,routes/temp_video_*directories (Polotno scratch space),.yarnrc
See _meta/canonical-vs-cloned.md for the same comparison for someli-platform.
10. Summary — what to do when you find duplicated code¶
| Pattern | What to do |
|---|---|
Identical file in two repos (e.g., tokenGenerator.js in someli-api/helper/ and Someli-admin-api/helper/) |
Treat as shared. Plan extraction to a small shared package. In the meantime, propagate fixes to both. |
Lightly-forked file (e.g., stockImage.js) |
Read both before fixing. The intent is probably the same; double-apply if the fix is universal. |
Heavily-forked file (e.g., helper.js, aiLogics.js) |
Do not assume parity. Fix only where the user-visible bug is. Note divergence in PR. |
Same boilerplate, different content (e.g., job_*.js files) |
Leave alone. The pattern is shared but the work is distinct. |
Snapshot copy in someli-mono-repo / someli-project |
Never edit. Re-generate from canonical if the snapshot is needed. |
| Two diverged Polotno editor folders | Fix the affected fork; port to the other only with intent. |