tspec: Compiler-Enforced Project Management for Enterprise Teams📋

From 300-Line Scanner to Enterprise Platform📋

The versus series found 42 gaps where typed specifications fall short. This series closes every one.

The Gap-Closure Matrix📋

Every limitation identified in the versus series maps to a tspec component:

What tspec Is📋

tspec is a C# product built on a Diem CMF instance. It has language backends (C#, TypeScript, Java, Groovy, Python, Go, Rust) that scan codebases and produce JSON. The Diem instance stores, visualizes, and manages everything.

Language Backends (C#, TS, Java, Groovy, Python, Go, Rust)
  → JSON scan results
    → Diem CMF Instance (C#/.NET)
      → API (auto-generated from content model)
      → Dashboard (Blazor admin, auto-generated)
      → Workflow engine (coverage-gated transitions)
      → Integrations (Jira, Slack, CI/CD)

The product eats its own dog food: tspec's own Diem instance tracks tspec's own requirements using the Requirements DSL.

Table of Contents📋

Part I: The Product Vision📋

A 300-line scanner proved compiler-enforced traceability works. A Diem instance makes it a product. The three-layer architecture, the 42 gaps, and why large industrial CAC40 companies need what Jira + Xray cannot provide.

Part II: The Meta-Metamodel — Custom Requirement Flavors📋

Epic, Feature, Story, Task is one flavor. SAFe uses Capability, Feature, Story, Enabler. Your client uses Program, Capability, Requirement, Work Item. The M3 layer handles all of them — plus Bug<TTarget>, support tickets with L1/L2/L3 levels, and a first-class maintenance mode.

Part III: TypeScript Hierarchy Redesign📋

The versus series said TypeScript hierarchy is flat. Here's the fix: Feature<TParent extends Epic> with generic constraints, generated from the flavor configuration, backward-compatible with existing code.

Part IV: Custom Workflows — DSL and YAML📋

Draft to Done is one workflow. Not the only one. CMF Workflow DSL attributes for .NET teams, YAML definitions for everyone else. Coverage-gated transitions: you can't mark "Done" until the scanner says 100%.

Part V: Language Backends — One Protocol, Seven Scanners📋

C#, TypeScript, Java, Groovy, Python, Go, Rust. Each backend understands its language's type system. All produce the same JSON. The Diem instance doesn't care which language produced the scan.

Part VI: Developer Experience — tspec work, done, next📋

tspec work --item #ID fetches the item, creates a branch, opens files, lists ACs, transitions to InProgress. tspec done scans, pushes, opens a PR, transitions to Review. The CLI becomes a daily driver, not just a scanner.

Part VII: The Diem Instance — 200 Lines of Content Model📋

tspec's server is a Diem instance. Like a blog is a WordPress instance. ~200 lines of C# content model with Diem attributes. Diem generates the API, the Blazor dashboard, the workflow engine, the search, the pagination — everything.

Part VIII: Dashboard Deep-Dive📋

Coverage matrix, Kanban board, trend charts, hierarchy tree, feature detail, sprint view, diff view — all auto-generated by the Diem Admin DSL from the content model.

Part IX: The Stakeholder View — Closing BDD's Advantage📋

PMs can't read abstract classes. So the dashboard renders JSDoc as natural-language bullet points. Approval workflows, comment threads, Gherkin export, PDF export, and manual test tracking for QA.

Part X: Dog-Fooding — tspec Tracks tspec📋

The ultimate proof: tspec's own Diem instance uses the Requirements DSL to track tspec's own features. If the product breaks, its own compliance drops, its own quality gate fails. The product refuses to ship a broken version of itself.

Part XI: Enterprise Features — CAC40 Scale📋

SSO, RBAC, audit trails, multi-repo federation, multi-tenant with three deployment models, on-premise Docker/K8s, data residency, and compliance certifications.

Part XII: Integrations — Bidirectional Everything📋

Jira sync generates features FROM tickets; push updates coverage BACK to Jira. Azure DevOps, Linear, Slack, GitHub Actions, GitLab CI, Jenkins, OpenAPI bridge, Grafana metrics.

Part XIII: Roadmap and Go-to-Market📋

Phase 1 ships the OSS core with dog-fooding from day one. Phase 4 targets enterprise contracts. Free CLI, $15/user/month cloud, custom enterprise pricing.

How to Read This Series📋

CTOs and engineering directors should read Parts I (Vision), XI (Enterprise), and XIII (Roadmap) for the business case and deployment model.

Software architects should read Parts II (Meta-Metamodel), III (Hierarchy), IV (Workflows), and VII (Diem Instance) for the technical architecture.

Developers should read Parts V (Backends), VI (DX), and VIII (Dashboard) for the daily workflow.

QA engineers and PMs should read Parts IX (Stakeholder View) and IV (Workflows) for how they interact with the system.

Anyone in a hurry should read Part I (Vision) and Part VII (Diem Instance) — the problem and the architectural answer.

Related Posts📋

This series builds on:

• Onboarding Typed Specifications — the seven-part implementation series (V1)
• Typed Specifications vs. Everything Else — the comparison series that identified the 42 gaps
• Building a Content Management Framework — the Diem CMF architecture (13 parts)
• Requirements as Code in C# — the Roslyn-based precedent
• Scaling Requirements as Code — the adapter/codegen pattern
• Where Requirements Meet DDD — the DDD mapping