Skip to content

refactor(artifacts): decouple artifact storage via repository pattern#346

Open
JWThewes wants to merge 1 commit into
awslabs:v2_backupfrom
JWThewes:repository-pattern
Open

refactor(artifacts): decouple artifact storage via repository pattern#346
JWThewes wants to merge 1 commit into
awslabs:v2_backupfrom
JWThewes:repository-pattern

Conversation

@JWThewes

@JWThewes JWThewes commented Jun 9, 2026

Copy link
Copy Markdown

WHY
The v2 framework hardcodes "markdown files in a directory tree" across skills, schemas, and every stage definition. Swapping the storage backend (e.g. to a graph database) would mean editing dozens of files. We want storage to be a single, swappable concern — change one adapter, not the methodology.

HOW
Introduce a port/adapter (repository) pattern:

  • Port (conventions/repository-interface.md): a stable, backend-neutral contract. Artifacts are addressed by a logical TYPE token (e.g. requirements, components) — never a filename, extension, or path — plus a small set of named operations (saveArtifact, readArtifact, copyForwardArtifact, registerOutput, appendAuditEntry, verifyStage, ...).
  • Adapter (src/repository//): the ONLY place that knows where and how artifacts are physically stored. Ships with the markdown-fs backend (adapter + paired verifier). A new backend = one adapter file + one verifier; nothing else changes.

Operations are a vocabulary of responsibilities, not an API. The adapter states the mechanism the agent uses to perform them: ordinary file tools for markdown-fs, or specific tools / an MCP server for other backends (e.g. a graph DB). The agent always reads the adapter to learn which.

WHAT

  • Add port repository-interface.md (address model, type catalog, ops).
  • Add repository/markdown-fs/ adapter (absorbs the old folder-structure.md
    • a type->representation map) and verifier.js (from process-checker.js, now resolving the new type/address state format).
  • Add repository/README.md backend-authoring guide.
  • Schemas: state outputs use {type, address} instead of {name, locationRelativeToIntentRoot}; reword workflow phase.
  • Rewrite skills (work-method, stage-execution, orchestration, kickoff, workflow-composition) to speak the port vocabulary; remove "to disk" / "file system" / org-ai-kb leakage from backend-neutral steering.
  • Strip extensions to type tokens across all 13 stage definitions and stage-graph.md.
  • build.js: BACKEND selector wires the active adapter -> conventions/ and verifier -> tools/process-checker.js (Kiro hook path unchanged).
  • Remove src/conventions/folder-structure.md and src/tools/process-checker.js (superseded by the adapter + paired verifier).

Methodology unchanged: stages, personas, state machine, autonomy, and review loops are untouched — only the storage vocabulary they speak through.

Summary

replace with your summary...

Changes

replace with a description of the changes

User experience

Please share what the user experience looks like before and after this change

Checklist

If your change doesn't seem to apply, please leave them unchecked.

  • I have reviewed the contributing guidelines
  • I have performed a self-review of this change
  • Changes have been tested
  • Changes are documented

Test Plan

replace with instructions or a checklist for reviewers to verify

Acknowledgment

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.

@JWThewes JWThewes force-pushed the repository-pattern branch from fc3e2cf to 30cf518 Compare June 9, 2026 13:54
WHY
The v2 framework hardcodes "markdown files in a directory tree" across
skills, schemas, and every stage definition. Swapping the storage backend
(e.g. to a graph database) would mean editing dozens of files. We want
storage to be a single, swappable concern — change one adapter, not the
methodology.

HOW
Introduce a port/adapter (repository) pattern:

  - Port (conventions/repository-interface.md): a stable, backend-neutral
    contract. Artifacts are addressed by a logical TYPE token (e.g.
    `requirements`, `components`) — never a filename, extension, or path —
    plus a small set of named operations (saveArtifact, readArtifact,
    copyForwardArtifact, registerOutput, appendAuditEntry, verifyStage, ...).
  - Adapter (src/repository/<backend>/): the ONLY place that knows where and
    how artifacts are physically stored. Ships with the `markdown-fs`
    backend (adapter + paired verifier). A new backend = one adapter file +
    one verifier; nothing else changes.

Operations are a vocabulary of responsibilities, not an API. The adapter
states the mechanism the agent uses to perform them: ordinary file tools for
markdown-fs, or specific tools / an MCP server for other backends (e.g. a
graph DB). The agent always reads the adapter to learn which.

WHAT
  - Add port `repository-interface.md` (address model, type catalog, ops).
  - Add `repository/markdown-fs/` adapter (absorbs the old folder-structure.md
    + a type->representation map) and `verifier.js` (from process-checker.js,
    now resolving the new type/address state format).
  - Add `repository/README.md` backend-authoring guide.
  - Schemas: state outputs use {type, address} instead of {name,
    locationRelativeToIntentRoot}; reword workflow `phase`.
  - Rewrite skills (work-method, stage-execution, orchestration, kickoff,
    workflow-composition) to speak the port vocabulary; remove "to disk" /
    "file system" / `org-ai-kb` leakage from backend-neutral steering.
  - Strip extensions to type tokens across all 13 stage definitions and
    stage-graph.md.
  - build.js: BACKEND selector wires the active adapter -> conventions/ and
    verifier -> tools/process-checker.js (Kiro hook path unchanged).
  - Remove src/conventions/folder-structure.md and src/tools/process-checker.js
    (superseded by the adapter + paired verifier).

Methodology unchanged: stages, personas, state machine, autonomy, and review
loops are untouched — only the storage vocabulary they speak through.
@JWThewes JWThewes force-pushed the repository-pattern branch from 30cf518 to ee2cef1 Compare June 10, 2026 11:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant