Skip to content

Documentation Verification Report

A pass to confirm that quantitative and pattern-based claims across the doc set still match the codebase. This report lists what's correct, what's drifted, and what needs follow-up.

Generated as a snapshot. Re-run when the codebase changes materially.

Summary

Category Result
Claims verified ✅ 18
Claims with drift 🔧 6
Claims requiring follow-up ⚠ 3

The drifts are mostly small quantitative figures inherited from the original codebase audit. None of the architectural / strategic recommendations are invalidated by the findings. Three significant fixes are required (S3 instantiation count, package count, images still in package.json).

A. Verified — claims match the codebase ✅

These claims are confirmed accurate as of the verification pass.

Claim Where claimed Reality
routes/routes.js is 21,631 lines enterprise-readiness.md §1.1, §1.5, architecture-overview.md ✅ 21,631
routes/auth.js is 24,432 lines Same ✅ 24,432
~46,000 combined route-file lines enterprise-readiness.md §1.5 ✅ 49,422 across all six route files
108 job_*.js files at root jobs-inventory.md, enterprise-readiness.md ✅ 108
3 generate_*.js files jobs-inventory.md ✅ 3
5 jobs in user_specific_contents_ai/ user-specific-ai.md ✅ 5
3 jobs in dashboard/services/ dashboard-analytics.md, jobs-inventory.md ✅ 3
39 PM2 apps in ecosystem.config.js jobs-inventory.md, deployment.md ✅ 39
49 files contain Polotno hardcoded key media-processing.md, Integration-inventory.md §16, security.md ✅ 49
97 createInstance vs 75 instance.close (= 22 leak sites) media-processing.md, Integration-inventory.md §16 ✅ 97 / 75 / 22
36 files use Sharp media-processing.md ✅ 36 (across both quote styles)
892 references to DB-credential conf.* data-model.md, Integration-inventory.md §28 ✅ 892
127 sync-mysql callers enterprise-readiness.md, dependencies-inventory.md ✅ 127
214 tables in schema data-model.md ✅ 214
tAccounts.corpusName does not exist data-model.md §1, rag-pipeline.md (flagged as cross-doc inconsistency) ✅ confirmed absent
tJobs.jobId does not exist data-model.md §1, §5.11 ✅ confirmed absent
tMember.auth_pass DEFAULT 'Welcome!1' data-model.md §1 ✅ confirmed in schema
1,490 commits to routes/routes.js, 21 contributors enterprise-readiness.md §1.5 ✅ 1,490 / 21
Schema typos tAccontInsights, tTempalte_Status, stylePriorty exist data-model.md §1 ✅ confirmed

B. Drift — claims that need correcting 🔧

These have inaccuracies that warrant fixes.

B.1 S3 instantiation count: claimed 36, actual ~86

Claimed:

