feat: add code-aware bootstrap baselines

FRAMEWORK.md

@@ -4,6 +4,12 @@ This document consolidates the architecture of the AI-driven Product Engineering
 
 The goal is not just to organize documents. The goal is to create a pipeline where product, specification, planning, execution, and audit form a single system.
 
+## 1.1 Pre-Specification Baseline
+
+Before a real Specification is authored, every product establishes a complete Product Landscape and the shared `knowledge/`, `engineering/`, and `design/system/` contracts. With existing code, these documents distinguish observed evidence from inference and inventory every code root, module, interface, data boundary, integration, rule, test, configuration, and design asset before domain modeling. Without code, they are explicit hypotheses with pending human decisions. A delivery Domain, Goal, Feature, or Use Case is derived only after the landscape is complete; a Specification requires the approved Product Landscape, Engineering System, and Design System.
+
+Implementation roots sit beside `product/` and use semantic role names such as `web/`, `api/`, `worker/`, `mobile/`, `infrastructure/`, or `library/`. The framework records them in the manifest rather than embedding application code. When a requested implementation does not exist, the responsible agent first identifies the intended stack and verifies the official scaffolding command before proposing its execution.
+
 ## 1. Thesis
 
 This framework treats documentation as engineering infrastructure.
@@ -138,7 +144,13 @@ The Design System is an optional shared product artifact for products with recur
 
 ### Engineering System
 
-The optional Engineering System versions stable architecture, module and data ownership, integrations, standards, quality attributes, operations, and evidence under `engineering/`. Its detailed versioning, maturity, hashing, migration, and approval contract lives in [`docs/engineering-systems.md`](docs/engineering-systems.md). Specification and approved `DEC-*` records remain authoritative when contracts conflict.
+The optional Engineering System versions stable architecture, module and data ownership, integrations, standards, quality attributes, operations, and evidence under `engineering/`. It models systems, applications, components, repositories, interfaces, data stores, and deployments as independently identified graph entities, so one product may span monorepos, polyrepos, shared components, and multiple deployables without encoding those relations in folder position. Its detailed contracts live in [`docs/engineering-systems.md`](docs/engineering-systems.md) and [`docs/engineering-catalog-and-standards.md`](docs/engineering-catalog-and-standards.md). Specification and approved `DEC-*` records remain authoritative when contracts conflict.
+
+`engineering-orchestrator` governs completeness and sequencing across `technical-landscape`, `engineering-standards`, `operations-baseline`, `engineering-evidence`, and final `engineering-system` consolidation. Each specialist owns its canonical contracts; the orchestrator never authors them, and `engineering-system` aggregates and versions them without absorbing their ownership. The baseline stops at human approval before Domain modeling or delivery-specific Technical Discovery.
+
+Engineering baseline execution supports `sequential` and `delegated` modes. Sequential execution is the compatible default. Delegated execution uses harness-native subagents under persisted dispatch envelopes with minimal context, bounded parallelism, explicit dependency phases, disjoint write scopes, and hash-verified compact returns. `dispatch-orchestrator` owns assignment and observation; `subagent-return-reviewer` validates returns; the CLI persists their contracts but never starts an agent itself. Technical Landscape runs first; Standards and Operations may then run concurrently; Evidence follows their returned contracts; Engineering System aggregates last. If native subagents are unavailable, the declared fallback applies without weakening gates or importing the entire specialist conversation into the parent context.
+
+Engineering standards are versioned, verifiable rules composed through profiles and applied by entity type, capability, or explicit assignment. A more specific contract may add constraints but cannot silently weaken an inherited required standard. Divergence requires a scoped, governed exception or approved decision.
 
 ### Engineering Quality System
 
@@ -209,7 +221,7 @@ An adopter repository owns one framework root, `product/`. Its stable ownership
 | `knowledge/` | Product rules, conventions, cross-cutting decisions, imports, and durable evidence. |
 | `domains/` | Domain → User Goal → Feature → Use Case hierarchy and delivery artifacts. |
 | `design/` | Shared Design System and product-owned design sources. |
-| `engineering/` | Versioned Engineering System, quality contracts, operations, and evidence. |
+| `engineering/` | Versioned Engineering System, technical entity graph, standards, quality contracts, operations, and evidence. |
 | `audits/` | Readiness, consistency, QA, security, and release findings. |
 | `releases/` | Product release records when materialized. |
 
@@ -553,7 +565,7 @@ Definition and planning skills follow the shared Discovery and Challenge contrac
 | --- | --- |
 | Foundation | Problem Discovery, Vision, Strategy, Domain Architect, and User Goal define evidenced product direction and boundaries. |
 | Product Design | Journey, Feature, Use Case, UX/UI, UX Review, and Design System define value slices and verifiable experience. |
-| Specification and planning | Specification, Engineering System, Technical Discovery, Engineering Proposal, Engineering Review, Implementation Planner, Execution Graph, and Task Generator turn approved intent into executable contracts. |
+| Specification and planning | Specification, Engineering Orchestrator, Technical Landscape, Engineering Standards, Operations Baseline, Engineering Evidence, Engineering System, Technical Discovery, Engineering Proposal, Engineering Review, Implementation Planner, Execution Graph, and Task Generator turn approved intent into executable contracts. |
 | Engineering and validation | Code Runner implements one approved task; QA, Code Review, and Security Review independently verify it; Threat Modeler maintains proactive security context; Commit Crafter and PR Finalizer prepare verified delivery without merging. |
 | Audit and evolution | Gap, Conflict, Dependency, Impact, Evolution, Documentation, and Product Historian skills inspect health and route governed change. |
 
@@ -567,6 +579,7 @@ Orchestrators do not create primary artifacts. They control flow, order, gates,
 | --- | --- |
 | Framework Guide | Translates intent and current CLI state into the smallest safe route; it does not author artifacts or approve work. |
 | Product | Coordinates the approved Foundation sequence and stops at each human gate. |
+| Engineering | Routes the shared technical landscape, standards, operations, evidence, aggregate Engineering System, and human approval gate without authoring specialist contracts. |
 | Domain Evolution | Compares evidenced feature candidates and requires explicit human selection before handoff. |
 | Existing Product Import | Moves sources through inventory, per-source traceability, conflicts, reviewed mappings, explicit materialization, and draft artifacts without treating sources as truth. |
 | New Feature | Drives an approved feature through Use Cases, Specification, Design, engineering gates, Plan, Graph, and Tasks. |

README.md

@@ -75,10 +75,10 @@ spec-framework uninstall --purge --yes
 | --- | --- |
 | **Specification** | The central contract: flow, UI, APIs, data, permissions, analytics, security, and acceptance — written before any code. |
 | **Design flow** | Specification → `design.md` (origin `generate`/`evolve`/`adopt`, versioned visual sources) → independent UX Review → human gate. |
-| **Engineering flow** | Technical Discovery → Engineering Proposal → independent Engineering Review → Implementation Plan. |
+| **Engineering flow** | Shared baseline: Engineering Orchestrator → Technical Landscape → Standards + Operations → Evidence → Engineering System approval. It runs sequentially by default or through bounded minimal-context native subagents. Delivery: Technical Discovery → Engineering Proposal → independent Engineering Review → Implementation Plan. |
 | **Execution Graph** | Complete vertical task contracts as a DAG with explicit `writeScope`; parallel work never overlaps write paths. |
 | **Approval gates** | `draft → proposed → approved → in_progress → implemented → validated → released`, each transition mechanically checked (content hashes, same-diff QA + Code Review, staleness detection). |
-| **Shared systems** | Optional versioned Design System (`design/system/`) and Engineering System (`engineering/`) — pinned per delivery, never self-approving. |
+| **Shared systems** | Optional versioned Design System (`design/system/`) and scalable Engineering System (`engineering/`) whose graph, standards, operations, evidence, aggregate, and quality contracts have explicit specialist owners — pinned per delivery, never self-approving. |
 
 ## CLI At a Glance
 

assets.go

@@ -6,5 +6,5 @@ import "embed"
 // Init composes product-owned starter assets through versioned contracts; method
 // assets are materialized in the user cache so the released CLI works offline.
 //
