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:46:50 +00:00
parent 221f31d824
commit fb20521880
14 changed files with 258 additions and 172 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
docs/agent-specification.md
View File

@@ -1,24 +1,23 @@
# Application landing zone agent specification
# Application Landing Zone Agent specification
**Name:** `application_landing_zone_agent`
**Purpose:** Transform application requirements into a reviewable Technical Solution Design and an editable draw.io architecture diagram.
## Purpose
Transform structured application requirements into a provider-neutral Technical Solution Design (TSD) and an editable draw.io architecture diagram. The agent is deterministic, review-first, and does not invent provider-specific resources when the input is silent.
## Input contract
JSON object fields: required `application_name`, `business_context`, `environments` (non-empty array), `data_classification`, `availability_target`; optional array fields `components`, `integrations`, `constraints`.
JSON object: `application_name` (string), `business_objective` (string), and `environments` (non-empty string array) are required. Optional arrays are `requirements`, `constraints`, and `integrations`; optional strings are `data_classification`, `availability_target`, and `region`.
## Output contract
`generate()` returns `{tsd: string, drawio: string, manifest: object}`. The CLI writes `tsd.md`, `architecture.drawio`, and `manifest.json`.
The agent writes `tsd.md`, `architecture.drawio` (native mxGraph XML), and `manifest.json` to the requested output directory. It returns their paths plus in-memory content. The manifest identifies formats and artifact paths.
## Workflow
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.
## Processing workflow
1. Parse JSON and validate required fields and array types.
2. Normalize defaults for omitted governance fields.
3. Render a TSD covering summary, requirements, environments, security, reliability, delivery, and decisions.
4. Render an XML diagram with users, edge controls, application tier, data tier, and cross-cutting operations.
5. Persist artifacts and a machine-readable manifest.
## Diagram requirements
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 error handling
Reject missing required fields, non-list environment values, and arrays containing non-strings with `ValueError`; CLI reports an error and exits 2. XML must parse, the diagram must contain an `mxGraphModel`, and the TSD must contain security and reliability sections. Ambiguous architecture decisions are recorded as decisions required, not silently resolved.
## Validation and errors
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.
## Conventions discovered
The implementation uses a `src/` package layout, `pyproject.toml` configuration, a thin public agent class, a CLI entry point, Markdown documentation, pytest tests, and native draw.io XML. These conventions are recorded here because the source template/target URLs were not provided in the request; the repository remains self-contained and provider-neutral.

10
docs/repository-conventions.md
View File

@@ -1,11 +1,3 @@
# Repository conventions and discovery record
## Discovery scope
The requested template and target repository URLs were not supplied to the build request. This repository therefore uses the standard Python agent landing-zone convention: `src/` package layout, `pyproject.toml`, JSON configuration, a callable package API, CLI wrapper, tests, and human-readable docs.
## Extracted conventions applied
- Keep runtime code under `src/<package>` and tests under `tests`.
- Expose a small programmatic interface and a CLI entry point.
- Keep configuration declarative and secret-free.
- Produce deterministic, reviewable artifacts in a caller-selected output directory.
- Document contracts, assumptions, validation, and diagram editing expectations.
The requested template and target repository URLs were not included, so discovery could not inspect external source trees. This project follows the expected single-agent conventions: `src/<package>` implementation, `tests/` pytest coverage, `docs/` contract/prompt material, `examples/` runnable input, `pyproject.toml` packaging, and a CLI entry point. Configuration is declarative in `pyproject.toml`; interfaces are typed dataclasses plus a public `ApplicationLandingZoneAgent.generate` method. Diagram output is editable draw.io mxGraph XML rather than an image.

3
docs/system-prompt.md Normal file
View File

@@ -0,0 +1,3 @@
# System prompt
You are the Application Landing Zone Agent. Convert the user's application requirements into a reviewable Technical Solution Design and an editable draw.io architecture diagram. Validate the required fields before generation. Preserve stated constraints and integrations. Use provider-neutral architecture language unless a provider is explicitly named. Always cover environment isolation, network boundaries, identity, secrets, logging, monitoring, encryption, backup/recovery, deployment, cost, and unresolved decisions. Never claim a compliance certification or invent capacity numbers. Produce `tsd.md`, `architecture.drawio`, and `manifest.json`; ensure the diagram is native mxGraph XML and all user-provided labels are XML-escaped. If information is missing, state an assumption or decision required. Return concise artifact paths and validation status.

12
docs/validation-report.md
View File

@@ -1,11 +1,3 @@
# Validation plan and report
# Validation report
The repository validation covers:
- Unit tests for required-field/type validation, TSD sections, and draw.io XML markers.
- CLI packaging smoke test that writes all three expected files.
- Human review checklist for assumptions, security controls, environment isolation, and editable diagram structure.
Run `python -m unittest discover -s tests -v` and `python -m landing_zone_agent.cli --requirements examples/requirements.json --output-dir /tmp/landing-zone-agent-check`.
The generated baseline is provider-neutral by design; provider-specific landing-zone controls require confirmation of cloud, identity, network, RTO/RPO, retention, and sizing.
Validation is performed by `pytest` and by the checks in `tests/test_agent.py`: required-field rejection, TSD section presence, manifest JSON shape, XML parsing, and `mxGraphModel` presence. The CLI is packaged through the `application-landing-zone-agent` script and can be smoke-tested with the example input.