spikerj/spikersoft-issues
1
0
Fork 0
Code Issues 196 Pull Requests Actions Packages Projects Releases Wiki Activity

[Backend][Refactor] Finish the SpikerSoft.Business decomposition — physically move the 13 linked source files into their slice projects, and adopt 'new code goes in the slice directory' #566

New Issue
Closed
opened 2026-07-14 14:22:57 +00:00 by spikerj · 2 comments
spikerj commented 2026-07-14 14:22:57 +00:00
Owner
Copy Link
Copy Source

QA Team — filed 2026-07-14 from the README audit, at spikerj's direction (the audit found no existing ticket tracking the completion of this work, and new hires hit the half-migrated state immediately).

Current state (verified in the csproj files): the decomposition slices exist and compile, but 13 source files are still <Compile Include="..\SpikerSoft.Business\..." Link="..."/> links rather than physically-moved files (done deliberately to preserve git history):

Slice Linked files
SpikerSoft.Business.CodeExecution 9
SpikerSoft.Business.Scheduling 2
SpikerSoft.Business.Books 1
SpikerSoft.Business.Identity 1
SpikerSoft.Business.{Ai,Edge,Metrics} 0 (fully physical)

Asks:

  1. Physically move the 13 remaining files into their slice directories (git preserves history through moves well enough with --follow; the link-to-preserve-history rationale has served its purpose).
  2. Adopt the rule (confirmed by spikerj 2026-07-14): new slice code goes in the slice project's own directory (like CodeExecution's Sql/ and Services/Git/), never in SpikerSoft.Business/Domain/... to be linked. The audit's new per-project READMEs state this rule; this ticket is what makes it true in the tree.
  3. Consider whether namespaces on slice-owned classes (e.g. SpikerSoft.Business.Services.Git on CodeExecution-owned provisioners) should be renamed to match their slice, or stay for consumer compatibility — a deliberate call, not drift.

Why now: the README audit documents the phases and the linked-file mechanism for new hires, but a documented half-migration is still a half-migration; this ticket is the thing that lets those READMEs eventually say "one file, one home".

