@codebehind/agent-workflow 1.0.0

package/README.md

@@ -0,0 +1,94 @@
+# @codebehind/agent-workflow
+
+A scaffolding CLI that installs the **agent-workflow** spec-driven delivery framework into any repository.
+
+The framework gives AI agents (Claude Code) a structured way to work: write specs, plan implementations, verify acceptance criteria, and hand off via GitLab merge requests — all with human checkpoints where you want them.
+
+---
+
+## Quick start
+
+```bash
+npx @codebehind/agent-workflow init
+```
+
+Run this from the root of any repo (meta repo, monorepo, or single-purpose repo). It copies the full framework into place and prints next steps.
+
+Use `--force` to overwrite existing files:
+
+```bash
+npx @codebehind/agent-workflow init --force
+```
+
+---
+
+## What gets installed
+
+```
+.agent-workflow/
+  README.md                    ← workflow rules for agents
+  acceptance-verification.md   ← acceptance proof protocol
+  playwright-acceptance.md     ← UI verification guide
+  notion-spec-mapping.md       ← Notion → spec mapping rules
+  specs/_template.md           ← spec template
+  plans/                       ← agent-generated plans
+  docs/                        ← feature documentation
+  artifacts/                   ← acceptance proof artifacts
+
+.claude/
+  rules/agentic-workflow.md    ← Claude Code session rules
+  settings.json                ← permissions config
+  skills/
+    prepare-spec/SKILL.md      ← /prepare-spec skill
+    implement-spec/SKILL.md    ← /implement-spec skill
+    acceptance-proof/SKILL.md  ← /acceptance-proof skill
+    create-mr-summary/SKILL.md ← /create-mr-summary skill
+
+scripts/agent/                 ← GitLab helper scripts (glab-based)
+
+AGENTS.md                      ← agent onboarding instructions
+agents-workflow-dev-process.md ← human user manual
+agents-workflow-env-setup.md   ← one-time environment setup guide
+```
+
+---
+
+## Workflow overview
+
+| Phase | What happens | Skill |
+|-------|-------------|-------|
+| A — Prepare spec | Create or refine a spec (`draft`) | `/prepare-spec` |
+| B — Implement spec | Plan → code → docs for an `open` spec | `/implement-spec` |
+
+See `agents-workflow-dev-process.md` after init for the full Claude Code workflow.
+
+---
+
+## After init
+
+1. **Customize** `AGENTS.md` and `agents-workflow-dev-process.md` for your project context.
+2. **Add a `CLAUDE.md`** at the repo root with project-specific AI instructions (domain, architecture, conventions).
+3. **Make scripts executable**: `chmod +x scripts/agent/*.sh`
+4. **Install prerequisites**: `glab`, `jq`, `node >= 18` — see `agents-workflow-env-setup.md`.
+5. **Write your first spec**: copy `.agent-workflow/specs/_template.md` to `.agent-workflow/specs/my-feature.md`.
+
+---
+
+## Requirements
+
+- Node.js 18+
+- `glab` (GitLab CLI) for MR management
+- `jq`
+- Claude Code CLI
+
+---
+
+## Versioning
+
+This package follows semver. Breaking changes to the framework structure increment the major version. To upgrade an existing installation:
+
+```bash
+npx @codebehind/agent-workflow init --force
+```
+
+Review the diff carefully — files you've customized for your project will be overwritten.

package/bin/agent-workflow.mjs