-//go:embed FRAMEWORK.md all:starter all:examples/events docs/artifact-registry-modules.md docs/execution-runtime.md docs/engineering-systems.md docs/lifecycle-and-approvals.md framework/AGENTS.framework.md framework/delivery-closure.md framework/extensions framework/init framework/skills
+//go:embed FRAMEWORK.md all:starter all:examples/events docs/artifact-registry-modules.md docs/execution-runtime.md docs/engineering-systems.md docs/engineering-catalog-and-standards.md docs/lifecycle-and-approvals.md framework/AGENTS.framework.md framework/delivery-closure.md framework/extensions framework/init framework/skills
 var Assets embed.FS

docs/artifact-registry-modules.md

@@ -25,7 +25,7 @@ This document is the canonical maintenance map for composing the initial artifac
 | `foundation-strategy` | Strategy | O starting point preserva apenas estratégia |
 | `delivery-domain` | Domain, Goal, Feature, Use Case | O produto está pronto para modelar entrega |
 | `delivery-design` | Design System, Design, componentes, padrões | O produto possui interface ou sistema visual |
-| `delivery-engineering` | Engineering System, Quality System, Engineering Proposal, Review | O produto precisa de contratos técnicos compartilhados |
+| `delivery-engineering` | Engineering System aggregate, technical landscape, standards, operations, evidence, Quality System, Engineering Proposal, Review | O produto precisa de contratos técnicos compartilhados |
 | `delivery-validation` | Tests, QA Evidence, Security Review, Audit | A entrega avançou para validação |
 | `delivery-execution` | Execution Graph, Task Set, Task | A especificação está pronta para implementação |
 | `governance` | Decisions, approvals, releases, audits | Sempre que houver governança aplicável |
@@ -40,7 +40,7 @@ The approval engine remains generic. Adapters are only for side effects or compo
 | --- | --- |
 | `generic` | Update document, registry, and approval record |
 | `foundation-context` | Synchronize the canonical document status with its `context.md` |
-| `engineering-system` | Synchronize context, YAML, Quality System, and composite hash |
+| `engineering-system` | Synchronize aggregate context, YAML, specialist contract references, Quality System, and composite hash |
 | `design-system` | Validate tokens/catalog when applicable |
 | `feature-brief` | Validate `targetFeature` and the selected feature |
 

docs/engineering-catalog-and-standards.md

