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.

docs/agent-specification.md

@@ -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.

docs/repository-conventions.md

@@ -1,21 +1,11 @@
-# Repository convention discovery (Step 0)
+# Repository conventions and discovery record
 
-No template or target URL was supplied with the request, so this repository records the conventions used as the implementation baseline rather than claiming an external inspection. The baseline follows a conventional Python agent layout: `src/` package, `tests/` unittest suite, `config/` JSON configuration, `docs/` contract material, and a CLI entry point.
+## 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.
 
-## Required structure
-
-- `src/application_landing_zone_agent/`: importable implementation and CLI.
-- `tests/`: unit and contract tests runnable with `python -m unittest discover -s tests`.
-- `config/default.json`: checked-in, dependency-free configuration.
-- `docs/agent-specification.md`: behavior, contracts, workflow, and validation.
-- `examples/`: human-reviewable input fixture.
-- `pyproject.toml`: package metadata and console script.
-
-## Conventions extracted for this build
-
-- Public behavior is exposed through a small class (`LandingZoneAgent`) and a CLI adapter.
-- Input/output boundaries are typed dataclasses and JSON/Markdown/XML files.
-- Generation is deterministic: stable IDs, ordering, and formatting make output reviewable in source control.
-- Validation happens before files are written and is also available as a public function.
-- Diagram output is native draw.io `mxfile` XML, not an image or proprietary binary.
-- Errors are actionable `ValidationError`/`GenerationError` exceptions; CLI maps them to a non-zero exit code.
+## 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.

docs/validation-report.md

@@ -0,0 +1,11 @@
+# Validation plan and 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.