@@ -0,0 +1,96 @@
+#!/usr/bin/env node
+import { existsSync, mkdirSync, copyFileSync, readdirSync, statSync } from 'fs';
+import { join, dirname, relative } from 'path';
+import { fileURLToPath } from 'url';
+
+const __dirname = dirname(fileURLToPath(import.meta.url));
+const TEMPLATES_DIR = join(__dirname, '..', 'templates');
+const VERSION = '1.0.0';
+
+const args = process.argv.slice(2);
+const command = args[0];
+const force = args.includes('--force');
+
+function printUsage() {
+  console.log(`
+@codebehind/agent-workflow v${VERSION}
+
+Usage:
+  npx @codebehind/agent-workflow init [--force]
+
+Commands:
+  init      Copy the agent-workflow framework files into the current directory.
+            Skips files that already exist (use --force to overwrite).
+
+Options:
+  --force   Overwrite existing files.
+  --version Print version and exit.
+`);
+}
+
+function walkDir(dir, baseDir, callback) {
+  for (const entry of readdirSync(dir)) {
+    const fullPath = join(dir, entry);
+    const relPath = relative(baseDir, fullPath);
+    if (statSync(fullPath).isDirectory()) {
+      walkDir(fullPath, baseDir, callback);
+    } else {
+      callback(fullPath, relPath);
+    }
+  }
+}
+
+function init(targetDir) {
+  const copied = [];
+  const skipped = [];
+
+  walkDir(TEMPLATES_DIR, TEMPLATES_DIR, (srcPath, relPath) => {
+    const destPath = join(targetDir, relPath);
+    const destDir = dirname(destPath);
+
+    if (!force && existsSync(destPath)) {
+      skipped.push(relPath);
+      return;
+    }
+
+    mkdirSync(destDir, { recursive: true });
+    copyFileSync(srcPath, destPath);
+    copied.push(relPath);
+  });
+
+  if (copied.length > 0) {
+    console.log('\nCopied:');
+    for (const f of copied) console.log(`  + ${f}`);
+  }
+
+  if (skipped.length > 0) {
+    console.log('\nSkipped (already exist — use --force to overwrite):');
+    for (const f of skipped) console.log(`  ~ ${f}`);
+  }
+
+  console.log(`
+Done. ${copied.length} file(s) copied, ${skipped.length} skipped.
+
+Next steps:
+  1. Customize AGENTS.md and agents-workflow-dev-process.md for your project.
+  2. Add a CLAUDE.md at the repo root with project-specific AI instructions.
+  3. If this is a meta repo with submodules, add them:
+       git submodule add <url> <folder>
+  4. Review .claude/settings.json and adjust permissions as needed.
+  5. Make agent scripts executable:
+       chmod +x scripts/agent/*.sh
+  6. See agents-workflow-env-setup.md for full setup instructions.
+`);
+}
+
+// Entry point
+if (command === '--version' || command === '-v') {
+  console.log(VERSION);
+  process.exit(0);
+} else if (!command || command === 'init') {
+  init(process.cwd());
+} else {
+  console.error(`Unknown command: ${command}`);
+  printUsage();
+  process.exit(1);
+}

package/package.json

@@ -0,0 +1,28 @@
+{
+  "name": "@codebehind/agent-workflow",
+  "version": "1.0.0",
+  "description": "Scaffold the agent-workflow spec-driven delivery framework into any repo",
+  "type": "module",
+  "bin": {
+    "agent-workflow": "bin/agent-workflow.mjs"
+  },
+  "files": [
+    "bin/",
+    "templates/"
+  ],
+  "engines": {
+    "node": ">=18"
+  },
+  "license": "MIT",
+  "keywords": [
+    "claude-code",
+    "ai-agent",
+    "workflow",
+    "scaffold",
+    "spec-driven"
+  ],
+  "repository": {
+    "type": "git",
+    "url": "git+https://gitlab.com/codebehind/agent-workflow.git"
+  }
+}

package/templates/.agent-workflow/README.md