@@ -0,0 +1,164 @@
+# Engineering Catalog And Standards
+
+## Purpose
+
+This contract defines how `engineering/` grows from a product baseline into a
+multi-system, multi-application, and multi-repository technical knowledge graph.
+It also records the implementation plan for adopting that model across the
+framework.
+
+The Engineering System must not assume that one product equals one repository
+or one deployable application. Repositories, systems, applications, components,
+interfaces, data stores, and deployments are independent entities connected by
+stable identifiers.
+
+Ownership is deliberately split. `technical-landscape` owns the graph,
+`engineering-standards` owns rules and profiles, `operations-baseline` owns
+operational contracts, `engineering-evidence` owns evidence and maturity, and
+`engineering-system` owns only the versioned aggregate and Quality System.
+`engineering-orchestrator` sequences these owners and stops at human approval.
+The aggregate `engineering-system.yaml` declares `owner_skill` for every area,
+and specialist root catalogs repeat their owner. Missing owner metadata remains
+valid for legacy adopters; once declared, mismatched ownership is a blocker.
+
+## Canonical Structure
+
+```text
+engineering/
+├── context.md
+├── engineering-system.md
+├── engineering-system.yaml
+├── architecture/
+│   ├── system-context.md
+│   ├── modules.md
+│   └── topology.yaml
+├── catalog/
+│   ├── catalog.yaml
+│   ├── systems/
+│   ├── applications/
+│   ├── components/
+│   ├── repositories/
+│   ├── data-stores/
+│   ├── interfaces/
+│   └── deployments/
+├── standards/
+│   ├── standards.yaml
+│   ├── profiles/
+│   ├── catalog/
+│   └── exceptions/
+├── quality/
+├── operations/
+│   ├── operations.yaml
+│   ├── environments/
+│   ├── deployments/
+│   └── runbooks/
+├── evidence/
+│   └── inventory.md
+└── decisions/
+```
+
+Only the root catalogs and README contracts are initialized. Entity records,
+profiles, standards, exceptions, environments, and runbooks are materialized
+on demand from evidence or explicit hypotheses; empty placeholder forests are
+not required.
+
+## Entity Graph
+
+| Entity | Responsibility |
+| --- | --- |
+| System | Technical capability composed from one or more applications or components. |
+| Application | Executable or user-facing unit delivered as a whole. |
+| Component | Service, module, package, worker, frontend, or reusable library. |
+| Repository | Physical source-control boundary containing one or more components. |
+| Interface | API, event, queue, file, webhook, or other cross-component contract. |
+| Data store | Database, cache, bucket, index, or other persistent source. |
+| Deployment | Mapping from components and artifacts to an environment and release strategy. |
+
+Relations live in mechanical catalogs and use stable IDs. Folder position is
+for navigation and never determines ownership or containment by itself. This
+supports monorepos, polyrepos, shared components, multiple deployables per
+repository, and applications assembled from several repositories.
+
+Each relation declares a stable `REL-*` ID, an extensible relation `type`, and
+existing `source` and `target` entity IDs. Evidence may be attached when the
+relation is observed rather than hypothetical. The framework validates graph
+integrity without imposing a closed relation vocabulary.
+
+## Contract Inheritance
+
+```text
+Engineering System
+→ System
+→ Application
+→ Component
+→ delivery-specific Engineering Proposal
+```
+
+A more specific contract may add constraints. It may not silently weaken or
+replace an inherited contract. A divergence requires a governed exception,
+deviation, or approved `DEC-*` record.
+
+## Standards System
+
+`engineering/standards/` is a versioned catalog of verifiable technical
+rules. Standards are independent entities grouped into profiles and selected
+by entity type, capability, or explicit assignment.
+
+Canonical categories are architecture, code, API, events, data, dependencies,
+security, observability, testing, and delivery. A standard declares:
+
+- stable ID, semantic version, status, category, and obligation level;
+- applicable entity types and capabilities;
+- individually identifiable rules;
+- verification methods and required evidence;
+- exception policy and compatibility notes.
+
+Obligation levels are `required`, `recommended`, `experimental`, and
+`deprecated`. Required standards block a governed gate unless conformity or
+an open, approved, unexpired, in-scope `STDEX-*` exception is recorded.
+
+Profiles compose standards for common shapes such as web applications, HTTP
+APIs, workers, event consumers, shared libraries, and product defaults.
+Consumers pin profile and standard versions. Profiles may extend other
+profiles, but cycles are invalid.
+
+Standards define technical rules. The Quality System defines quality policy and
+coverage. The security baseline defines threats, trust, and governed controls.
+Standards reference these contracts rather than duplicating them.
+
+## Evidence And Maturity
+
+Every maturity above `baseline` requires resolvable evidence. Evidence may
+reference repository paths, tests, CI, commands, runtime observations, or
+approved external sources. `engineering/evidence/inventory.md` indexes the
+evidence used by catalogs without copying volatile output into contracts.
+
+The Engineering System composite approval hash covers every file under
+`engineering/`. Adding or changing a catalog, profile, standard, exception,
+entity, operation, or evidence contract makes existing approval stale.
+
+## Compatibility And Migration
+
+The model is additive. Existing adopters with only `engineering-system.md`,
+`engineering-system.yaml`, architecture, and quality remain valid. Upgrade
+must not create or overwrite adopter-owned entity records. New starter
+repositories receive empty root catalogs; existing products opt into them by a
+previewable migration or normal skill-driven evolution followed by approval.
+
+## Skill Flow
+
+```text
+engineering-orchestrator
+→ technical-landscape
+→ engineering-standards
+→ operations-baseline
+→ engineering-evidence
+→ engineering-system aggregation and validation
+→ engineering-orchestrator readiness review
+→ human approval
+→ domain-architect or technical-discovery
+```
+
+The orchestrator may revisit only affected specialists during evolution, but it
+must revalidate downstream contracts and the final composite hash before asking
+for approval.