[Backend][Refactor] Extract the 'Mark Wilson / Marks-Site' client domain (generator-propane service business) out of the SpikerSoft platform codebase #572

New Issue

2026-07-14T14:58:46Z

spikerj commented

2026-07-14 14:58:46 +00:00

QA Team — filed 2026-07-14 from the README audit, at spikerj's direction (decision: separate client/side project — should be extracted).

What's entangled: a second, unrelated business (a generator/propane service company) is woven through the SpikerSoft learning-platform codebase:

SpikerSoft.Business/Domain/Mark_Wilson/ — a domain folder named after a person, holding Customers CRUD including a MigrateCustomersToMongoDB command.
SpikerSoft.Common — carries the "Marks-Site" business models (generator/propane service domain) rather than a contracts project of their own; SpikerSoft.Common is a dependency of nearly everything, so this client's models ship in every service image on the swarm.
SpikerSoft.AI.MCPServer — EchoTool.AddCustomer ("Adds a customer to marks software with AI"), a live registered MCP tool (also covered by #563's cleanup).

Why it matters beyond tidiness: a new hire reading the codebase cannot tell which domains are the product; the client's data models are compiled into every deployed platform service; and a person-named namespace is an onboarding trap.

Ask: extract to its own repo/solution (or at minimum its own bounded contracts + service projects with a non-person-named domain), remove the models from SpikerSoft.Common, and drop the MCP demo tool. Coordinate with #563 (MCPServer cleanup) and #566 (Business decomposition) so the work lands once.

**QA Team** — filed 2026-07-14 from the README audit, at spikerj's direction (decision: separate client/side project — should be extracted). **What's entangled:** a second, unrelated business (a generator/propane service company) is woven through the SpikerSoft learning-platform codebase: 1. **`SpikerSoft.Business/Domain/Mark_Wilson/`** — a domain folder *named after a person*, holding Customers CRUD including a `MigrateCustomersToMongoDB` command. 2. **`SpikerSoft.Common`** — carries the "Marks-Site" business models (generator/propane service domain) rather than a contracts project of their own; SpikerSoft.Common is a dependency of nearly everything, so this client's models ship in every service image on the swarm. 3. **`SpikerSoft.AI.MCPServer`** — `EchoTool.AddCustomer` ("Adds a customer to marks software with AI"), a live registered MCP tool (also covered by #563's cleanup). **Why it matters beyond tidiness:** a new hire reading the codebase cannot tell which domains are the product; the client's data models are compiled into every deployed platform service; and a person-named namespace is an onboarding trap. **Ask:** extract to its own repo/solution (or at minimum its own bounded contracts + service projects with a non-person-named domain), remove the models from `SpikerSoft.Common`, and drop the MCP demo tool. Coordinate with #563 (MCPServer cleanup) and #566 (Business decomposition) so the work lands once.

spikerj commented

2026-07-22 03:04:14 +00:00

Board-sweep status (2026-07-22): the Mark_Wilson client code now lives organized under SpikerSoft.Business/Domain/Mark_Wilson (the #566 business decomposition's physical move), but the EXTRACTION this ticket asks for — its own slice assembly following the SpikerSoft.Business.* pattern — has not happened (no such project exists). Scope is now smaller than when filed: the domain is already isolated in one folder, so the slice split is mostly mechanical + a MediatR Marker registration.

spikerj referenced this issue

2026-07-29 15:32:34 +00:00

Sponsor family card: declutter header, consolidate member photos, promote the $ tracker #831

spikerj commented

2026-07-29 18:34:11 +00:00

Audited against origin/master — NOT DONE. Nothing extracted.

The Mark Wilson / Marks-Site client domain is still fully resident in the platform codebase: 136 files matching marks in spikersoft-backend, 133 files under marks-site in spikersoft-angular. No separate repo, no module boundary, no extraction of any kind.

Notes are accurate as written.

Two observations that may affect how this gets scoped, both from other audits this week:

1. The surface has grown, not shrunk. marks-site picked up work during the epic #722 modernization — E5 wave-2 batch 7 migrated marks-site off ngModel onto Signal Forms. So the client domain has been actively maintained as part of the platform, which is the opposite direction from extraction. Worth deciding whether that's acceptable drift or whether extraction should be prioritised before more platform-wide sweeps pull it further in.

2. It has a live bug that extraction would inherit. #840 — NetworkStatusService at projects/spikersoft/src/app/_services/marks-site/network-status/network-status.service.ts:6 calls the Inject decorator as a function, so DI never resolves. I confirmed it's currently latent (nothing injects that service), but it sits squarely inside the code being extracted. Cheaper to fix now than to carry into a new repo where it'd be someone else's confusing first bug. Same applies to #760 (marks-address duplicate @for track keys plus a stubbed saveAddresses()).

One genuine blocker worth naming. Extraction implies a separate deployment, and this audit found that the deploy path can't currently prove it shipped anything: #615 (root has no git credentials, so sudo git -C /mnt/infrastructure pull fails and is swallowed by || echo "WARNING") and #774 (no post-deploy convergence check anywhere in the shared workflow). Standing up a new service on that pipeline means its first deploy is unverifiable. Worth settling those first — they're already blocking #582 and #519 for the same reason.

No work has landed; this is a clean "not started" with the scope intact.

Audited against `origin/master` — **NOT DONE. Nothing extracted.** The Mark Wilson / Marks-Site client domain is still fully resident in the platform codebase: **136 files** matching `marks` in spikersoft-backend, **133 files** under `marks-site` in spikersoft-angular. No separate repo, no module boundary, no extraction of any kind. Notes are accurate as written. **Two observations that may affect how this gets scoped, both from other audits this week:** **1. The surface has grown, not shrunk.** `marks-site` picked up work during the epic #722 modernization — E5 wave-2 batch 7 migrated marks-site off `ngModel` onto Signal Forms. So the client domain has been actively maintained *as part of the platform*, which is the opposite direction from extraction. Worth deciding whether that's acceptable drift or whether extraction should be prioritised before more platform-wide sweeps pull it further in. **2. It has a live bug that extraction would inherit.** **#840** — `NetworkStatusService` at `projects/spikersoft/src/app/_services/marks-site/network-status/network-status.service.ts:6` calls the `Inject` *decorator* as a function, so DI never resolves. I confirmed it's currently latent (nothing injects that service), but it sits squarely inside the code being extracted. Cheaper to fix now than to carry into a new repo where it'd be someone else's confusing first bug. Same applies to **#760** (marks-address duplicate `@for` track keys plus a stubbed `saveAddresses()`). **One genuine blocker worth naming.** Extraction implies a separate deployment, and this audit found that the deploy path can't currently prove it shipped anything: **#615** (root has no git credentials, so `sudo git -C /mnt/infrastructure pull` fails and is swallowed by `|| echo "WARNING"`) and **#774** (no post-deploy convergence check anywhere in the shared workflow). Standing up a new service on that pipeline means its first deploy is unverifiable. Worth settling those first — they're already blocking #582 and #519 for the same reason. No work has landed; this is a clean "not started" with the scope intact.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#572