@@ -0,0 +1,160 @@
+# Agent Workflow
+
+This folder contains the complete feature delivery workflow for both Users and Agents.
+
+## Target Structure
+
+```mermaid
+flowchart TD
+    User["User"] --> Specs[".agent-workflow/specs/"]
+    AgentPlan["Agent (Plan mode)"] --> Plans[".agent-workflow/plans/"]
+    AgentImpl["Agent (Agent mode)"] --> Docs[".agent-workflow/docs/"]
+    RootReadme[".agent-workflow/README.md"] --> User
+    RootReadme --> AgentPlan
+    RootReadme --> AgentImpl
+```
+
+## Spec status
+
+| Value | Meaning |
+|--------|--------|
+| `draft` | Spec file exists; **not** ready for implementation. User or agent is still authoring. |
+| `open` | Ready for Phase B: planning, implementation, docs. |
+| `done` | Delivered; agent sets this after the feature doc is written and work is complete. |
+
+Additional frontmatter fields:
+
+| Field | Default | Meaning |
+|-------|---------|---------|
+| `verification` | `true` | Human checkpoints during Phase B (`true` = plan/impl approval; `false` = autonomous). |
+| `acceptance_proof` | `true` | Acceptance verification capture after implementation (`true` = required; `false` = skip capture, post text-only confirmation instead — use only for pure config/infra specs with no visual or API surface). |
+
+**Rule:** Phase B (implementation) only targets specs with **`status: open`**. Ignore **`draft`** unless the user explicitly asked to edit the spec, not implement the feature.
+
+---
+
+## Phase A — Spec authorship
+
+How the spec file gets into `./specs/`:
+
+1. **1.1 User-written:** User copies `./specs/_template.md`, fills it in, sets `status` to `draft` or `open`, commits, and tells the agent when ready (local chat or Slack for Cloud Agents).
+2. **1.2 Chat-only drafting:** Agent uses **plan-style** interaction (outline, questions, suggestions) until the user agrees, then writes `./specs/{name}.md`, usually with **`status: draft`**.
+3. **1.3 From Notion:** Agent uses Notion MCP (`notion-fetch`), maps content using [`.agent-workflow/notion-spec-mapping.md`](notion-spec-mapping.md), asks questions, proposes a spec outline (**plan-style**) until the user agrees, then writes the spec file, usually **`status: draft`**.
+4. **1.4 Triggers:** User may paste a Notion URL or a free-text description (local or Slack — see repo root `agents-workflow-dev-process.md` for Slack patterns). **Prepare-spec** work belongs in a **dedicated Slack thread** (Thread A) separate from implementation (Thread B).
+5. **1.5 Agent output:** Spec is saved under `./specs/`; agent informs the user (chat or Slack) with the file path.
+6. **1.6 User review:** User edits the spec and/or sets **`status: open`** when development should start (or asks the agent to flip `draft` → `open`).
+
+Frontmatter for new specs: `verification: true|false` (default **`true`** if omitted in Phase B). Notion-sourced specs may include optional `notion_source` / `scope` — see `notion-spec-mapping.md`.
+
+---
+
+## Phase B — Delivery (implementation)
+
+1. **Agent reads the spec** with **`status: open`** and creates a plan in `./plans/` named `{spec-name}_plan.md`.
+2. **Agent checks verification mode** (default `verification: true` when missing):
+   - `verification: true`: standard checkpoints (plan approval + implementation approval).
+   - `verification: false`: continue autonomously after plan creation.
+3. **Agent implements** the feature.
+4. **Agent verifies acceptance criteria** — reads each `- [ ]` item from the spec, captures **runtime proof** (Playwright-first screenshots for UI, `curl` output for API) following [`.agent-workflow/acceptance-verification.md`](acceptance-verification.md) and [`.agent-workflow/playwright-acceptance.md`](playwright-acceptance.md), saves artifacts under `.agent-workflow/artifacts/`, and includes the acceptance checklist in the MR description. MR is **not** opened until all criteria pass (or blocked criteria are explicitly documented).
+5. **Agent writes/updates** the final feature document in `./docs/` using `./docs/_template.md`.
+6. **Agent marks the spec** `status: done`.
+
+```mermaid
+flowchart TD
+  subgraph authorship [Phase A Spec authorship]
+    U1[User or Agent creates spec]
+    U1 --> DraftFile["specs/*.md status draft"]
+    DraftFile --> UserReview[User review]
+    UserReview --> OpenSpec["status open"]
+  end
+  subgraph delivery [Phase B Delivery]
+    OpenSpec --> Plan["plans/"]
+    Plan --> Impl[Implementation]
+    Impl --> Verify["Verify acceptance criteria\n+ post proof to Slack"]
+    Verify --> Docs["docs/"]
+    Docs --> Done[status done + MR opened]
+  end
+```
+
+---
+
+## Feature Doc Selection Rule
+
+When writing final documentation, choose update/create in this order:
+
+1. If an existing feature doc already lists the spec under `Covered Specs`, update that doc.
+2. Else if one existing doc clearly matches the same bounded context (same page/domain/integration/data entities), update that doc.
+3. Else create a new feature doc from `./docs/_template.md`.
+4. Always add the spec under `Covered Specs` in the selected/new doc.
+
+---
+
+## Codebase Snapshot
+
+To reduce onboarding cost, use a reusable codebase snapshot file:
+
+- Path: `.agent-workflow/codebase.md`
+- If the file is missing, the first onboarded agent scans the codebase and creates it.
+- If the file exists, agents read it instead of rescanning the codebase.
+- Rescan and refresh this file only when the user explicitly asks.
+
+Expected snapshot structure (keep concise and high-level):
+
+1. Project Overview
+2. Backend Structure
+3. Frontend Structure
+4. Data/DB Layer
+5. API Surface Summary
+6. Feature Workflow Files
+7. Key Commands
+
+---
+
+## Ad-hoc Changes
+
+For non-trivial changes not described by a new feature spec:
+
+- Document the change in the relevant feature doc's **Change Log** in `./docs/`.
+- Agent and User should agree which feature document should be updated.
+- Trivial cosmetic tweaks (for example color and icon swaps) can skip documentation.
+
+---
+
+## Naming Rules
+
+- Specs: `./specs/{name}.md`
+- Plans: `./plans/{spec-name}_plan.md`
+- Feature docs: `./docs/{descriptive-feature-name}.md`
+
+---
+
+## Onboarding
+
+- **Users:** Add specs under `./specs/` using `_template.md`. Use **`draft`** until ready, then **`open`** for implementation. See `agents-workflow-dev-process.md` for the full Claude Code workflow (skill invocations, worktrees, MR flow). Set `verification: false` when you want autonomous execution without verification checkpoints in Phase B.
+- **Agents:**
+  1. Read this file first.
+  2. Check `.agent-workflow/codebase.md`.
+  3. If missing, create it by scanning the codebase once. If present, read it and continue.
+  4. If the task is **prepare spec** (Notion URL, chat drafting): follow Phase A; write **`draft`** unless the user says otherwise.
+  5. If the task is **implement feature**: read `verification` in each relevant spec with **`status: open`** (default `true` when missing).
+  6. Continue with `./specs/`, `./plans/`, and `./docs/` according to Phase B above.
+  7. **After implementation:** always run the acceptance verification step per [`.agent-workflow/acceptance-verification.md`](acceptance-verification.md) (unless `acceptance_proof: false` in the spec). For UI tasks, use the Playwright-first guidance in [`.agent-workflow/playwright-acceptance.md`](playwright-acceptance.md). Include proof in the MR description before opening it.
+
+---
+
+## Meta-repo specifics
+
+This is the project's meta repository. The `.agent-workflow/` directory exists **only here** — there are no per-submodule workflow directories.
+
+| Content | Location |
+|---------|---------|
+| Specs, plans, feature docs, artifacts | This repo under `.agent-workflow/` |
+| Backend application code | `backend/` submodule — commit and MR in project-backend |
+| Web application code | `web/` submodule — commit and MR in project-web |
+| Mobile application code | `mobile/` submodule — commit and MR in project-mobile |
+
+When implementing a spec that touches application code:
+1. Navigate into the relevant submodule directory to make code changes.
+2. Open a separate MR in that submodule's GitLab project.
+3. The meta repo MR covers only spec, plan, docs, and artifacts.
+4. Reference the submodule MR(s) in the meta repo MR description.