"36 separate S3 client instantiations" — enterprise-readiness.md §1.5 (Hard Truth #8) and §5.1 (Language & Runtime)

Reality: 86 unique files instantiate new AWS.S3 (91 total occurrences).

Impact: The "duplications as organizational symptom" argument is stronger, not weaker, with the corrected number. The 36 figure was inherited from earlier ad-hoc counting (likely a pattern that matched only one variant). The fix amplifies the point being made.

Recommended correction: Replace "36 separate S3 client instantiations" with "86 separate S3 client instantiations" in both locations.

B.2 Package count: claimed 91 direct deps, actual 94

Claimed:

"Direct dependencies: 91" — dependencies-inventory.md §1 At a Glance

Reality: jq '.dependencies | length' package.json returns 94.

Drift: The doc table in §2 lists 91 entries; the actual package.json has 94. Missing from the doc: oauth-1.0a (used 2× in OAuth signing), pdf.js-extract (2× — alternate PDF parser), socket.io (3× — real-time WebSocket). These are listed elsewhere in the doc but not in the §2 catalog table.

Impact: Three packages are described in narrative form (e.g., socket.io in §6 of related docs) but missing the catalog row. The "removable in §6" recipe and consolidation tables are unaffected — they list real targets correctly.

Recommended correction: - Update §1 At-a-Glance count: 91 → 94 - Add three rows to §2 catalog with the correct usage counts

B.3 The images package — claimed removable, still in package.json

Claimed:

"Already-confirmed unused; ... Remove" — dependencies-inventory.md §2

Reality: images is still in package.json ("images": "^3.2.4"). The recommendation was made but not actioned (consistent with the user noting they have read-only access).

Impact: No factual error in the doc — it correctly says "Remove" as a recommendation. But readers may interpret status as "already removed."

Recommended correction: Add an explicit "as of audit, not yet removed" note in the package row, distinguishing recommendations from completed actions.

B.4 Endpoints count: claimed ~708, actual ~728

Claimed:

"~708 endpoints across 6 route files" — README.md, API-inventory.md, enterprise-readiness.md §4.2 finding, §4.5 finding

Reality: 728 endpoints total (router.{get,post,put,delete,patch,all} counts across the 6 route files). Per-file breakdown: - routes/auth.js: 291 - routes/routes.js: 394 - routes/social.js: 15 - routes/paddle.js: 2 - routes/partnerAuth.js: 4 - dashboard/routes/index.js: 22 - Total: 728

Impact: Minor — the "~708" was approximate, but a sharper number is available. The strategic argument (no API contract for 700+ endpoints) is unaffected.

Recommended correction: "~708" → "~728" or simply "~700" in 4 locations.

B.5 Env-var count framing: claim is technically correct but misleading

Claimed:

"~72 environment variables" — README.md, getting-started.md, configuration.md (implicitly)

Reality: - conf.js has 46 process.env.* references - conf.js + dashboard/conf.js combined: 51 - The whole codebase has 72 unique env vars (process.env.* referenced anywhere)

Impact: The "72" number is technically right when counting unique env vars across the whole codebase, but the doc framing implies they're all in conf.js (only 46 are). Readers looking at conf.js will find ~46, not 72.

Recommended correction: Clarify the framing in configuration.md: "46 in conf.js + 5 additional in dashboard/conf.js + 21 read directly from process.env in worker / route files = ~72 unique env vars referenced across the codebase."

B.6 MySQL driver counts: small drift on mysql2

Claimed:

"mysql2 (53 references)" — dependencies-inventory.md §2

Reality: - require('mysql2') directly: 16 files - require('mysql2/promise'): 36 files - Combined: 52 files (the original 53 was off by 1, likely because grep matched a comment somewhere)

Impact: Negligible — the architectural argument doesn't change.

Recommended correction: Optional — update the count from 53 to 52. The strategic point holds either way.

C. Follow-up needed ⚠

These items can't be verified from the codebase alone and should be checked against external sources.

C.1 OAuth callback paths

Claimed: Various docs reference paths like /social/google/callback, /social/facebook/callback, etc.

Status: Not exhaustively verified against routes/social.js line by line. The claim that callbacks exist is correct (15 endpoints in routes/social.js); the exact paths are convention rather than verified.

Recommended action: Already flagged in verify-markers.md as an existing [VERIFY] item — leave as is.

C.2 RAG corpus identifier location

Claimed: rag-pipeline.md referenced tAccounts.corpusName. The verification confirmed this column does NOT exist. The follow-up: where is the corpus identifier actually stored?

Status: Not yet verified. Likely candidates: tCloudKnowledgeBase table (which exists and is referenced in code), or a JSON column on tAccounts (e.g., industry_classifications).

Recommended action: Already flagged in data-model.md §8 (Cross-Doc Consistency Issues) and tracked. Investigate by running SHOW CREATE TABLE tCloudKnowledgeBase or grepping the codebase for "ragCorpus" usage with table joins.

C.3 Job-type code list

Claimed: data-model.md previously listed DGEN, UGEN, UCL, TCC, PIC, CGEN, UMGEN, RAGCON, TSB, HPB, CLKB, TRCON, TCON. jobs-inventory.md lists CGEN, UGEN, DGEN, DPGEN, UMGEN, TIV, MCC, TCH, UCL, TSB, FC, TCON, RTCON, RGEN. Two different sets.

Status: Cannot be verified from code alone — need a SELECT DISTINCT type FROM tJobs against the running DB to settle the canonical list.

Recommended action: Already flagged in data-model.md §8 (Cross-Doc Consistency Issues) and tracked. Run the DISTINCT query when DB access is available.

D. Cross-cutting checks that passed

The following higher-level verifications also held:

  • Three DB drivers in concurrent use: mysql (1 file), mysql2 direct (16), mysql2/promise (36), sync-mysql (127) — confirms the "three drivers" claim with the right counts.
  • tMember.auth_pass DEFAULT 'Welcome!1' in schema: confirmed via direct grep of someli-schema.sql.
  • The 4 newly-added integrations in Integration-inventory.md (Impact.com, GHL, Teams runtime, Teams CI/CD) are all backed by actual code references at the cited file/line locations.
  • Polotno integration depth: 49 hardcoded-key files matches; 97 createInstance vs 75 instance.close (= 22 leak sites) holds.
  • Hardcoded secrets at file level: Polotno key, Slack token, session secret all confirmed present in source.
  • Schema integrity: 0 FOREIGN KEY constraints, 111 KEY/PRIMARY KEY declarations — confirms the "no FKs at the schema level" finding.

Concrete edits to apply, ordered by impact:

# Doc Change
1 enterprise-readiness.md §1.5 (Hard Truth #8) "36 separate S3 client instantiations" → "86 separate S3 client instantiations"
2 enterprise-readiness.md §5.1 (Language & Runtime, npm cultural artifact paragraph) Same fix as #1
3 dependencies-inventory.md §1 At a Glance "Direct dependencies: 91" → "Direct dependencies: 94"
4 dependencies-inventory.md §2 catalog Add three missing rows: oauth-1.0a (2×), pdf.js-extract (2×), socket.io (3×)
5 dependencies-inventory.md §2 (images row) Add "as of audit, not yet removed despite zero usage" note
6 README.md, API-inventory.md, enterprise-readiness.md (×2 references) "~708 endpoints" → "~728" or just "~700+"
7 configuration.md Clarify env-var framing: "46 in conf.js + 5 in dashboard/conf.js + ~21 referenced directly from worker/route files = ~72 unique"
8 dependencies-inventory.md §2 (mysql2 row) "53" → "52" (optional; trivial)

After these eight edits, the headline numbers across the doc set match the codebase as of the audit date.

F. What the verification did NOT cover

In the interest of staying focused, this pass did not exhaustively verify:

  • Architectural narratives (e.g., "the content pipeline goes through X then Y") — these would require reading the actual control flow, which is more than a quantitative grep
  • Operational claims (e.g., "the dashboard is mounted at /auth") — these would require running the app
  • Claimed statuses on external integrations (e.g., "Stripe is legacy", "Unsplash is disabled") — these need confirmation from product/operations
  • Most [VERIFY] markers — those are already tracked in verify-markers.md as known follow-ups
  • Doc cross-links — every [some-doc.md](some-doc.md) should resolve; spot-checked a few but didn't validate every link

A tighter automated pass — schema diff against someli-schema.sql, link-check on all markdown, periodic re-counts of headline numbers — would catch drift earlier. Worth scripting if the docs are going to be maintained long-term.

G. How to keep the docs honest going forward

The drifts found here mostly come from inherited claims (the 708, the 36, the 72) that were never re-verified when subsequent docs cited them. The discipline that prevents this:

  1. Don't quote a number from another doc without re-deriving it. If dependencies-inventory.md says 91, don't cite "91" in a new doc — re-grep and cite the freshly-verified number.
  2. Add a "Last verified" line to docs whose claims are time-sensitive. Headline numbers age; refresh quarterly.
  3. Move the headline numbers to a machine-readable source (e.g., a metrics.json produced by a script that runs the same greps as this verification). Then docs can pull from it rather than embedding stale snapshots.
  4. Run this verification as part of CI for any PR that touches the audit tree (someli-doc/audit/) and references a counted number.

This last item is the right long-term fix. The doc set is now ~30 documents and ~13,000 lines of prose; manual verification works once but doesn't scale. A small scripts/verify-doc-claims.sh that re-runs the greps in this report and exits non-zero on drift would catch all of B.1–B.6 before merge.