TomSpecs Model — Document Outlines
Generated — do not edit by hand. Every file in this folder is produced by tom_specs_clitool/bin/outliner.dart
from the live Dart model in tom_specs_model/lib/src/; hand edits are lost on the next run. Hand-written documentation lives in
../../doc/.
To regenerate all outlines at once, run the canonical batch script from tom_specs_clitool/
(this is the drift-proof entry point — re-run it after any model-shape change and commit the diff):
./tool/regenerate_outlines.sh
To regenerate a single outline, run from tom_specs_clitool/ with the root class name. The default output path already points here, so
-o is only needed for a non-standard file name:
dart run bin/outliner.dart --package ../tom_specs_model --root-type <RootClassName>
Add --stop-at-detailed-in (short: -c) to stop expansion at @DetailedIn
boundaries and emit a compact outline:
dart run bin/outliner.dart --package ../tom_specs_model --root-type D00SolutionBlueprint \
--stop-at-detailed-in \
-o ../tom_specs_model/generated-doc/outlines/SolutionBlueprint_compact_outline.md---
Whole-model outline
| Root Class | Description | Outline |
|---|---|---|
DocSpecsProject |
The tree root the tooling walks —
not
an
@Document
. Expands every document root in one outline.
|
outline |
Document outlines
| ID | Document | Root Class | Description | Outline |
|---|---|---|---|---|
| SBP | Solution Blueprint | D00SolutionBlueprint |
Comprehensive specification covering all aspects of the system from current landscape through target operating model, information model, solution architecture, security, experience design, quality & acceptance, and delivery / transition planning. Master document — all others
basedOn
SBP.
|
outline |
| SBP | Solution Blueprint (compact) | D00SolutionBlueprint |
Same as above but tree traversal stops at
@DetailedIn
boundaries — each such section shows a
→ DocId
marker instead of expanding its sub-tree.
|
outline |
| CLA | Current Landscape Assessment | D01CurrentLandscapeAssessment |
Detailed analysis of the current systems and processes the target system will replace — landscape, pain points, metrics, risks, replacement inventory, and migration considerations. | outline |
| TOM | Target Operating Model | D02TargetOperatingModel |
Target business process specification — vision, design principles, catalog, diagrams, improvements, relationships, workflows, cross-process analysis, exceptions, and KPIs. | outline |
| IFM | Information Model | D03InformationModel |
Complete business data model — entities, relationships, data classification, business objects, functions, rules, dictionary, and validation/integrity constraints. | outline |
| RSP | Requirements Specification | D04RequirementsSpecification |
Complete requirements catalog — functional, technical, security, organizational — with traceability, relationships, and coverage against goals, use cases, and tests. | outline |
| ISC | Interaction Scenarios | D05InteractionScenarios |
Use cases derived from the target process steps and actor interactions — catalog, scenarios, diagrams, end-to-end test scenarios, and traceability. | outline |
| ATS | Architecture & Technology Specification | D06ArchitectureTechnologySpecification |
Comprehensive technical requirements — platform, software design, standard software, hardware, operations, communication, system operation, security, architecture, components, framework conditions, and translation handling. | outline |
| IIS | Integration & Interface Specification | D07IntegrationInterfaceSpecification |
Complete specification of interactions between the target system and external systems — inventory, patterns, testing, dependencies, migration, operations, and error handling. | outline |
| SAS | Security & Access Specification | D08SecurityAccessSpecification |
Complete access and authorization specification — user management, authentication, resource protection, authorization, encryption, audit, role matrix, and compliance framework. | outline |
| XDS | Experience Design Specification | D09ExperienceDesignSpecification |
Full UI design and prototype specification — vision, screens, flow, print, errors, help, accessibility, responsive design, components, language selection, prototype, and wireframes/mockups. | outline |
| QAP | Quality & Acceptance Plan | D10QualityAcceptancePlan |
Business-facing quality plan — quality framework, user / technical / operations / documentation criteria, prioritization, acceptance criteria, test strategy, and the full acceptance plan (criteria, process, UAT, defects, sign-off, warranty). | outline |
| DRM | Delivery Roadmap | D11DeliveryRoadmap |
Comprehensive project phase plan — staging strategy, stages, feature prioritization, migration, gates, decisions, initial development flow, and upgrade cycle framework. | outline |
| TRP | Transition & Rollout Plan | D12TransitionRolloutPlan |
End-to-end rollout specification — localization, translation, documentation and training, rollout plan, migration plan, user manuals, training materials, pilot, cutover, knowledge transfer, and warranty/support. | outline |
| CGP | CodeSpecs Projection | D13CodeSpecsProjection |
The Phase-4 CodeSpecs generation input — a flat projection referencing the CodeSpecs subtree roots directly, grouped by
@Comment('locus: …')
into the shared / client-only / server-only project split.
|
outline |
---
Related hand-written documentation
| File | Purpose |
|---|---|
| ../../doc/index.md | Catalogue of all hand-written TomSpecs documentation |
| ../../doc/tom_specs_model_rules.md | The model-authoring authority — section IDs, annotations, structural invariants, and the outliner tool (§11: notation, type expansion, output rules) |
| ../../doc/som_multiplatform_spec_model.md | The SOM authority — nine-language generation, metadata tree, generated SOM surfaces, md/yaml serialization, schema generation, packaging |