Pulse — https://github.com/acme/social-scheduler
Process-health from the repository alone. Observations to discuss, not verdicts.
In plain language (AI-refined)
Over the last two weeks, the team focused on making scheduled publishing more reliable and able to handle more load, alongside new posting features for Facebook, WordPress, and LinkedIn, plus some security improvements and better handling when AI content generation runs into errors. Most of the effort went into building new capabilities, with a good share spent fixing issues along the way. One thing worth raising: there don't appear to be automated tests in place — it's worth asking how the team checks that things work before they go live. Overall this looks like normal, active development, and the point above is a good question to ask rather than a cause for concern.
Questions worth raising
The signals most worth a conversation this period — observations to discuss, not verdicts. Each carries the evidence behind it. Ordered by how much it stands out, not by severity of judgement.
flagWe added about 1,403 lines of product code this period with no test code, and the project has no test files at all — is this covered elsewhere or is testing falling behind?
Behind it: +1,403 code lines, +0 test lines · the project has no test files at all · window 2026-06-18 → 2026-07-01
watch2 commits this period were reverts — what shipped and had to be pulled back, and was the root cause understood?
Behind it: “Revert "scale scheduler to 12 concurrent workers"”; “Revert "stream large media uploads to R2"” · window 2026-06-18 → 2026-07-01
watchlibraries/nestjs-libraries/src/integrations/social/tiktok.provider.ts is one of the period's most-active files and only John Carter has touched it (13 commits) — a single point of knowledge worth spreading?
Behind it: 13 commits, sole author John Carter · window 2026-06-18 → 2026-07-01
watchlibraries/nestjs-libraries/src/integrations/social.abstract.ts and libraries/nestjs-libraries/src/integrations/social/facebook.provider.ts changed together in 5 commits this period (~80% of the time one moved, so did the other) — intended coupling, or a seam worth decoupling?
Behind it: 5 co-changes, ~80% confidence · window 2026-06-18 → 2026-07-01
watchlibraries/nestjs-libraries/src/integrations/social/facebook.provider.ts has been rewritten 3.0× its current size across 6 commits — a settling design, or churn without convergence?
Behind it: churn factor 3.0× (162 lines over 54 now) · 6 commits · window 2026-06-18 → 2026-07-01
watchAbout 55% of Bob Nguyen's 11 classified commits this period were bugfixes — is that firefighting a fragile area, or just where they happened to be assigned?
Behind it: 55% of 11 classified commits are bugfixes · window 2026-06-18 → 2026-07-01
infoAbout 38% of this period's commits (15 of 39) landed on 2026-06-30 versus a typical ~3 a day — was that a batch or merge day, an end-of-sprint push, or just when the work was ready?
Behind it: 15 of 39 commits on 2026-06-30 (typical day ~3) · window 2026-06-18 → 2026-07-01
AI-inferred work items AI
What was built, reconstructed by clustering commits — no Jira. The footprint and commit count under each item are computed locally from the real diff, not the model's say-so; confidence is the model's own estimate from commit metadata alone — a weak signal, so read low / medium with caution. No code leaves the box.
libraries/nestjs-libraries/src/temporal/temporal.module.ts, libraries/nestjs-libraries/src/integrations/social.abstract.ts, libraries/nestjs-libraries/src/integrations/social/tiktok.provider.tslibraries/nestjs-libraries/src/integrations/social/facebook.provider.ts, apps/frontend/src/components/new-launch/providers/facebook/facebook.background.ts, libraries/nestjs-libraries/src/dtos/posts/providers-settings/facebook.dto.tslibraries/nestjs-libraries/src/integrations/social/wordpress.provider.ts, libraries/react-shared-libraries/src/form/multi.select.tsx, apps/frontend/src/components/new-launch/providers/wordpress/wordpress.terms.tsxlibraries/nestjs-libraries/src/integrations/social/linkedin.provider.tsSECURITY.md, .claude/settings.json, libraries/nestjs-libraries/src/integrations/social.abstract.tsapps/frontend/src/components/launches/generator/generator.tsx, libraries/nestjs-libraries/src/database/prisma/media/media.service.ts, libraries/nestjs-libraries/src/openai/generation.error.tsapps/backend/src/api/routes/billing.controller.ts, libraries/nestjs-libraries/src/services/stripe.service.ts, apps/frontend/src/components/layout/gtm.component.tsxlibraries/nestjs-libraries/src/database/prisma/organizations/organization.service.tsREADME.mdapps/frontend/src/components/launches/calendar.tsxCommit work-type mix AI
39 commits classified by intent — the shape of a role: builds vs fixes vs refactors. AI per-commit labels (conventional kinds), cached so re-runs only classify new commits.
feature 62%bugfix 26%docs 10%config 3%
| authori | commitsi | mixi |
|---|---|---|
| John Carter | 26 | feature 73%bugfix 15%docs 8%config 4% |
| Bob Nguyen | 11 | bugfix 55%feature 45% |
| Barbara Ellis | 2 | docs 100% |
Bob Nguyen: a majority of commits look like bugfixes — firefighting, or just where they were assigned? Worth asking.
Demo-risk / quality smells
A rule-based scan of the current code for signs it was rushed toward a demo — high-signal patterns only, framed as questions. "Clean" means none of debug tails, skipped tests, or hardcoded secrets; TODO markers and a thin test ratio are shown for context but don't break "clean". Build / tooling scripts are excluded from the debug scan, and only near-zero-false-positive secret patterns are flagged.
Debug tails left in: 74
libraries/nestjs-libraries/src/integrations/social/bluesky.provider.ts×5, libraries/nestjs-libraries/src/services/email.service.ts×5, libraries/nestjs-libraries/src/upload/r2.uploader.ts×5, libraries/nestjs-libraries/src/integrations/social/wordpress.provider.ts×4
Demo-risk read AI
Scan flags leftover debug output across the code and no detectable test files, though secrets and skipped-tests came back clean
We found 74 spots that look like leftover debug/logging statements — can the team confirm these are intentional and won't leak noise or sensitive detail into production logs?
The scan detected 0 test files across 709 code files. Can the team explain how the software is currently verified before release — automated tests, manual QA, or something else?
Is the absence of tests a real gap, or could tests live in a separate repo or format our scan didn't recognize?
What would it take to add automated tests around the most critical parts of the system, and is that on the roadmap?
On the positive side, we found no hardcoded secrets, no skipped tests, and no leftover TODO markers — can the team confirm that matches their own understanding of the codebase's hygiene?
Per-author profile
Lines added by category — the shape of a contribution, not a score.
| authori | commitsi | prodi | uii | migri | testi | jsi | noise%i | owns%i |
|---|---|---|---|---|---|---|---|---|
| John Carter | 26 | 0 | 63 | 0 | 0 | 323 | 8% | 97.9 |
| Bob Nguyen | 11 | 0 | 399 | 0 | 0 | 618 | 0% | 0.9 |
| Barbara Ellis | 2 | 0 | 0 | 0 | 0 | 0 | 100% | 0.1 |
Current ownership by area
Who holds the live code as of the period end — by git blame over the current
code, so a rewrite reassigns ownership to whoever last touched a line, not who first wrote it.
Percentages are within each area (each row sums to ~100%); the count in grey is that person's
live lines there. Contributors under 1% are hidden.
| js | John Carter 97.6% 66824 |
| ui | John Carter 98.3% 42980 |
Anomaly feed — questions worth raising
Scans current ownership for knowledge concentration — one person holding an outsized share of the code who has since gone quiet. Flagged when someone owns ≥25% of all code, or ≥60% of one of the two largest areas, and hasn't committed for 60+ days before the period end. An empty feed means none was found.
Who introduced new files in the period
Who created new files in the window — file creations attributed to their author, counted and split by category (the count, then the share within that area). A third lens beside "who holds the code now" (ownership) and "what grew" (growth). Only meaningful files count, so bots adding lockfiles or generated output never show up here.
| ui | Bob Nguyen 2 (100%) |
| js | Bob Nguyen 2 (100%) |
Rework hotspots
Most-touched meaningful files → "why so much?". Settled = quiet since well before the period end.
| commitsi | churni | last touchedi | filei | authorsi |
|---|---|---|---|---|
| 13 | 68 | 2026-06-30 | libraries/nestjs-libraries/src/integrations/social/tiktok.provider.ts | John Carter |
| 6 | 162 | 2026-07-01 | libraries/nestjs-libraries/src/integrations/social/facebook.provider.ts | Bob Nguyen, John Carter |
| 5 | 95 | 2026-07-01 | libraries/nestjs-libraries/src/integrations/social.abstract.ts | Bob Nguyen, John Carter |
| 5 | 37 | 2026-06-30 | libraries/nestjs-libraries/src/integrations/social/linkedin.provider.ts | Bob Nguyen, John Carter |
| 4 | 76 | 2026-06-30 | libraries/nestjs-libraries/src/temporal/temporal.module.ts | John Carter |
| 3 | 191 | 2026-06-30 | libraries/nestjs-libraries/src/integrations/social/wordpress.provider.ts | Bob Nguyen, John Carter |
| 3 | 25 | 2026-06-30 | libraries/nestjs-libraries/src/integrations/social/bluesky.provider.ts | John Carter |
| 3 | 20 | 2026-06-30 | libraries/nestjs-libraries/src/integrations/social/instagram.provider.ts | John Carter |
| 2 | 8 | 2026-06-30 | libraries/nestjs-libraries/src/3rdparties/heygen/heygen.provider.ts | John Carter |
| 2 | 13 | 2026-06-30 | libraries/nestjs-libraries/src/integrations/social/pinterest.provider.ts | John Carter |
| 2 | 8 | 2026-06-30 | libraries/nestjs-libraries/src/integrations/social/whop.provider.ts | John Carter |
| 2 | 4 | 2026-06-26 | libraries/nestjs-libraries/src/services/stripe.service.ts | John Carter |
| 1 | 103 | 2026-07-01 | apps/frontend/src/components/new-launch/providers/facebook/facebook.background.ts | Bob Nguyen |
| 1 | 44 | 2026-07-01 | apps/frontend/src/components/new-launch/providers/facebook/facebook.preview.tsx | Bob Nguyen |
| 1 | 92 | 2026-07-01 | apps/frontend/src/components/new-launch/providers/facebook/facebook.provider.tsx | Bob Nguyen |
Churn factor
Churn over the analyzed window ÷ current size — a high ratio means a file kept being rewritten lately.
| factori | churni | nowi | commitsi | last touchedi | filei |
|---|---|---|---|---|---|
| 3.0x | 162 | 54 | 6 | 2026-07-01 | libraries/nestjs-libraries/src/integrations/social/facebook.provider.ts |
| 1.0x | 103 | 104 | 1 | 2026-07-01 | apps/frontend/src/components/new-launch/providers/facebook/facebook.background.ts |
| 1.0x | 92 | 93 | 1 | 2026-06-30 | libraries/react-shared-libraries/src/form/multi.select.tsx |
| 1.0x | 58 | 59 | 1 | 2026-06-30 | apps/frontend/src/components/new-launch/providers/wordpress/wordpress.terms.tsx |
Semantic churn
Functions rewritten most often → "why so much?". The function-level twin of rework hotspots: parsed with tree-sitter, across the busiest parseable files, showing functions changed in 2+ commits.
| commitsi | functioni | filei |
|---|---|---|
| 5 | uploadedVideoSuccess | libraries/nestjs-libraries/src/integrations/social/tiktok.provider.ts |
| 5 | post | libraries/nestjs-libraries/src/integrations/social/facebook.provider.ts |
| 4 | fetch | libraries/nestjs-libraries/src/integrations/social.abstract.ts |
| 4 | getTemporalModule | libraries/nestjs-libraries/src/temporal/temporal.module.ts |
| 3 | post | libraries/nestjs-libraries/src/integrations/social/instagram.provider.ts |
| 2 | constructor | libraries/nestjs-libraries/src/integrations/social.abstract.ts |
| 2 | prepareMediaBuffer | libraries/nestjs-libraries/src/integrations/social/linkedin.provider.ts |
| 2 | authenticate | libraries/nestjs-libraries/src/integrations/social/wordpress.provider.ts |
| 2 | uploadVideo | libraries/nestjs-libraries/src/integrations/social/bluesky.provider.ts |
| 2 | sendData | libraries/nestjs-libraries/src/3rdparties/heygen/heygen.provider.ts |
| 2 | post | libraries/nestjs-libraries/src/integrations/social/pinterest.provider.ts |
| 2 | uploadMediaToWhop | libraries/nestjs-libraries/src/integrations/social/whop.provider.ts |
Semantic growth over the period
2026-06-18 → 2026-07-01 · units, not lines — measured at the window's first commit vs its last. Functions and classes come from parsing the code (tree-sitter); the other rows are per-stack file / feature counts.
| uniti | starti | endi | Δi |
|---|---|---|---|
| apps/backend/modules | 47 | 47 | 0 |
| apps/commands/modules | 5 | 5 | 0 |
| apps/extension/modules | 9 | 9 | 0 |
| apps/frontend/components | 300 | 300 | 0 |
| apps/frontend/modules | 20 | 21 | +1 |
| apps/orchestrator/modules | 21 | 21 | 0 |
| apps/sdk/modules | 2 | 2 | 0 |
| components | 29 | 29 | 0 |
| modules | 271 | 272 | +1 |
| functions | 2596 | 2608 | +12 |
| classes | 303 | 303 | 0 |
What exists now (feature surface)
A rough count of the distinct units that exist at the end of the window, per stack — files for most stacks (components, modules, prod / test files) or real features for some (routes, models). It shows how broad the product is, not how good or how much code; counts aren't comparable across stacks, so don't add them up.