package/templates/.agent-workflow/acceptance-verification.md

@@ -0,0 +1,192 @@
+# Acceptance Verification Protocol
+
+This document defines how agents **verify acceptance criteria and report proof** at the end of Phase B, before opening an MR.
+
+---
+
+## Meta-repo note
+
+This is the project's meta repository. Application code lives in submodules (for example `backend/`, `web/`, `mobile/`). Acceptance proof that requires a running app (UI screenshots, API curl) must be executed **inside the relevant submodule directory**. Artifacts are then saved here under `.agent-workflow/artifacts/`.
+
+---
+
+## Core rule
+
+Acceptance proof must show **what ran**, **what was observed**, and **where the evidence lives**.
+
+Do not confuse these three ideas:
+
+- **Implemented** — code was written
+- **Verified automatically** — runtime checks actually ran
+- **Human QA** — reviewer or tester still checked behavior manually
+
+A statement such as “`onRowClick` was added” is implementation evidence, not acceptance evidence.
+
+---
+
+## When to run
+
+After implementation is complete, **before writing docs or opening the MR**, the agent must:
+
+1. Read every `- [ ]` item from the `### Acceptance Criteria` section of the spec.
+2. Check `acceptance_proof` in the spec's YAML frontmatter (default `true` when missing).
+   - `acceptance_proof: false` — skip capture and post a brief text-only confirmation instead.
+   - `acceptance_proof: true` (or missing) — full capture required.
+3. Create the artifact folder manually:
+
+   ```bash
+   mkdir -p .agent-workflow/artifacts/acceptance-<spec-slug>-<YYYYMMDD>
+   ```
+
+4. Classify each criterion (see below), capture proof, save artifacts, and prepare the MR handoff.
+
+---
+
+## Classifying each criterion
+
+| Criterion type | How to identify | Capture method |
+|----------------|----------------|----------------|
+| **UI / visual** | Involves a page, component, user interaction, tab, layout, or rendered output | **Playwright-first** browser run + screenshots (video/trace optional) |
+| **API / data** | Involves an HTTP endpoint, data shape, or server response | `curl` against the local server; terminal output or saved `.txt` |
+| **Config / infra** | Build flags, env vars, CI config, no runtime surface | Text confirmation + relevant log or build output |
+
+A single criterion may need both UI and API evidence.
+
+---
+
+## Required status fields per criterion
+
+Every criterion entry in `acceptance-summary.md` must include:
+
+- **Classification** — `ui`, `api`, or `config`
+- **Code status** — `implemented` or `not implemented`
+- **Automated verification** — `passed`, `failed`, or `not run`
+- **Human verification** — usually `pending` unless a human already checked it
+- **Evidence paths** — screenshot / video / curl / log path(s)
+- **Notes** — blockers, caveats, chosen fixture data, or observed differences
+
+This prevents reviewers from mistaking “implemented” for “tested”.
+
+---
+
+## How to capture proof
+
+### UI / visual criteria
+
+For UI criteria, use **Playwright-first verification**. See `.agent-workflow/playwright-acceptance.md`.
+
+Minimum expected evidence for a UI task:
+
+1. Start the app with the normal local dev flow.
+2. Open the page or flow in the browser automation tool.
+3. Assert the primary visible UI elements from the spec.
+4. Save screenshots for each meaningful state.
+5. Record the result in `acceptance-summary.md`.
+
+Recommended screenshots for page-level UI tasks:
+
+- route landing / entry point
+- top summary section
+- each important tab or subsection
+- post-interaction result state
+- empty or fallback state, if required by the spec
+
+Good verification example:
+
+> Playwright opened `/games`, clicked one row, navigated to `/games/:id`, confirmed the game summary title was visible, and saved `01-route-navigation.png`.
+
+Bad verification example:
+
+> Added `navigate('/games/${row.game_id}')` in the table click handler.
+
+### API / data criteria
+
+1. Ensure the local app is running.
+2. Run a `curl` command against the local server.
+3. Save either:
+   - terminal output into a `.txt` file under the artifact directory, or
+   - a readable code block in the final handoff.
+4. Record the exact endpoint and observed result in `acceptance-summary.md`.
+
+Example pattern:
+
+```bash
+curl -s http://localhost:3000/api/game/123/summary | jq . \
+  > .agent-workflow/artifacts/acceptance-example-20260329/02-game-summary-response.txt
+```
+
+### Config / infra criteria
+
+1. Run the relevant command (`npm run build`, `npm run lint`, etc.).
+2. Save the final useful output lines in a `.txt` file when practical.
+3. Record whether the criterion was actually exercised or only inspected statically.
+
+---
+
+## Artifact naming
+
+Save all files under:
+
+```text
+.agent-workflow/artifacts/acceptance-<spec-slug>-<YYYYMMDD>/
+```
+
+Suggested file naming inside that folder:
+
+```text
+acceptance-summary.md
+01-<criterion-slug>.png
+02-<criterion-slug>.txt
+03-<criterion-slug>.webm
+```
+
+Where:
+- `<spec-slug>` is the spec filename without the date prefix and `.md`
+- `<YYYYMMDD>` is the run date
+- the numeric prefix matches the order of the acceptance criteria in the spec
+
+Keep artifacts concise and reviewer-friendly.
+
+---
+
+## MR handoff
+
+Include an acceptance checklist in the MR description. Format:
+
+```
+## Acceptance verification
+
+✓ 01 — <criterion text> — [evidence](artifacts/...)
+✓ 02 — <criterion text> — [evidence](artifacts/...)
+⚠ 03 — SKIPPED — <reason; manual verification required>
+✗ 04 — FAILED — <what failed and what was done to fix it>
+```
+
+- pass / fail / skipped per criterion
+- relative links to artifact files where applicable
+- short notes for any failure or manual follow-up
+
+---
+
+## Blocking rule
+
+- **All criteria pass** → proceed to docs, mark spec `done`, and open the MR.
+- **Any criterion fails** → record the failure clearly, fix it, and re-run the affected verification.
+- **Untestable locally** → mark as `skipped`, explain why, and specify the manual verification step required.
+
+Never present a criterion as passed when the runtime check was not actually executed.
+
+---
+
+## Quick checklist for agents
+
+Before opening the MR, confirm:
+
+- [ ] `acceptance_proof` is not `false` in the spec (or text-only confirmation was intentional)
+- [ ] artifact folder created at `.agent-workflow/artifacts/acceptance-<spec-slug>-<YYYYMMDD>/`
+- [ ] every criterion has `classification`, `code status`, `automated verification`, `human verification`, and `evidence paths`
+- [ ] UI criteria have Playwright-first browser evidence
+- [ ] API criteria have request/response evidence
+- [ ] artifacts are saved under `.agent-workflow/artifacts/acceptance-<spec-slug>-<YYYYMMDD>/`
+- [ ] MR description includes the acceptance checklist with artifact links
+- [ ] no failed criterion is hidden behind vague wording like “implemented”