**QA Team** — filed 2026-07-14 from the README audit, at spikerj's direction (the audit found no existing ticket tracking the completion of this work, and new hires hit the half-migrated state immediately). **Current state (verified in the csproj files):** the decomposition slices exist and compile, but **13 source files are still `<Compile Include="..\SpikerSoft.Business\..." Link="..."/>` links** rather than physically-moved files (done deliberately to preserve git history): | Slice | Linked files | |---|---| | SpikerSoft.Business.CodeExecution | 9 | | SpikerSoft.Business.Scheduling | 2 | | SpikerSoft.Business.Books | 1 | | SpikerSoft.Business.Identity | 1 | | SpikerSoft.Business.{Ai,Edge,Metrics} | 0 (fully physical) | **Asks:** 1. **Physically move** the 13 remaining files into their slice directories (git preserves history through moves well enough with `--follow`; the link-to-preserve-history rationale has served its purpose). 2. **Adopt the rule** (confirmed by spikerj 2026-07-14): **new slice code goes in the slice project's own directory** (like CodeExecution's `Sql/` and `Services/Git/`), never in `SpikerSoft.Business/Domain/...` to be linked. The audit's new per-project READMEs state this rule; this ticket is what makes it true in the tree. 3. Consider whether namespaces on slice-owned classes (e.g. `SpikerSoft.Business.Services.Git` on CodeExecution-owned provisioners) should be renamed to match their slice, or stay for consumer compatibility — a deliberate call, not drift. **Why now:** the README audit documents the phases and the linked-file mechanism for new hires, but a documented half-migration is still a half-migration; this ticket is the thing that lets those READMEs eventually say "one file, one home".
spikerj commented 2026-07-17 04:10:10 +00:00
Author
Owner
Copy Link
Copy Source

PR up: spikersoft-backend PR #339 (spikerj/spikersoft-backend#339) — refactor/566-finish-business-decomposition.

  • Ask 1: all formerly link-included sources physically moved into their slices via pure git mv (556 files, 100% similarity). Note: the actual linked set was bigger than the ticket's '13 files' — the CodeExecution slice also glob-linked Domain/CodeExecution/** (49) and Domain/Lessons/** (485), so the PR moves the whole set; details + a scope note in the PR body.
  • Ask 2: the 'new code goes in the slice directory' rule is now the physical reality; READMEs and the wasm-link-include rule updated accordingly.
  • Ask 3 (namespaces): kept as SpikerSoft.Business.* — deliberate consumer-compatibility call, documented in the slice READMEs and csproj comments.

Also fixed en route: spikersoft-api/notifications/tests CI workflows only path-matched 'SpikerSoft.Business/', so after the move slice edits would have silently stopped triggering them — they now also match 'SpikerSoft.Business.*/'.

Verified: SpikerSoft.sln + UnitTests.slnf build clean, full unit suite passes (7,555 Business.Tests among them), Wasm builds with all 8 es translation resources embedded under the pinned names.

Deliberately left as follow-ups (per the audit READMEs): per-slice test projects (#478 convention), a Profile slice for ProfileCompletionValidator, the Business.Identity boundary call.

Will close after the PR merges.

PR up: spikersoft-backend PR #339 (https://git.spikersoft.com/spikerj/spikersoft-backend/pulls/339) — refactor/566-finish-business-decomposition. - Ask 1: all formerly link-included sources physically moved into their slices via pure git mv (556 files, 100% similarity). Note: the actual linked set was bigger than the ticket's '13 files' — the CodeExecution slice also glob-linked Domain/CodeExecution/** (49) and Domain/Lessons/** (485), so the PR moves the whole set; details + a scope note in the PR body. - Ask 2: the 'new code goes in the slice directory' rule is now the physical reality; READMEs and the wasm-link-include rule updated accordingly. - Ask 3 (namespaces): kept as SpikerSoft.Business.* — deliberate consumer-compatibility call, documented in the slice READMEs and csproj comments. Also fixed en route: spikersoft-api/notifications/tests CI workflows only path-matched 'SpikerSoft.Business/**', so after the move slice edits would have silently stopped triggering them — they now also match 'SpikerSoft.Business.*/**'. Verified: SpikerSoft.sln + UnitTests.slnf build clean, full unit suite passes (7,555 Business.Tests among them), Wasm builds with all 8 es translation resources embedded under the pinned names. Deliberately left as follow-ups (per the audit READMEs): per-slice test projects (#478 convention), a Profile slice for ProfileCompletionValidator, the Business.Identity boundary call. Will close after the PR merges.
spikerj commented 2026-07-17 04:16:00 +00:00
Author
Owner
Copy Link
Copy Source

Resolved in spikersoft-backend PR #339 (merged to master). All formerly link-included sources physically moved into their slice projects (556 files, pure git mv), 'new code goes in the slice directory' is now the tree's reality, and namespaces stay SpikerSoft.Business.* as a documented consumer-compatibility call. Follow-ups tracked in the PR body / READMEs: per-slice test projects, a Profile slice for ProfileCompletionValidator, the Business.Identity boundary call. Closing.

Resolved in spikersoft-backend PR #339 (merged to master). All formerly link-included sources physically moved into their slice projects (556 files, pure git mv), 'new code goes in the slice directory' is now the tree's reality, and namespaces stay SpikerSoft.Business.* as a documented consumer-compatibility call. Follow-ups tracked in the PR body / READMEs: per-slice test projects, a Profile slice for ProfileCompletionValidator, the Business.Identity boundary call. Closing.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
agentic
Actionable surfaced by the agentic architecture & security review
 bug
Something is not working
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 invalid
Something is wrong
 question
More information is needed
 sonarqube
Code quality issue surfaced by SonarQube (bug / code smell)
 wontfix
This won't be fixed
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
spikerj (Joseph Spiker)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#566