agents/crucible-agent-build-phase-2
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

decomposer: generate deliverable files for Inspect the single_agent template and target repository conventions to identify the required project structure, configuration, interfaces, and implementation patterns for the application landing zone agent.; Define the application landing zone agent's behavior, input and output contracts, document-generation workflow, and architecture-diagram requirements using the extracted template conventions.; Validate the implemented application_landing_zone_agent by running repository tests and checking the TSD document generation, draw.io diagram generation, agent packaging, configuration, and committed implementation against the defined contracts.; Commit and push the validated application_landing_zone_agent implementation to the target repository.

Browse Source
This commit is contained in:
demo-bot
2026-08-31 14:45:15 +00:00
parent 576c4050be
commit 0060bdd426
14 changed files with 226 additions and 85 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
docs/agent-specification.md
View File

@@ -1,38 +1,24 @@
# Application landing zone agent specification
## Purpose
**Name:** `application_landing_zone_agent`
Transform application requirements into a reviewable Technical Solution Design and an editable draw.io architecture diagram. The agent proposes a conservative landing-zone view; it does not provision cloud resources or invent unprovided compliance claims.
**Purpose:** Transform application requirements into a reviewable Technical Solution Design and an editable draw.io architecture diagram.
## Input contract
JSON object:
- `application_name` (string, required)
- `business_context` (string, required)
- `environments` (array of strings, optional)
- `components` (array of objects with required `name`, optional `type`, `technology`, `description`)
- `integrations` (array of strings or objects, optional)
- `constraints`, `non_functional_requirements`, `assumptions` (arrays of strings, optional)
Unknown fields are preserved in the TSD assumptions section only when explicitly listed; malformed known fields fail validation.
JSON object fields: required `application_name`, `business_context`, `environments` (non-empty array), `data_classification`, `availability_target`; optional array fields `components`, `integrations`, `constraints`.
## Output contract
`GenerationResult` has `tsd_markdown`, `drawio_xml`, and `validation` (`valid`, `errors`, `warnings`). The CLI writes the configured filenames and a `validation.json` report.
`generate()` returns `{tsd: string, drawio: string, manifest: object}`. The CLI writes `tsd.md`, `architecture.drawio`, and `manifest.json`.
## Workflow
1. Validate and normalize requirements without making network calls.
2. Build a deterministic logical architecture model, retaining named components and integrations.
3. Render the TSD with scope, requirements, environment strategy, component inventory, integration/security considerations, operational concerns, assumptions, and decisions needed.
4. Render native draw.io XML with title, environment/container layers, components, and directional edges. IDs are stable (`component-<index>`, `integration-<index>`).
5. Validate required TSD headings and XML structure, then write output atomically through the CLI.
1. Parse and validate the requirements.
2. Apply safe baseline assumptions and identify unresolved decisions.
3. Generate TSD sections for context, scope, architecture, environments, security, resilience, operations, constraints, and acceptance criteria.
4. Generate an XML draw.io file with users, application boundary, components, and orthogonal relationships.
5. Validate artifact structure and return the manifest.
## Diagram requirements
The diagram must open in draw.io/diagrams.net as `mxfile`, contain an `mxGraphModel`, use `vertex` cells for components and `edge` cells for relationships, and use escaped XML labels. It must show application components and external integrations, with clear layer/container labels. It may not contain executable code or credentials.
The diagram must be importable by draw.io, use an `<mxfile>` root and `<mxGraphModel>`, include vertex cells for the users, application, and components, and include relationships. It must remain editable XML rather than an image.
## Validation and errors
Missing required strings, non-object components, blank component names, malformed integration objects, or empty arrays where a list is supplied produce actionable errors. The CLI prints the error and exits 2. Rendering failures exit 1. The library never silently drops a named component.
Missing required fields, malformed types, and empty environments raise `ValueError` with actionable field names. A diagram contract failure raises `RuntimeError`. No credentials are inferred or emitted.