package/templates/.agent-workflow/docs/README.md

@@ -0,0 +1,45 @@
+# Docs
+
+This folder contains final feature documentation written after implementation is completed.
+
+## Source of Truth
+
+Read `../README.md` first for the full workflow used by both Users and Agents.
+
+## Purpose
+
+Feature docs provide a concise overview of:
+- **Functional perspective** (stakeholders): value, behavior, and user impact
+- **Technical perspective** (dev/QA): architecture, files, and data flow
+
+## Guidelines
+
+- Use `_template.md` as the starting structure.
+- Keep concise: about one A4 page for Functional and one for Technical.
+- Do not include acceptance criteria, scenario matrices, or edge-case catalogs here.
+- Track non-trivial follow-up changes in the **Change Log**.
+
+## For AI Agents
+
+- Write/update docs after implementation is completed for the spec.
+- Respect spec verification mode:
+  - `verification: true`: write/update docs after implementation approval checkpoint.
+  - `verification: false`: write/update docs autonomously (no approval checkpoint pause).
+- Decide update/create in this order:
+  1. If a doc already lists the spec in `Covered Specs`, update that doc.
+  2. Else if one existing doc clearly matches the same bounded context, update that doc.
+  3. Else create a new doc from `_template.md`.
+  4. Add the spec to `Covered Specs` in the selected/new doc.
+- For ad-hoc non-trivial changes, update the relevant feature doc Change Log after agreeing with the User which document to update.
+
+## Current Feature Docs
+
+- [Fix Full Graphic Popup mobile responsiveness](./fix-full-graphic-popup-mobile-responsiveness.md)
+- [Content page metadata](./content-page-metadata.md)
+- [Sitemap API proxy](./sitemap-api-proxy.md)
+- [Content 301 redirects](./content-301-redirects.md)
+- [RapidAPI Integration And Sync](./rapidapi-integration-and-sync.md)
+- [Match Predictor Data Enrichment](./match-predictor-data-enrichment.md)
+- [H2H Comparison Features](./h2h-comparison-features.md)
+- [Team And Last Games Features](./team-and-last-games-features.md)
+- [Schedule And Prediction Assistant UX](./schedule-and-prediction-assistant-ux.md)

package/templates/.agent-workflow/docs/_template.md

@@ -0,0 +1,35 @@
+# {Feature Title}
+
+## Functional Overview
+
+### Goal / Value
+
+The purpose and value of this feature in the context of the overall software, from a stakeholder perspective. What problem does it solve and why does it matter?
+
+### What it does
+
+Brief description of the feature from a user/stakeholder perspective.
+
+### How it works
+
+Step-by-step user flow or behavior description.
+
+## Technical Overview
+
+### Architecture
+
+High-level description of components involved (backend endpoints, frontend pages, database tables, external integrations).
+
+### Key Files
+
+List of primary files added or modified.
+
+### Data Flow
+
+Brief description of how data moves through the system for this feature.
+
+## Change Log
+
+| Date | Description |
+|------|-------------|
+| YYYY-MM-DD | Initial implementation |