[Tech Debt] SIN-Code-Bundle has 7 vendored sub-projects — should be promoted to standalone repos

[Delqhi]

Summary

Full-repo sweep on 2026-06-06 found ~190 files in 7 vendored sub-projects living inside SIN-Code-Bundle/. These are standalone Python packages that have their own pyproject.toml, src/, tests/, and build/ — but are tracked as plain files inside the Bundle repo.

Affected sub-projects

Sub-project path	Package name	Should be promoted to
SIN-Code-Architectural-Debt-Watchdogs/	sin_code_adw	OpenSIN-Code/SIN-Code-ADW-Tool
SIN-Code-Ephemeral-Full-Stack-Mocking-Orchestration/	sin_code_efm	OpenSIN-Code/SIN-Code-EFM-Tool
SIN-Code-Intent-Based-Diffing/	sin_code_ibd	OpenSIN-Code/SIN-Code-IBD-Tool
SIN-Code-Proof-of-Correctness/	sin_code_poc	OpenSIN-Code/SIN-Code-PoC-Tool
SIN-Code-Semantic-Codebase-Knowledge-Graphs/	sin_code_sckg	OpenSIN-Code/SIN-Code-SCKG-Tool
SIN-Code-Verification-Oracle/	sin_code_oracle	OpenSIN-Code/SIN-Code-Oracle-Tool
SIN-Code-Bundle/ (nested self-clone)	n/a	DELETE (it's a non-submodule duplicate of the parent)

Also: Next.js frontend (57+ files)

app/, components/ui/*, hooks/, lib/, public/, styles/, next.config.mjs, package.json, tsconfig.json, etc. form a complete Next.js 15 + shadcn/ui frontend living in the Python CLI repo.

Should be split into OpenSIN-Code/SIN-Code-Bundle-Web and referenced via monorepo / submodule.

Why this matters

1. No independent versioning: changes to the ADW package ship as Bundle releases, even if the Bundle itself is stable.
2. No independent CI: a test failure in EFM blocks Bundle releases.
3. Dependency hell: Bundle's pyproject.toml must list every sub-project's deps, even if a consumer only wants the Bundle.
4. Review surface too large: PRs that touch multiple sub-projects are impossible to review coherently.
5. Contradicts 1-package-1-repo rule: every other SIN-Code tool has its own repo (Discover, Execute, Map, Grasp, Scout, Harvest, Orchestrate). The Bundle broke this pattern for the 7 listed.

Proposed action plan

Phase 1: Tooling (1-2h)

• Create 6 new repos under OpenSIN-Code org
• git mv each sub-project out of Bundle
• Set up CI workflow in each new repo
• Add new repos to Bundle as git submodules (or external deps)

Phase 2: Frontend split (2-3h)

• Create SIN-Code-Bundle-Web repo
• Move Next.js app + components + config
• Add Web repo as submodule of Bundle (or as separate deploy target)
• Update build/release pipeline

Phase 3: Cleanup (30min)

• Remove nested SIN-Code-Bundle/ (the self-clone)
• Update Bundle README + requirements-ecosystem.txt
• Update Sinator-v0 docs that reference Bundle's old layout

Acceptance criteria

• Each sub-project has its own semver
• Each sub-project has its own CI workflow
• Bundle pip install still works (transitively, via submodules or extras)
• Bundle README reflects the new architecture
• 0 vendored sub-projects in Bundle root
• Frontend is a separate deployable unit

Related

• Skill-Audit-Matrix: SIN-Code-Bundle/docs/skill-audit-matrix.md (commit b9e7b42)
• Audit performed by general-purpose sub-agent on 2026-06-06
• Inspired by: the same pattern that was applied to split sin-codocs + sin-codocs-sprint into the merged SIN-Code-Codocs-Skill repo

[Delqhi]

Resolved by v3.0.0/v3.1.0/v3.2.0 release train (2026-06-12):

• v3.0.0 (7962b73): repo renamed SIN-Code-Bundle → SIN-Code, module path github.com/OpenSIN-Code/SIN-Code, race fix in Dispatcher.runOne
• v3.1.0 (610adaa): 5 new packages — agentloop, session, verify, permission, mcpclient (C1-C5, all ≥78% coverage, race-clean)
• v3.2.0 (db0ba3c): hook engine (24 events) + custom slash commands (C7+C8, both ≥94% coverage)

See AGENTS.md §5/§8.