forked from diegoecab/oci-deal-accelerator
Extractor: drawio → absolute_layout YAML scaffold (107/132 cached)
Closes the procedural hole that kept making Codex sessions fall back
to ``examples/`` for YAML scaffolding even after the SKILL forbade it.
The lookup tool returns a canonical Oracle ``.drawio`` as the geometry
source, but the agent had no YAML version of that geometry to copy —
the .drawio is XML with stencil-encoded icons. Without a scaffold,
agents reverse-engineered or fell back to ``examples/`` (which is
forbidden but happened anyway because the alternative was painful).
New tool ``tools/archcenter_drawio_to_template.py`` extracts:
• canvas dimensions
• containers (region / vcn / ad / subnet) classified by stroke /
fill style markers
• service bounding boxes with ``type: TODO_identify`` (the icon
type is encoded in stencil bytes — agent fills it from the
renderer's TYPE_TO_ICON aliases when authoring the spec)
• edge waypoints (source, target, points)
Output lands at ``kb/diagram/assets/archcenter-refs/<slug>/_template.yaml``
next to the .drawio. Lookup now surfaces it as
``cached: yaml=<path>`` so the agent has a one-step "copy this YAML
and adapt" path.
Ran across all 132 cached folders: 107 templates emitted, 24 had no
.drawio (zip didn't ship one), 1 already cached.
Other persistent guardrails added in this commit:
- SKILL.md option 2 step 3: explicit reminder that valid ``type:``
values come from ``TYPE_TO_ICON`` / ``ICON_TYPE_ALIASES`` in the
renderer source plus the icon-index JSON files. Do NOT grep
``examples/`` for ``type:`` — that's where the previous Codex
session was looking, against the rule.
- ``make archcenter-templates-refresh`` Makefile target.
- The lookup index now also indexes ``_template.yaml`` per slug.
- Auto-extracted templates committed under
``kb/diagram/assets/archcenter-refs/*/_template.yaml`` so a fresh
clone has them on first lookup (no extraction step needed).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
12
SKILL.md
12
SKILL.md
@@ -131,12 +131,14 @@ Pick a number, or just describe what you need.
|
||||
```
|
||||
|
||||
After the user answers, **follow these steps in order — do NOT skip step 1**:
|
||||
1. **Reference-architecture lookup.** Run `python tools/archcenter_pattern_lookup.py "<topology keywords>"` against `kb/architecture-center/catalog.yaml` (123 Oracle-curated entries with cached `.drawio` / `_description.md` under `kb/diagram/assets/archcenter-refs/`). Pick the highest-scoring entry whose topology matches.
|
||||
- **The cached `.drawio` is your GEOMETRY source** — it carries Oracle's canonical container nesting, padding, AD/subnet placement, and icon choices. Open it (drawio desktop, drawio.exe, or read the XML) to extract the layout you'll mirror.
|
||||
- **`examples/` is allowed ONLY as a YAML scaffold reference** — i.e. as a starting `absolute_layout:` skeleton to copy the *spec shape* from (which fields exist, how connections are written, fontSize unit). Do NOT copy *geometry numbers* from `examples/`; those came from a different topology and will produce a worse layout than the canonical Oracle ref. Geometry must come from the cached `.drawio` (or be invented based on it).
|
||||
- Rule of thumb: if you find yourself copying `(x, y, w, h)` numbers from `examples/`, stop — you should be copying them from (or fitting them to) the cached `.drawio`. `examples/` is a YAML schema reference, not a geometry source.
|
||||
1. **Reference-architecture lookup.** Run `python tools/archcenter_pattern_lookup.py "<topology keywords>"` against `kb/architecture-center/catalog.yaml` (123 Oracle-curated entries with cached `.drawio` / `_description.md` / `_template.yaml` under `kb/diagram/assets/archcenter-refs/`). Pick the highest-scoring entry whose topology matches.
|
||||
- **The cached `_template.yaml` is your YAML SCAFFOLD** — auto-extracted from the canonical `.drawio` by `tools/archcenter_drawio_to_template.py`. It carries Oracle's container geometry (region/vcn/ad/subnet bboxes), service positions, and edge waypoints in the `absolute_layout:` shape your spec uses. Copy it as the starting point, rename ids, fill in `type:` for services (the extractor leaves `type: TODO_identify` because the canonical icon TYPE is encoded in stencil bytes — pick the right alias from the renderer's TYPE_TO_ICON), and adapt to the customer's components. Lookup result surfaces it as `cached: yaml=<path>`.
|
||||
- **The cached `.drawio` is the visual source of truth** if the template extractor missed something — open it (drawio.exe, the SVG companion, or the XML) for the canonical look.
|
||||
- **Do NOT use `examples/` as a geometry source.** `examples/` is previous user output, not authoritative. The `_template.yaml` covers everything `examples/` was being abused for.
|
||||
2. **Pre-generation review.** Confirm the component list with the user (REQUESTED + TECHNICAL DEPENDENCIES per the whitelist).
|
||||
3. **Author the spec in `absolute_layout` shape** — this is REQUIRED. Do NOT use the legacy workload-driven shape (`tenancy → regions → compartments → services`); it does not resolve OCI icon stencils, does not run through the spec validator, and produces wireframe-looking output (rectangles with text instead of real OCI icons). Every container, service, label, and connection needs explicit `(x, y, w, h)`.
|
||||
|
||||
**Where to look up valid `type:` values for services:** the authoritative sources are (1) `TYPE_TO_ICON` in `tools/oci_pptx_diagram_gen.py` (PPTX path) and `ICON_TYPE_ALIASES` in `tools/oci_diagram_gen.py` (drawio path), and (2) the slug keys in `kb/diagram/oci-icons.json` (drawio) and `kb/diagram/oci-pptx-icons-index.json` (PPTX). Do NOT grep `examples/` for `type:` patterns to discover valid slugs — `examples/` are previous user outputs that may use stale or non-canonical slugs. Both renderer files and both index files are exhaustive and current.
|
||||
4. **Spec validator runs automatically** before either renderer (`tools/diagram_spec_validator.py`). It runs ONLY on `absolute_layout` specs — that's another reason workload-driven is forbidden. Fix any errors before re-rendering.
|
||||
5. **Render.** `oci_diagram_gen.py` for drawio, `oci_deck_gen.py` for PPTX.
|
||||
6. **Visually verify.** `tools/oci_pptx_render.py` to rasterize, then read the PNG.
|
||||
@@ -568,4 +570,6 @@ KB lives under `kb/`. See [kb/README.md](kb/README.md) for the directory map, fr
|
||||
- You do NOT claim features exist if you're unsure. Check the KB first.
|
||||
- You do NOT do detailed project management. DELIVER artifacts are lightweight handover aids.
|
||||
- You do NOT add services or components the user did not request.
|
||||
- **The skill ships as an MCP server.** This repo is packaged and served via the hosted MCP at `https://mcp.tech-lad.com/deal-accelerator/mcp/`. Anything you change in the skill's runtime — `tools/`, `scripts/`, `kb/`, `SKILL.md`, `AGENTS.md`, `.agents/` — must keep working in that deployed environment, not just on the SA's laptop. Concrete implications: (1) NO machine-specific paths (use `pathlib.Path(__file__).resolve().parent.parent` or env vars, never hardcoded `/mnt/c/...` or `/home/diego/...`); (2) NO required network calls during normal operation (the MCP container won't have access to drawio.exe, paid APIs, or Diego's local files — opt-in via env vars like `DRAWIO_EXE` / `ANTHROPIC_API_KEY`, never required); (3) NO writes outside the repo tree (the MCP filesystem is the cloned repo, write only under `examples/`, `tmp/`, or the artifacts the skill is meant to produce); (4) NO new dependencies that aren't in `requirements.txt` (CI installs from there, the MCP container too); (5) any new tool must work in a fresh clone with `make venv` — no manual setup steps. Before adding a feature that depends on a binary, an external service, or a privileged operation, ask whether it'll work when the SA is hitting the MCP endpoint with no laptop attached.
|
||||
|
||||
- **You do NOT edit skill source code or tooling when the user is in "menu mode".** When the user invoked the skill via the welcome menu (options 1–14) or asked for one of the menu outputs (proposal, diagram, deck, BOM, WA review, etc.), your job is to USE the existing tools, not modify them. Do NOT touch `tools/`, `scripts/`, `kb/diagram/*.json`, or any other code/index file as part of fulfilling a menu request — even if you discover a bug or a missing alias mid-task. If you hit a tool gap (missing icon alias, broken renderer, type that doesn't resolve), surface it as a follow-up at the end of your reply (e.g. "I noticed `refreshable_clone` doesn't have a PPTX icon alias — flag this for the maintainer to add to `tools/oci_pptx_diagram_gen.py::TYPE_TO_ICON`") rather than silently patching it. Code edits happen in a separate "developer mode" engagement, not while the SA is generating customer artifacts. The two exceptions: (1) `kb/field-findings/tracker.yaml` via menu option 11 (the menu's purpose IS to write that file), and (2) writing the customer's spec/output YAML files under `examples/<customer>/` — those are the deliverable, not the skill itself.
|
||||
|
||||
Reference in New Issue
Block a user