Setting the file. One moment.
Subchapter 23.45
references/phases/poc/poc-report.mdMarkdown13 KBView on GitHub
Loaded by poc.md Step 4.5 after the POC files are written (Step 3) — for BOTH modes. Produces
$RUN_DIR/poc/poc-report.htmland opens it in the browser. Non-blocking: if generation fails, log a warning and continue; the files themselves are the deliverable.
A single self-contained HTML file summarizing the POC: what was generated, what changed from
the original app, how to deploy it, the deployment architecture, and what still needs
verifying. Uses the v3 document shell (same visual system as recommendation-report.html):
inline CSS from references/report-shell.md + SRI-pinned Mermaid — no other external
dependencies. The report sits in $RUN_DIR/poc/, so artifact download links are relative to
that dir.
Before writing the HTML: load the shared shell (references/report-shell.md) — inline
its CSS block and its SRI-pinned mermaid@10.9.3 script tag. The v3 shell defines
.help-strip, .doc-head, .timeline, .feat-grid, .callout, document tables, and all
other shared components. The help CTA is GATED on report-help-banner.md‘s banner_status:
it currently reads SUPPRESSED (support page not launched), so render NO help strip. Only when
it flips to LIVE do you substitute {{ HELP_URL }} with the single-source destination URL
from references/report-help-banner.md — never hardcode it here.
| Variable | Source |
|---|---|
POC_FILES | the files actually written under $RUN_DIR/poc/ (walk the dir; EXCLUDE __pycache__/, *.pyc, and the report itself) |
DEPLOYMENT_MODEL | confirm.json.deployment_model (primary unit; per-unit in UNITS[].deployment_model for a multi-unit POC) |
UNITS | design.json.units[] — one POC per unit; each carries id, effective_runtime, and model_recommendation (null for a model-less non-agent unit) |
MODEL_DISPLAY | resolved Bedrock model PER UNIT (Step 2 of poc.md) — null/omitted for a unit whose model_recommendation is null; never a single global model |
PLAN_BACKED | true if this POC came from a migration plan (3-F / 3-H plan-backed) |
CHANGES | when plan-backed: aws-design-ai.json.ai_architecture.code_migration.files_to_modify[].changes[] and before_after_example — the applied migration edits |
SOURCE_MODEL | when plan-backed: the source model replaced (from the plan) |
MODE | Mode A (deliverables) or Mode B (assisted build) from Gate 2b |
DEPLOY_STEPS | the staged steps from $RUN_DIR/plan.md |
DIAGRAM_MERMAID | compose a POC-deployment diagram (see Step P2) |
TODOS | every TODO: verify / deferred / drift note left in the generated files + plan.md |
LEDGER | Mode B only: $RUN_DIR/poc/created-resources.json (deployed resources) |
RUN_ID | from .phase-status.json |
For each file in POC_FILES, write a one-line purpose. Multi-unit layout: when
poc/<unit-id>/ directories exist, list files nested per unit. Single-unit layout
collapses flat (no unit subdirs). Infer from the filename/role:
app/app.py → “Migrated app (original UI/handler; local-dev only after migration)”app/core.py → “Shared LLM logic — used by both the UI and the entrypoint server”app/agentcore_app.py → “AgentCore Runtime entrypoint server (/invocations + /ping)”app/pyproject.toml / requirements.txt → “Dependencies (provider swap applied)”Dockerfile → “Container image for AgentCore Runtime”deploy.sh → “One-command deploy (creates real AWS resources)”README.md → “Runbook”harness.json → “Declarative Harness agent definition (the deploy artifact)”Compose a flowchart TD Mermaid block showing the POC’s RUNTIME shape (what actually runs
after deploy.sh), using the same topology discipline as build-diagram.md. Render one node per
unit in UNITS, each on ITS OWN effective_runtime, NOT hardcoded to AgentCore and NOT a single
global runtime/model — the POC now supports agentcore / ecs / eks / lambda / batch / fargate /
serverless_workers, and a MIXED or Temporal system has several units on different runtimes. For a
single-unit POC this collapses to one node.
MODEL_DISPLAY) only when THAT
unit’s model_recommendation is non-null. A model-less non-agent unit renders its runtime
node with NO Bedrock node or invoke edge — never attach the primary unit’s model to a secondary
unit’s runtime. User → runtime for agent/service units; a Temporal worker’s flow is Temporal
Server → worker. Every unit’s deployment is shown — a secondary unit is never omitted.confirm.json) — AgentCore
units only.<details> block, same as build-diagram.md.Use the v3 document shell (same structure as recommendation-report.html). The report follows this structure:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Deployable POC</title>
<!-- SRI-pinned mermaid@10.9.3 script tag — inline it VERBATIM from the shared shell
(references/report-shell.md), same tag/integrity hash. -->
{{ SHARED_SHELL_MERMAID_TAG from references/report-shell.md }}
The shell provides .doc-head, .help-strip, numbered h2/h3, document table, .feat-grid,
.timeline, .callout, and .doc-foot. POC-specific styles (.diff-before, .diff-after) are
added after the shared block. Dynamic numbering: sections shift by 1 when plan-backed (migration
changes is §2, pushing files/deploy/architecture/todos/resources down).
open "$RUN_DIR/poc/poc-report.html" # macOS
xdg-open "$RUN_DIR/poc/poc-report.html" # LinuxIf it fails (no GUI), print: POC report ready — open: file://$RUN_DIR/poc/poc-report.html
Return to poc.md. Do NOT update .phase-status.json — poc.md Step 6 handles phase state.