docs(keycloak-session-store): import the session-storage lab as a new project
The keycloak project ended with four open questions that design could not
settle. A two-VM lab was built to answer them by measurement, and this is
that material: 26 experiments, 125 raw command outputs, 22 browser captures.
Follows the import procedure in README.md.
source/ the originating repository verbatim — 78 documents, 28 SVGs,
8 manifests, plus .source-revision recording the commit
final/ the SSOT
document.md 729 lines written from the 29 experiment documents, not
concatenated: what was predicted, what was measured, and
where the measurement itself was wrong
evidence/raw 125 outputs, flattened to <experiment>__<file> because
the originals collided (01-baseline.txt appeared three
times) and the audit only globs the top level
evidence/meta one per raw file; command and exitCode are null and the
README says why rather than inventing them
evidence/browser 22 captures
assets/ three diagrams through techviz
.techviz/ their VizSpecs
A separate project rather than an addition to keycloak: the B-layer answers
that project's four questions, but the A, C and D layers are about cluster
failure, SSO and operations, and one document.md should hold one subject.
The four question records there can point here through 관계.
Recorded rather than papered over: only three of the 28 diagrams were
remade. The repository forbids hand-drawn SVG and forbids titles inside the
canvas; all 28 originals carry both, so converting them is redrawing, not
reformatting. They stay in source/ and the gap is written into the document.
verify-pipeline.py passes. audit-records.py reports no issues.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
DongHyeonka
co-authored by
Claude Opus 5
Claude Opus 5
parent
43bccd08a8
commit
b2963105a8
@@ -0,0 +1,96 @@
|
||||
# Refactoring From Analysis Design
|
||||
|
||||
## Goal
|
||||
|
||||
Use completed `/shared/document-detail/<project>` analysis as the planning context for bounded refactoring, while keeping current application source as the SSOT and retaining verifiable evidence for every change.
|
||||
|
||||
## Core pipeline
|
||||
|
||||
1. Only an analysis snapshot whose queue state is `COMPLETE`, whose recorded revision equals the current repository HEAD, and whose working tree is clean may feed refactoring.
|
||||
2. Findings from `document-detail` become bounded WorkItems. Queue order is controlled by priority, while `type` and `scope` determine execution and verification strategy.
|
||||
3. Each WorkItem is implemented in an isolated Git worktree/branch, never directly in the analysis source checkout.
|
||||
4. Verification evidence is retained under `/shared/refactor-detail/<project>/<work-item>/`.
|
||||
5. An item cannot reach `WAITING_APPROVAL` unless the evidence contract for its type is satisfied.
|
||||
6. Approved merged refactors cause the analysis queue entry to become `REANALYZE`; human-authored repository changes remain an explicit reanalysis decision.
|
||||
|
||||
## Durable layout
|
||||
|
||||
```text
|
||||
/shared/codebase/refactor-queue.yaml
|
||||
/shared/refactor-detail/<project>/<work-item>/
|
||||
├── work-item.json
|
||||
├── plan.md
|
||||
├── evidence/
|
||||
│ ├── environment.md
|
||||
│ ├── baseline/raw/
|
||||
│ ├── after/raw/
|
||||
│ └── comparison.md
|
||||
├── verification/
|
||||
└── diff/
|
||||
```
|
||||
|
||||
The queue carries ordering/state summaries. `work-item.json` is the detail SSOT for the refactor item. `document-detail` is context; current code is source truth.
|
||||
|
||||
## WorkItem fields
|
||||
|
||||
Every item records: id, project, analysisRevision, priority, type, scope, target, status, problem, goal, acceptanceCriteria, and evidence references.
|
||||
|
||||
Allowed initial type taxonomy:
|
||||
|
||||
- `PERFORMANCE`
|
||||
- `CODE_STRUCTURE`
|
||||
- `MODULE_STRUCTURE`
|
||||
- `ARCHITECTURE`
|
||||
- `DATA_ACCESS`
|
||||
- `RELIABILITY`
|
||||
- `CONCURRENCY`
|
||||
- `TRANSACTION`
|
||||
- `SECURITY`
|
||||
- `OPERABILITY`
|
||||
- `CONFIGURATION`
|
||||
- `DEPENDENCY`
|
||||
- `BUILD`
|
||||
- `TESTABILITY`
|
||||
- `CLEANUP`
|
||||
|
||||
Allowed scopes: `LOCAL`, `MODULE`, `CROSS_MODULE`, `PROJECT`.
|
||||
|
||||
Priority determines order (`P0`..`P3`, then queue order). Type/scope never replace priority; they select the verification contract.
|
||||
|
||||
## Performance hard gate
|
||||
|
||||
A `PERFORMANCE` WorkItem must define its measurement contract before source modification:
|
||||
|
||||
- exact measurement command or reproducible procedure;
|
||||
- environment evidence path;
|
||||
- dataset/load fixture identifier;
|
||||
- metrics to compare;
|
||||
- acceptance criteria.
|
||||
|
||||
The baseline must be captured before the refactor. After the change, the same measurement contract must be used. Before `WAITING_APPROVAL`, retained evidence must include:
|
||||
|
||||
- raw baseline output;
|
||||
- raw after output;
|
||||
- environment record;
|
||||
- `comparison.md` containing before/after values, delta, conditions, and acceptance result.
|
||||
|
||||
If equivalent conditions cannot be reproduced, the item is `BLOCKED`; no improvement claim is allowed.
|
||||
|
||||
## Type-directed verification
|
||||
|
||||
- `PERFORMANCE`: baseline + after measurement + comparison + functional regression checks.
|
||||
- `BUILD`: baseline/after build measurement when improvement is claimed, plus build correctness.
|
||||
- `ARCHITECTURE`, `MODULE_STRUCTURE`, `DEPENDENCY`: dependency graph/architecture rules/build/integration evidence as applicable.
|
||||
- `DATA_ACCESS`, `TRANSACTION`, `CONCURRENCY`, `RELIABILITY`: representative integration/contract/failure-path evidence; concurrency or failure injection where the claim depends on it.
|
||||
- `SECURITY`: security regression tests/configuration/negative-path evidence without storing secrets.
|
||||
- `CODE_STRUCTURE`, `CLEANUP`, `TESTABILITY`, `CONFIGURATION`, `OPERABILITY`: behavior-preserving tests plus references/build/runtime checks appropriate to the item.
|
||||
|
||||
All types retain the commands and raw verification outputs used to justify completion.
|
||||
|
||||
## Safety
|
||||
|
||||
- Never refactor an analysis snapshot that is stale or dirty.
|
||||
- Never fabricate benchmark output, runtime evidence, or before/after comparisons.
|
||||
- Never weaken or delete a failing test merely to make a refactor pass.
|
||||
- Never store secrets in evidence.
|
||||
- Large goals must be decomposed into reviewable WorkItems; one scheduled execution works on at most one item.
|
||||
@@ -0,0 +1,68 @@
|
||||
# Refactoring From Analysis Implementation Plan
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [x]`) syntax for tracking.
|
||||
|
||||
**Goal:** Add a durable, type-directed refactoring workspace whose performance items require retained baseline and after evidence.
|
||||
|
||||
**Architecture:** `refactor-queue.yaml` orders bounded items, while `/shared/refactor-detail/<project>/<item>/work-item.json` owns detailed item metadata and evidence references. A dedicated verifier enforces type-specific hard gates, especially the performance baseline/after contract.
|
||||
|
||||
**Tech Stack:** Markdown/YAML/JSON, Python unittest, existing `/shared` workspace.
|
||||
|
||||
**Spec:** `docs/superpowers/specs/2026-08-28-refactoring-from-analysis-design.md`
|
||||
|
||||
## Global Constraints
|
||||
|
||||
- Application source remains read-only during documentation/refactor planning.
|
||||
- Performance claims require retained raw baseline and after evidence under equivalent conditions.
|
||||
- Existing documentation and user files must not be deleted or reset.
|
||||
- No legacy workspace dependency may be introduced.
|
||||
|
||||
---
|
||||
|
||||
### Task 1: WorkItem evidence verifier
|
||||
|
||||
**Files:**
|
||||
- Create: `tools/verify_refactor_work_item.py`
|
||||
- Test: `tools/tests/test_verify_refactor_work_item.py`
|
||||
|
||||
- [x] **Step 1: Write failing tests for type validation and performance evidence gates**
|
||||
- [x] **Step 2: Run tests and observe missing verifier failure**
|
||||
- [x] **Step 3: Implement the verifier**
|
||||
- [x] **Step 4: Run verifier tests green**
|
||||
|
||||
### Task 2: Refactoring skill and contracts
|
||||
|
||||
**Files:**
|
||||
- Create: `.agents/skills/refactoring-from-analysis/SKILL.md`
|
||||
- Create: `.agents/skills/refactoring-from-analysis/references/work-item-contract.md`
|
||||
- Create: `.agents/skills/refactoring-from-analysis/references/type-strategies.md`
|
||||
- Create: `.agents/skills/refactoring-from-analysis/references/performance-evidence-contract.md`
|
||||
- Create: `.agents/skills/refactoring-from-analysis/references/evidence-contract.md`
|
||||
|
||||
- [x] **Step 1: Encode queue eligibility and one-bounded-item rule**
|
||||
- [x] **Step 2: Encode type-directed execution and verification**
|
||||
- [x] **Step 3: Encode performance evidence hard gate**
|
||||
|
||||
### Task 3: Durable queue/detail templates
|
||||
|
||||
**Files:**
|
||||
- Create: `/shared/codebase/refactor-queue.yaml`
|
||||
- Create: `/shared/refactor-detail/README.md`
|
||||
- Create: `/shared/refactor-detail/_templates/work-item.json`
|
||||
- Create: `/shared/refactor-detail/_templates/plan.md`
|
||||
- Create: evidence and verification template directories
|
||||
|
||||
- [x] **Step 1: Create queue SSOT**
|
||||
- [x] **Step 2: Create WorkItem/evidence templates**
|
||||
|
||||
### Task 4: Pipeline integration and verification
|
||||
|
||||
**Files:**
|
||||
- Modify: `AGENTS.md`
|
||||
- Modify: `tools/verify_pipeline.py`
|
||||
- Modify: `tools/tests/test_verify_pipeline.py`
|
||||
|
||||
- [x] **Step 1: Add refactor paths to pipeline verification**
|
||||
- [x] **Step 2: Add instructions for the new stage**
|
||||
- [x] **Step 3: Run all verifier and terminal renderer tests**
|
||||
- [x] **Step 4: Run live workspace verification**
|
||||
@@ -0,0 +1,216 @@
|
||||
# Tech Log Document Pipeline Design
|
||||
|
||||
## Goal
|
||||
|
||||
Build a durable, project-scoped pipeline that turns a codebase into a deeply evidenced analysis document, decomposes that analysis into a root tree of Tech Log records, generates the records and evidence assets, and later performs an editorial pass without depending on any legacy workspace.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Do not publish records to Tech Log automatically.
|
||||
- Do not invent incidents, decisions, measurements, or first-person experiences that are not supported by the codebase, command output, browser evidence, Git history, or explicitly supplied source material.
|
||||
- Do not make the pipeline depend on any legacy document repository or path.
|
||||
- Do not treat the root tree as a brainstorming list. Every node must be traceable to analysis evidence.
|
||||
|
||||
## Workspace contract
|
||||
|
||||
```text
|
||||
/shared/
|
||||
├── codebase/
|
||||
│ └── <project>/
|
||||
│
|
||||
├── document-detail/
|
||||
│ └── <project>/
|
||||
│ ├── README.md
|
||||
│ ├── state.json
|
||||
│ ├── source-index.md
|
||||
│ ├── analysis/
|
||||
│ │ ├── 00-project-overview.md
|
||||
│ │ └── <module-or-scope>.md
|
||||
│ ├── final/
|
||||
│ │ └── document.md
|
||||
│ ├── root-tree.md
|
||||
│ ├── notes/
|
||||
│ ├── checkpoints/
|
||||
│ └── evidence/
|
||||
│ ├── raw/
|
||||
│ ├── terminal/
|
||||
│ ├── browser/
|
||||
│ ├── svg/
|
||||
│ └── meta/
|
||||
│
|
||||
└── Tech-Log-Document/
|
||||
├── AGENTS.md
|
||||
├── README.md
|
||||
├── .agents/skills/
|
||||
│ ├── writing-tech-log-from-analysis/
|
||||
│ └── humanizing-korean-tech-writing/
|
||||
├── tools/terminal-evidence/
|
||||
├── research/korean-tech-writing/
|
||||
├── _templates/project/
|
||||
└── <project>/
|
||||
├── case/
|
||||
├── reference/
|
||||
├── openquestion/
|
||||
├── decision/
|
||||
├── assets/
|
||||
│ ├── raw/
|
||||
│ ├── terminal/
|
||||
│ ├── browser/
|
||||
│ └── svg/
|
||||
└── _meta/
|
||||
```
|
||||
|
||||
## Pipeline stages
|
||||
|
||||
### Stage A — Detailed codebase analysis
|
||||
|
||||
Input: `/shared/codebase/<project>`.
|
||||
|
||||
Output: `/shared/document-detail/<project>`.
|
||||
|
||||
For a small codebase, analysis may converge in one run. For a large codebase, analyze one bounded module or subsystem per run and update `state.json` and `source-index.md`. The final document is a synthesis of completed module analyses, not a fresh rewrite that discards their provenance.
|
||||
|
||||
Required analysis properties:
|
||||
|
||||
- map project/module/package boundaries and dependency direction;
|
||||
- trace representative request, state, persistence, messaging, error, and operational paths when present;
|
||||
- identify implemented behavior separately from declared-but-unwired contracts;
|
||||
- inspect tests, build rules, configuration, Git history, and runtime behavior when they materially change the interpretation;
|
||||
- distinguish observed facts, code-derived inference, hypotheses, and external knowledge;
|
||||
- capture command/browser evidence for claims that benefit from execution verification;
|
||||
- preserve exact versions, paths, commands, status codes, measurements, and identifiers in evidence.
|
||||
|
||||
### Stage B — Root tree derivation
|
||||
|
||||
Input: `final/document.md`, module analyses, source index, evidence.
|
||||
|
||||
Output: `root-tree.md`.
|
||||
|
||||
The root tree is the decomposition contract for all downstream Tech Log records. It groups records by Topic and by kind: CASE, REFERENCE, OPEN QUESTION, DECISION.
|
||||
|
||||
A node is not valid merely because its title sounds useful. Each node records:
|
||||
|
||||
- slug;
|
||||
- source anchors into the detailed analysis;
|
||||
- code/evidence references when relevant;
|
||||
- why it belongs to that record kind;
|
||||
- readiness status;
|
||||
- missing verification, if any;
|
||||
- relations to sibling nodes.
|
||||
|
||||
Allowed readiness values:
|
||||
|
||||
- `READY`: enough grounded material exists to author the record;
|
||||
- `NEEDS_EVIDENCE`: the idea is grounded, but a material claim still needs execution or browser evidence;
|
||||
- `NEEDS_DECISION`: a Decision title is plausible but no project decision has actually been made;
|
||||
- `OPEN`: valid Question with unresolved unknowns;
|
||||
- `BLOCKED`: source material is insufficient or contradictory;
|
||||
- `REJECTED`: candidate must not become a record.
|
||||
|
||||
Only `READY` Case/Reference nodes, actual adopted/proposed project Decision nodes with explicit decision evidence, and legitimate `OPEN` Question nodes may enter Stage C.
|
||||
|
||||
### Record classification contract
|
||||
|
||||
**CASE** — a concrete incident, implementation experiment, failure, diagnosis, or verification sequence exists. It must have a specific observed problem/condition, evidence, and bounded conclusion. Case is the only record kind that may carry rich body Markdown such as code, tables, diagrams, and images.
|
||||
|
||||
**REFERENCE** — a reusable criterion, distinction, or operating/design rule can be extracted from one or more grounded cases or code observations. It must generalize beyond retelling one incident.
|
||||
|
||||
**OPEN QUESTION** — a material design or operational uncertainty remains unresolved. It must state known facts, unknowns, constraints, candidate directions when grounded, and the next verification/decision criterion. It must not smuggle in an answer.
|
||||
|
||||
**DECISION** — the project has actually selected or proposed a direction. It requires explicit decision evidence and at least one supporting relation. A best-practice recommendation is not a project Decision.
|
||||
|
||||
### Stage C — Tech Log record generation
|
||||
|
||||
Input: `root-tree.md` plus cited analysis/evidence.
|
||||
|
||||
Output: `/shared/Tech-Log-Document/<project>/{case,reference,openquestion,decision}` plus assets.
|
||||
|
||||
Generation rules:
|
||||
|
||||
- read the local writing skill before authoring;
|
||||
- generate only root-tree nodes whose status permits generation;
|
||||
- re-open the cited source anchors instead of relying on the root-tree title alone;
|
||||
- never invent a technical reason merely because a technology is present;
|
||||
- never invent first-person experience;
|
||||
- preserve protected literals exactly: numbers, dates, versions, units, source paths, code, commands, URLs, status codes, identifiers, quoted text;
|
||||
- Case rich evidence must be backed by actual raw evidence or a diagram whose semantics are derived from grounded sources;
|
||||
- Reference/Question/Decision fields remain plain text unless the target Tech Log contract changes;
|
||||
- relation metadata is generated from root-tree relations and source provenance.
|
||||
|
||||
### Stage D — Editorial refinement
|
||||
|
||||
Input: generated Tech Log record.
|
||||
|
||||
Output: same record, content-preserving editorial revision.
|
||||
|
||||
The editorial pass must read `humanizing-korean-tech-writing` first. It may alter diction, sentence rhythm, paragraphing, headings, repetition, and awkward connective phrases. It may not delete technical facts for concision, change evidence, change status/decision semantics, manufacture personal experience, or silently broaden/narrow a claim.
|
||||
|
||||
Research on Korean engineering writing is stored under `research/korean-tech-writing/` and distilled into the skill. Runtime editing must not depend on a specific external blog being reachable.
|
||||
|
||||
## Evidence model
|
||||
|
||||
### Raw first
|
||||
|
||||
Evidence is always captured in a raw form before presentation assets are produced.
|
||||
|
||||
```text
|
||||
real command / browser observation
|
||||
↓
|
||||
evidence/raw/<artifact>
|
||||
↓
|
||||
renderer or curated diagram
|
||||
↓
|
||||
evidence/terminal | browser | svg
|
||||
```
|
||||
|
||||
### Terminal evidence
|
||||
|
||||
A command run is stored with command, cwd, execution time, exit code, and output. A deterministic renderer converts that real output into an SVG terminal card. The renderer must:
|
||||
|
||||
- XML-escape all output;
|
||||
- preserve the original raw output separately;
|
||||
- redact obvious secret-bearing environment assignments and authorization/token values from the visual output;
|
||||
- visually mark truncation when the renderer caps lines;
|
||||
- never fabricate output lines.
|
||||
|
||||
### Browser evidence
|
||||
|
||||
Use browser automation only when an application can actually be run and the UI/network behavior is relevant. Store screenshots under the project evidence path and record the URL/state/assertion that makes the screenshot evidentiary rather than decorative.
|
||||
|
||||
### Diagrams
|
||||
|
||||
SVG diagrams may explain architecture, boundaries, sequences, state, or before/after behavior. A diagram is explanatory evidence, not primary proof. Its labels and relationships must be traceable to code or observed behavior.
|
||||
|
||||
## State and idempotency
|
||||
|
||||
Each project has state files so scheduled runs can resume safely. A run must inspect Git status and existing state before editing. It must not overwrite uncommitted user work.
|
||||
|
||||
Detailed-analysis state records at least:
|
||||
|
||||
- project path;
|
||||
- current code revision when Git is available;
|
||||
- analyzed scopes;
|
||||
- pending scopes;
|
||||
- final synthesis status;
|
||||
- root-tree status;
|
||||
- evidence tasks.
|
||||
|
||||
Tech-Log generation state records at least:
|
||||
|
||||
- root-tree revision/hash;
|
||||
- generated nodes;
|
||||
- pending nodes;
|
||||
- editorial status per record;
|
||||
- last validation result.
|
||||
|
||||
## Safety boundaries
|
||||
|
||||
- No automatic `git reset`, `git clean`, branch deletion, push, merge, or destructive filesystem operation.
|
||||
- No automatic production changes.
|
||||
- Do not display or persist credentials in evidence.
|
||||
- Do not silently overwrite source code while doing documentation analysis.
|
||||
- If the codebase changes materially after analysis, mark affected analysis/root-tree records stale before generating new records.
|
||||
|
||||
## Independence requirement
|
||||
|
||||
The new pipeline must be self-contained. Its instructions, skills, templates, tools, and scheduled prompts must not reference or require any legacy document workspace. Existing historical material may be consulted once during migration, but all durable rules must live under `/shared/document-detail` or `/shared/Tech-Log-Document` afterward.
|
||||
@@ -0,0 +1,100 @@
|
||||
# Tech Log Document Pipeline Implementation Plan
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [x]`) syntax for tracking.
|
||||
|
||||
**Goal:** Build a self-contained codebase-to-Tech-Log documentation pipeline with project-scoped analysis, grounded root-tree decomposition, evidence tooling, and editorial skills.
|
||||
|
||||
**Architecture:** `/shared/codebase/<project>` is the source. `/shared/document-detail/<project>` owns deep analysis and the root tree. `/shared/Tech-Log-Document/<project>` owns publishable record drafts and assets. Local skills and templates make all stages independent from historical workspaces.
|
||||
|
||||
**Tech Stack:** Markdown, JSON, Python 3 standard library, SVG, shell-based verification.
|
||||
|
||||
**Spec:** `docs/superpowers/specs/2026-08-28-tech-log-document-pipeline-design.md`
|
||||
|
||||
## Global Constraints
|
||||
|
||||
- No runtime dependency on any legacy document workspace.
|
||||
- Root-tree nodes require source anchors and readiness state.
|
||||
- No invented incidents, decisions, measurements, first-person experience, or technical selection reasons.
|
||||
- Raw evidence precedes rendered evidence.
|
||||
- Terminal SVGs must derive from actual command output and redact obvious credentials.
|
||||
- Editorial refinement preserves technical facts and evidence semantics.
|
||||
|
||||
---
|
||||
|
||||
### Task 1: Workspace contract and templates
|
||||
|
||||
**Files:**
|
||||
- Create: `/shared/Tech-Log-Document/AGENTS.md`
|
||||
- Create: `/shared/Tech-Log-Document/README.md`
|
||||
- Create: `/shared/document-detail/README.md`
|
||||
- Create: `/shared/document-detail/_templates/*`
|
||||
- Create: `/shared/Tech-Log-Document/_templates/project/*`
|
||||
|
||||
- [x] Encode directory ownership, stage boundaries, and safety rules.
|
||||
- [x] Add project analysis state, source-index, final-document, and root-tree templates.
|
||||
- [x] Add Tech Log project output/state templates.
|
||||
- [x] Verify all required paths exist.
|
||||
|
||||
### Task 2: Root-tree and Tech Log generation skill
|
||||
|
||||
**Files:**
|
||||
- Create: `.agents/skills/writing-tech-log-from-analysis/SKILL.md`
|
||||
- Create: `.agents/skills/writing-tech-log-from-analysis/references/record-kinds.md`
|
||||
- Create: `.agents/skills/writing-tech-log-from-analysis/references/root-tree-contract.md`
|
||||
- Create: `.agents/skills/writing-tech-log-from-analysis/references/body-syntax.md`
|
||||
- Create: `.agents/skills/writing-tech-log-from-analysis/references/evidence-and-diagrams.md`
|
||||
- Create: `.agents/skills/writing-tech-log-from-analysis/references/review-checklist.md`
|
||||
- Create: `.agents/skills/writing-tech-log-from-analysis/templates/*`
|
||||
|
||||
- [x] Distill the historical Tech Log format into self-contained references.
|
||||
- [x] Make source provenance/readiness gates mandatory.
|
||||
- [x] Encode different output contracts for Case/Reference/Open Question/Decision.
|
||||
- [x] Add static verification for forbidden legacy-path dependencies and required skill sections.
|
||||
|
||||
### Task 3: Korean technical-writing editorial skill
|
||||
|
||||
**Files:**
|
||||
- Create: `.agents/skills/humanizing-korean-tech-writing/SKILL.md`
|
||||
- Create: `.agents/skills/humanizing-korean-tech-writing/references/editorial-rules.md`
|
||||
- Create: `.agents/skills/humanizing-korean-tech-writing/references/protected-content.md`
|
||||
- Create: `.agents/skills/humanizing-korean-tech-writing/references/research-method.md`
|
||||
- Create: `research/korean-tech-writing/README.md`
|
||||
|
||||
- [x] Encode content-preserving editorial scope.
|
||||
- [x] Carry forward known AI-writing failure patterns without referencing their historical location.
|
||||
- [x] Define how later public-blog research is distilled into the skill without copying a single writer's voice.
|
||||
- [x] Verify protected-content and anti-fabrication rules are present.
|
||||
|
||||
### Task 4: Terminal evidence renderer via TDD
|
||||
|
||||
**Files:**
|
||||
- Create: `tools/terminal-evidence/tests/test_render_terminal.py`
|
||||
- Create: `tools/terminal-evidence/render_terminal.py`
|
||||
- Create: `tools/terminal-evidence/README.md`
|
||||
|
||||
- [x] Write tests for XML escaping, metadata, line rendering, redaction, and truncation marker.
|
||||
- [x] Run tests before implementation and confirm they fail because the renderer is missing.
|
||||
- [x] Implement the minimal renderer using Python standard library.
|
||||
- [x] Run tests and confirm they pass.
|
||||
- [x] Render a sample from real command output and validate the SVG as XML.
|
||||
|
||||
### Task 5: Example root-tree contract
|
||||
|
||||
**Files:**
|
||||
- Create: `/shared/document-detail/_examples/backend-clean-architecture/root-tree.md`
|
||||
|
||||
- [x] Encode the requested JPA feed topic tree as an explicitly marked structural example.
|
||||
- [x] Add source/evidence/readiness metadata placeholders that make clear it is not claimed as newly analyzed evidence.
|
||||
- [x] Verify the example conforms to the root-tree contract.
|
||||
|
||||
### Task 6: End-to-end static verification
|
||||
|
||||
**Files:**
|
||||
- Create: `/shared/Tech-Log-Document/tools/verify_pipeline.py`
|
||||
- Create: `/shared/Tech-Log-Document/tools/tests/test_verify_pipeline.py`
|
||||
|
||||
- [x] Write failing tests for required paths and forbidden legacy dependency strings.
|
||||
- [x] Implement the verifier.
|
||||
- [x] Run all tests.
|
||||
- [x] Search the new pipeline for forbidden legacy-path references.
|
||||
- [x] Print the final directory tree and verification summary.
|
||||
Reference in New Issue
Block a user