diff --git a/.agent/workflows/straymark-followups.md b/.agent/workflows/straymark-followups.md new file mode 100644 index 0000000..817ac7b --- /dev/null +++ b/.agent/workflows/straymark-followups.md @@ -0,0 +1,83 @@ +--- +description: Maintain the follow-ups backlog registry — the canonical answer to "what's pending?". Session-start glance, pre-commit drift --apply, post-Charter-close triage and operator-gated promote. Thin wrapper over the straymark followups CLI; never edits CLI-owned counters by hand. +--- + +# StrayMark Follow-ups Registry Skill + +Maintain the central follow-ups registry (`.straymark/follow-ups-backlog.md`) — the first-class artifact that aggregates `§Follow-ups` and `R (new, not in Charter)` entries across AILOGs *(first-class since fw-4.21.0 / cli-3.19.0)*. The agent is the registry's **primary maintainer**; this skill drives the three directives of `AGENT-RULES.md §13` by delegating every mutation to the CLI (`straymark followups list/status/drift/promote`). The skill contains no extraction or counting logic of its own — parsing, schema validation, counter recomputation, and FU → TDE elevation all live in the CLI. + +> See `.straymark/00-governance/FOLLOW-UPS-BACKLOG-PATTERN.md` and `STRAYMARK.md §16` for the pattern; `AGENT-RULES.md §13` for the shipped directives this skill wraps. + +## When to use this skill + +Trigger on any of: + +- Session start, or the operator asks *"what's pending?"* / *"what follow-ups do we have?"*. +- You created or modified an AILOG containing `## Follow-ups` or `R (new, not in Charter)` entries and are about to commit. +- A Charter just closed and the registry entries it resolved need triage. +- The operator asks to promote a follow-up to a TDE document. + +If the project does not maintain the registry (the per-AILOG `§Follow-ups` convention alone is enough below ~20 AILOGs — see the pattern doc), this skill does not apply. + +## Instructions + +### 1. Session start — answer from the registry + +The registry is the **canonical source** for "what's pending". Answer from it; do not re-scan AILOGs. + +```bash +straymark followups status # registry pulse: counters recomputed on the fly, + # per-bucket breakdown, blocking / suspected-closed alerts +straymark followups list # full entry table +straymark followups list --severity blocking # focus on blockers +straymark followups status FU-NNN # one entry's full field detail +``` + +Fall back to an AILOG scan **only** when the registry does not exist, or when `straymark followups drift` reports unextracted AILOGs. + +### 2. Pre-commit — registry rides the same commit as the AILOG + +Created or modified any AILOG with `## Follow-ups` or `R (new, not in Charter)` entries? Sync before committing: + +```bash +straymark followups drift # detect unextracted AILOGs (exit 1 on drift) +straymark followups drift --apply # extract into `## Bucket: ready`, auto-number FU-NNN ids, + # recompute counters, upgrade v0 registries to v1 in place +``` + +so the registry extension rides **the same commit** as the AILOG. Bullets whose AILOG text already carries a closure marker (`closed in-Charter`, `fixed in batch N`, a backtick-wrapped commit hash) are extracted as `suspected-closed` automatically — **do not delete them**; the operator confirms at the next triage. + +### 3. Post-Charter close — triage what the Charter resolved + +Review the registry entries the just-closed Charter resolved: + +```bash +straymark followups list --status suspected-closed # entries awaiting confirm-or-reopen +straymark followups promote FU-NNN # FU → TDE elevation (operator-approved) +``` + +- Mark resolved entries `closed` (with the closing Charter id in `Notes`) or `superseded`. +- Confirm or reopen any `suspected-closed` entries that the Charter's AILOGs produced. +- For un-resolved entries that meet the TDE criteria of `AGENT-RULES.md §3` (heritage, transversal, dedicated Charter, human prioritization), **propose** promotion via `straymark followups promote FU-NNN` — promotion itself is operator-approved, per the autonomy limits of §3. + +### 4. Report result + +Surface the CLI output verbatim (counters, alerts, created TDE paths). Example after a pre-commit sync: + +``` +✓ Extracted 4 entries from 1 AILOG(s) into `## Bucket: ready`. + ! 1 extracted as suspected-closed (closure marker in source AILOG) — confirm at the next triage. + Counters recomputed: 3 open / 1 suspected-closed / 0 promoted (total 4). + +StrayMark: registry synced — commit it together with the AILOG. +``` + +## What this skill does NOT do + +- **It does not edit the frontmatter counters** (`total_open`, `total_promoted`, `total_suspected_closed`, …). They are CLI-owned: every write command recomputes them. Hand-editing them is a §13 violation. +- **It does not promote without the operator.** `straymark followups promote` is proposed, never auto-run — prioritization and assignment stay human (`AGENT-RULES.md §3`). +- **It does not delete `suspected-closed` entries.** The operator confirms (→ `closed`) or reopens them at the next triage. +- **It does not re-scan AILOGs to answer "what's pending?"** when the registry exists — the registry is canonical; `drift` tells you when it is not trustworthy. +- **It does not replace the per-AILOG `§Follow-ups` section.** That stays the write-time capture point; the registry aggregates it via `drift --apply`. + +> **Terminal compatibility**: If the terminal does not support box-drawing characters (Unicode), use plain-text formatting with dashes and pipes instead (e.g., `+--+` instead of `╔══╗`). diff --git a/.claude/skills/straymark-followups/SKILL.md b/.claude/skills/straymark-followups/SKILL.md new file mode 100644 index 0000000..9fa9c59 --- /dev/null +++ b/.claude/skills/straymark-followups/SKILL.md @@ -0,0 +1,85 @@ +--- +name: straymark-followups +description: Maintain the follow-ups backlog registry — the canonical answer to "what's pending?". Session-start glance, pre-commit drift --apply, post-Charter-close triage and operator-gated promote. Thin wrapper over the straymark followups CLI; never edits CLI-owned counters by hand. +allowed-tools: Read, Glob, Bash(git diff *, git log *, git status *, ls *, straymark followups *) +--- + +# StrayMark Follow-ups Registry Skill + +Maintain the central follow-ups registry (`.straymark/follow-ups-backlog.md`) — the first-class artifact that aggregates `§Follow-ups` and `R (new, not in Charter)` entries across AILOGs *(first-class since fw-4.21.0 / cli-3.19.0)*. The agent is the registry's **primary maintainer**; this skill drives the three directives of `AGENT-RULES.md §13` by delegating every mutation to the CLI (`straymark followups list/status/drift/promote`). The skill contains no extraction or counting logic of its own — parsing, schema validation, counter recomputation, and FU → TDE elevation all live in the CLI. + +> See `.straymark/00-governance/FOLLOW-UPS-BACKLOG-PATTERN.md` and `STRAYMARK.md §16` for the pattern; `AGENT-RULES.md §13` for the shipped directives this skill wraps. + +## When to use this skill + +Trigger on any of: + +- Session start, or the operator asks *"what's pending?"* / *"what follow-ups do we have?"*. +- You created or modified an AILOG containing `## Follow-ups` or `R (new, not in Charter)` entries and are about to commit. +- A Charter just closed and the registry entries it resolved need triage. +- The operator asks to promote a follow-up to a TDE document. + +If the project does not maintain the registry (the per-AILOG `§Follow-ups` convention alone is enough below ~20 AILOGs — see the pattern doc), this skill does not apply. + +## Instructions + +### 1. Session start — answer from the registry + +The registry is the **canonical source** for "what's pending". Answer from it; do not re-scan AILOGs. + +```bash +straymark followups status # registry pulse: counters recomputed on the fly, + # per-bucket breakdown, blocking / suspected-closed alerts +straymark followups list # full entry table +straymark followups list --severity blocking # focus on blockers +straymark followups status FU-NNN # one entry's full field detail +``` + +Fall back to an AILOG scan **only** when the registry does not exist, or when `straymark followups drift` reports unextracted AILOGs. + +### 2. Pre-commit — registry rides the same commit as the AILOG + +Created or modified any AILOG with `## Follow-ups` or `R (new, not in Charter)` entries? Sync before committing: + +```bash +straymark followups drift # detect unextracted AILOGs (exit 1 on drift) +straymark followups drift --apply # extract into `## Bucket: ready`, auto-number FU-NNN ids, + # recompute counters, upgrade v0 registries to v1 in place +``` + +so the registry extension rides **the same commit** as the AILOG. Bullets whose AILOG text already carries a closure marker (`closed in-Charter`, `fixed in batch N`, a backtick-wrapped commit hash) are extracted as `suspected-closed` automatically — **do not delete them**; the operator confirms at the next triage. + +### 3. Post-Charter close — triage what the Charter resolved + +Review the registry entries the just-closed Charter resolved: + +```bash +straymark followups list --status suspected-closed # entries awaiting confirm-or-reopen +straymark followups promote FU-NNN # FU → TDE elevation (operator-approved) +``` + +- Mark resolved entries `closed` (with the closing Charter id in `Notes`) or `superseded`. +- Confirm or reopen any `suspected-closed` entries that the Charter's AILOGs produced. +- For un-resolved entries that meet the TDE criteria of `AGENT-RULES.md §3` (heritage, transversal, dedicated Charter, human prioritization), **propose** promotion via `straymark followups promote FU-NNN` — promotion itself is operator-approved, per the autonomy limits of §3. + +### 4. Report result + +Surface the CLI output verbatim (counters, alerts, created TDE paths). Example after a pre-commit sync: + +``` +✓ Extracted 4 entries from 1 AILOG(s) into `## Bucket: ready`. + ! 1 extracted as suspected-closed (closure marker in source AILOG) — confirm at the next triage. + Counters recomputed: 3 open / 1 suspected-closed / 0 promoted (total 4). + +StrayMark: registry synced — commit it together with the AILOG. +``` + +## What this skill does NOT do + +- **It does not edit the frontmatter counters** (`total_open`, `total_promoted`, `total_suspected_closed`, …). They are CLI-owned: every write command recomputes them. Hand-editing them is a §13 violation. +- **It does not promote without the operator.** `straymark followups promote` is proposed, never auto-run — prioritization and assignment stay human (`AGENT-RULES.md §3`). +- **It does not delete `suspected-closed` entries.** The operator confirms (→ `closed`) or reopens them at the next triage. +- **It does not re-scan AILOGs to answer "what's pending?"** when the registry exists — the registry is canonical; `drift` tells you when it is not trustworthy. +- **It does not replace the per-AILOG `§Follow-ups` section.** That stays the write-time capture point; the registry aggregates it via `drift --apply`. + +> **Terminal compatibility**: If the terminal does not support box-drawing characters (Unicode), use plain-text formatting with dashes and pipes instead (e.g., `+--+` instead of `╔══╗`). diff --git a/.codex/skills/straymark-followups/SKILL.md b/.codex/skills/straymark-followups/SKILL.md new file mode 100644 index 0000000..88a3fff --- /dev/null +++ b/.codex/skills/straymark-followups/SKILL.md @@ -0,0 +1,84 @@ +--- +name: straymark-followups +description: Maintain the follow-ups backlog registry — the canonical answer to "what's pending?". Session-start glance, pre-commit drift --apply, post-Charter-close triage and operator-gated promote. Thin wrapper over the straymark followups CLI; never edits CLI-owned counters by hand. +--- + +# StrayMark Follow-ups Registry Skill + +Maintain the central follow-ups registry (`.straymark/follow-ups-backlog.md`) — the first-class artifact that aggregates `§Follow-ups` and `R (new, not in Charter)` entries across AILOGs *(first-class since fw-4.21.0 / cli-3.19.0)*. The agent is the registry's **primary maintainer**; this skill drives the three directives of `AGENT-RULES.md §13` by delegating every mutation to the CLI (`straymark followups list/status/drift/promote`). The skill contains no extraction or counting logic of its own — parsing, schema validation, counter recomputation, and FU → TDE elevation all live in the CLI. + +> See `.straymark/00-governance/FOLLOW-UPS-BACKLOG-PATTERN.md` and `STRAYMARK.md §16` for the pattern; `AGENT-RULES.md §13` for the shipped directives this skill wraps. + +## When to use this skill + +Trigger on any of: + +- Session start, or the operator asks *"what's pending?"* / *"what follow-ups do we have?"*. +- You created or modified an AILOG containing `## Follow-ups` or `R (new, not in Charter)` entries and are about to commit. +- A Charter just closed and the registry entries it resolved need triage. +- The operator asks to promote a follow-up to a TDE document. + +If the project does not maintain the registry (the per-AILOG `§Follow-ups` convention alone is enough below ~20 AILOGs — see the pattern doc), this skill does not apply. + +## Instructions + +### 1. Session start — answer from the registry + +The registry is the **canonical source** for "what's pending". Answer from it; do not re-scan AILOGs. + +```bash +straymark followups status # registry pulse: counters recomputed on the fly, + # per-bucket breakdown, blocking / suspected-closed alerts +straymark followups list # full entry table +straymark followups list --severity blocking # focus on blockers +straymark followups status FU-NNN # one entry's full field detail +``` + +Fall back to an AILOG scan **only** when the registry does not exist, or when `straymark followups drift` reports unextracted AILOGs. + +### 2. Pre-commit — registry rides the same commit as the AILOG + +Created or modified any AILOG with `## Follow-ups` or `R (new, not in Charter)` entries? Sync before committing: + +```bash +straymark followups drift # detect unextracted AILOGs (exit 1 on drift) +straymark followups drift --apply # extract into `## Bucket: ready`, auto-number FU-NNN ids, + # recompute counters, upgrade v0 registries to v1 in place +``` + +so the registry extension rides **the same commit** as the AILOG. Bullets whose AILOG text already carries a closure marker (`closed in-Charter`, `fixed in batch N`, a backtick-wrapped commit hash) are extracted as `suspected-closed` automatically — **do not delete them**; the operator confirms at the next triage. + +### 3. Post-Charter close — triage what the Charter resolved + +Review the registry entries the just-closed Charter resolved: + +```bash +straymark followups list --status suspected-closed # entries awaiting confirm-or-reopen +straymark followups promote FU-NNN # FU → TDE elevation (operator-approved) +``` + +- Mark resolved entries `closed` (with the closing Charter id in `Notes`) or `superseded`. +- Confirm or reopen any `suspected-closed` entries that the Charter's AILOGs produced. +- For un-resolved entries that meet the TDE criteria of `AGENT-RULES.md §3` (heritage, transversal, dedicated Charter, human prioritization), **propose** promotion via `straymark followups promote FU-NNN` — promotion itself is operator-approved, per the autonomy limits of §3. + +### 4. Report result + +Surface the CLI output verbatim (counters, alerts, created TDE paths). Example after a pre-commit sync: + +``` +✓ Extracted 4 entries from 1 AILOG(s) into `## Bucket: ready`. + ! 1 extracted as suspected-closed (closure marker in source AILOG) — confirm at the next triage. + Counters recomputed: 3 open / 1 suspected-closed / 0 promoted (total 4). + +StrayMark: registry synced — commit it together with the AILOG. +``` + +## What this skill does NOT do + +- **It does not edit the frontmatter counters** (`total_open`, `total_promoted`, `total_suspected_closed`, …). They are CLI-owned: every write command recomputes them. Hand-editing them is a §13 violation. +- **It does not promote without the operator.** `straymark followups promote` is proposed, never auto-run — prioritization and assignment stay human (`AGENT-RULES.md §3`). +- **It does not delete `suspected-closed` entries.** The operator confirms (→ `closed`) or reopens them at the next triage. +- **It does not re-scan AILOGs to answer "what's pending?"** when the registry exists — the registry is canonical; `drift` tells you when it is not trustworthy. +- **It does not replace the per-AILOG `§Follow-ups` section.** That stays the write-time capture point; the registry aggregates it via `drift --apply`. + +> **Terminal compatibility**: If the terminal does not support box-drawing characters (Unicode), use plain-text formatting with dashes and pipes instead (e.g., `+--+` instead of `╔══╗`). diff --git a/.cursor/rules/straymark.md b/.cursor/rules/straymark.md index df02b21..a7ec39d 100644 --- a/.cursor/rules/straymark.md +++ b/.cursor/rules/straymark.md @@ -457,6 +457,49 @@ The command does not touch git — the operator decides when to commit. The `str --- +## 16. Follow-ups backlog — the pending-work registry *(fw-4.21.0+)* + +The **follow-ups backlog** is StrayMark's first-class artifact for *deferred work that outlives the AILOG that recorded it*. Every AILOG documents what is deferred in its `§Follow-ups` section and its `R (new, not in Charter)` risks; past ~20 AILOGs that dispersed knowledge stops being scannable from memory. The registry aggregates it into a single queryable file. + +Like Charters (section 15), the registry is **conceptually distinct** from the 12+4 document types of section 13: + +- It lives at `.straymark/follow-ups-backlog.md` — one file per project, never one file per entry. +- Entries (`FU-NNN`) are organized in five buckets by trigger type (*when actionable*): `ready`, `time-triggered`, `charter-triggered`, `phase-blocked`, `operational`. +- Entry statuses: `open` → `in-progress` → `closed` / `superseded` / `promoted`, plus `suspected-closed` for auto-extracted entries whose source AILOG carries a closure marker. +- Frontmatter counters (`total_open`, …) are **CLI-owned** — recomputed on every write command; never maintain them by hand. + +### Why it matters beyond tracking + +Follow-ups originate not only from planning (ex-ante) but from **execution reality** — test runs, telemetry, staging incidents, real-environment bugs — and they feed planning back: entries become chores, mini-charters, or reshape already-planned Charters (`Destination: charter-replanning`). The registry is the ex-post counterpart of SpecKit. The v1 entry dimensions (`Origin-class`, `Severity: blocking`, `Labels`) exist to make that planning loop queryable. + +### Lifecycle + +| Stage | What happens | CLI | +|-------|--------------|-----| +| **Extraction** | New AILOG with `§Follow-ups` / `R (new)` content → entries auto-extracted into `## Bucket: ready` (or `suspected-closed` when the AILOG text marks them resolved in-Charter). | `straymark followups drift --apply` | +| **Triage** | Operator reclassifies bucket/trigger/destination, fills `Severity`/`Labels`, confirms or reopens `suspected-closed` entries. Typically once per stage close (~1h per 4-8 Charters at reference-adopter scale). | (manual edit + `followups list`) | +| **Consumption** | Entries feed Charter planning; when a Charter addresses an entry, mark `in-progress` → `closed` with provenance in `Notes`. | (manual edit) | +| **Promotion** | Entries meeting the transversal-debt criteria (AGENT-RULES.md §3) are elevated to a TDE document with full traceability. | `straymark followups promote FU-NNN` | + +### How it relates to existing artifacts + +- It **does not replace** per-AILOG `§Follow-ups` — that convention stays; the registry aggregates it. Per-AILOG extraction granularity (the `fully_extracted_ailogs` frontmatter list) is the load-bearing design choice. +- It **feeds** Charters and TDEs: `Destination:` points at where the work lands; `straymark followups promote` creates the TDE with `promoted_from_followup: FU-NNN` traceability. +- Agent directives (session-start glance, pre-commit drift, post-close review) ship in `AGENT-RULES.md §13`. + +### Quick CLI surface + +```bash +straymark followups list # enumerate entries (filters: --bucket, --status, --severity, --label) +straymark followups status [FU-NNN] # registry pulse (counters recomputed on the fly) / entry detail +straymark followups drift [--apply|--scan-all] # detect/extract AILOGs not yet in the registry +straymark followups promote FU-NNN # automate FU → TDE promotion +``` + +> **Schema**: `.straymark/schemas/follow-ups-backlog.schema.v1.json` — experimental v1; hard stabilization gated on a second adopter (Principle #12, ADR-2026-06-03-001). Full convention: `.straymark/00-governance/FOLLOW-UPS-BACKLOG-PATTERN.md`. Template: `.straymark/templates/follow-ups-backlog.md`. + +--- + ## Directive Injection Markers StrayMark uses HTML comment markers to manage injected content in agent configuration files (`AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, `.github/copilot-instructions.md`, `.cursorrules`, `.cursor/rules/straymark.md`): diff --git a/.cursorrules b/.cursorrules index af1db86..ed122cd 100644 --- a/.cursorrules +++ b/.cursorrules @@ -457,6 +457,49 @@ The command does not touch git — the operator decides when to commit. The `str --- +## 16. Follow-ups backlog — the pending-work registry *(fw-4.21.0+)* + +The **follow-ups backlog** is StrayMark's first-class artifact for *deferred work that outlives the AILOG that recorded it*. Every AILOG documents what is deferred in its `§Follow-ups` section and its `R (new, not in Charter)` risks; past ~20 AILOGs that dispersed knowledge stops being scannable from memory. The registry aggregates it into a single queryable file. + +Like Charters (section 15), the registry is **conceptually distinct** from the 12+4 document types of section 13: + +- It lives at `.straymark/follow-ups-backlog.md` — one file per project, never one file per entry. +- Entries (`FU-NNN`) are organized in five buckets by trigger type (*when actionable*): `ready`, `time-triggered`, `charter-triggered`, `phase-blocked`, `operational`. +- Entry statuses: `open` → `in-progress` → `closed` / `superseded` / `promoted`, plus `suspected-closed` for auto-extracted entries whose source AILOG carries a closure marker. +- Frontmatter counters (`total_open`, …) are **CLI-owned** — recomputed on every write command; never maintain them by hand. + +### Why it matters beyond tracking + +Follow-ups originate not only from planning (ex-ante) but from **execution reality** — test runs, telemetry, staging incidents, real-environment bugs — and they feed planning back: entries become chores, mini-charters, or reshape already-planned Charters (`Destination: charter-replanning`). The registry is the ex-post counterpart of SpecKit. The v1 entry dimensions (`Origin-class`, `Severity: blocking`, `Labels`) exist to make that planning loop queryable. + +### Lifecycle + +| Stage | What happens | CLI | +|-------|--------------|-----| +| **Extraction** | New AILOG with `§Follow-ups` / `R (new)` content → entries auto-extracted into `## Bucket: ready` (or `suspected-closed` when the AILOG text marks them resolved in-Charter). | `straymark followups drift --apply` | +| **Triage** | Operator reclassifies bucket/trigger/destination, fills `Severity`/`Labels`, confirms or reopens `suspected-closed` entries. Typically once per stage close (~1h per 4-8 Charters at reference-adopter scale). | (manual edit + `followups list`) | +| **Consumption** | Entries feed Charter planning; when a Charter addresses an entry, mark `in-progress` → `closed` with provenance in `Notes`. | (manual edit) | +| **Promotion** | Entries meeting the transversal-debt criteria (AGENT-RULES.md §3) are elevated to a TDE document with full traceability. | `straymark followups promote FU-NNN` | + +### How it relates to existing artifacts + +- It **does not replace** per-AILOG `§Follow-ups` — that convention stays; the registry aggregates it. Per-AILOG extraction granularity (the `fully_extracted_ailogs` frontmatter list) is the load-bearing design choice. +- It **feeds** Charters and TDEs: `Destination:` points at where the work lands; `straymark followups promote` creates the TDE with `promoted_from_followup: FU-NNN` traceability. +- Agent directives (session-start glance, pre-commit drift, post-close review) ship in `AGENT-RULES.md §13`. + +### Quick CLI surface + +```bash +straymark followups list # enumerate entries (filters: --bucket, --status, --severity, --label) +straymark followups status [FU-NNN] # registry pulse (counters recomputed on the fly) / entry detail +straymark followups drift [--apply|--scan-all] # detect/extract AILOGs not yet in the registry +straymark followups promote FU-NNN # automate FU → TDE promotion +``` + +> **Schema**: `.straymark/schemas/follow-ups-backlog.schema.v1.json` — experimental v1; hard stabilization gated on a second adopter (Principle #12, ADR-2026-06-03-001). Full convention: `.straymark/00-governance/FOLLOW-UPS-BACKLOG-PATTERN.md`. Template: `.straymark/templates/follow-ups-backlog.md`. + +--- + ## Directive Injection Markers StrayMark uses HTML comment markers to manage injected content in agent configuration files (`AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, `.github/copilot-instructions.md`, `.cursorrules`, `.cursor/rules/straymark.md`): diff --git a/.gemini/skills/straymark-followups/SKILL.md b/.gemini/skills/straymark-followups/SKILL.md new file mode 100644 index 0000000..88a3fff --- /dev/null +++ b/.gemini/skills/straymark-followups/SKILL.md @@ -0,0 +1,84 @@ +--- +name: straymark-followups +description: Maintain the follow-ups backlog registry — the canonical answer to "what's pending?". Session-start glance, pre-commit drift --apply, post-Charter-close triage and operator-gated promote. Thin wrapper over the straymark followups CLI; never edits CLI-owned counters by hand. +--- + +# StrayMark Follow-ups Registry Skill + +Maintain the central follow-ups registry (`.straymark/follow-ups-backlog.md`) — the first-class artifact that aggregates `§Follow-ups` and `R (new, not in Charter)` entries across AILOGs *(first-class since fw-4.21.0 / cli-3.19.0)*. The agent is the registry's **primary maintainer**; this skill drives the three directives of `AGENT-RULES.md §13` by delegating every mutation to the CLI (`straymark followups list/status/drift/promote`). The skill contains no extraction or counting logic of its own — parsing, schema validation, counter recomputation, and FU → TDE elevation all live in the CLI. + +> See `.straymark/00-governance/FOLLOW-UPS-BACKLOG-PATTERN.md` and `STRAYMARK.md §16` for the pattern; `AGENT-RULES.md §13` for the shipped directives this skill wraps. + +## When to use this skill + +Trigger on any of: + +- Session start, or the operator asks *"what's pending?"* / *"what follow-ups do we have?"*. +- You created or modified an AILOG containing `## Follow-ups` or `R (new, not in Charter)` entries and are about to commit. +- A Charter just closed and the registry entries it resolved need triage. +- The operator asks to promote a follow-up to a TDE document. + +If the project does not maintain the registry (the per-AILOG `§Follow-ups` convention alone is enough below ~20 AILOGs — see the pattern doc), this skill does not apply. + +## Instructions + +### 1. Session start — answer from the registry + +The registry is the **canonical source** for "what's pending". Answer from it; do not re-scan AILOGs. + +```bash +straymark followups status # registry pulse: counters recomputed on the fly, + # per-bucket breakdown, blocking / suspected-closed alerts +straymark followups list # full entry table +straymark followups list --severity blocking # focus on blockers +straymark followups status FU-NNN # one entry's full field detail +``` + +Fall back to an AILOG scan **only** when the registry does not exist, or when `straymark followups drift` reports unextracted AILOGs. + +### 2. Pre-commit — registry rides the same commit as the AILOG + +Created or modified any AILOG with `## Follow-ups` or `R (new, not in Charter)` entries? Sync before committing: + +```bash +straymark followups drift # detect unextracted AILOGs (exit 1 on drift) +straymark followups drift --apply # extract into `## Bucket: ready`, auto-number FU-NNN ids, + # recompute counters, upgrade v0 registries to v1 in place +``` + +so the registry extension rides **the same commit** as the AILOG. Bullets whose AILOG text already carries a closure marker (`closed in-Charter`, `fixed in batch N`, a backtick-wrapped commit hash) are extracted as `suspected-closed` automatically — **do not delete them**; the operator confirms at the next triage. + +### 3. Post-Charter close — triage what the Charter resolved + +Review the registry entries the just-closed Charter resolved: + +```bash +straymark followups list --status suspected-closed # entries awaiting confirm-or-reopen +straymark followups promote FU-NNN # FU → TDE elevation (operator-approved) +``` + +- Mark resolved entries `closed` (with the closing Charter id in `Notes`) or `superseded`. +- Confirm or reopen any `suspected-closed` entries that the Charter's AILOGs produced. +- For un-resolved entries that meet the TDE criteria of `AGENT-RULES.md §3` (heritage, transversal, dedicated Charter, human prioritization), **propose** promotion via `straymark followups promote FU-NNN` — promotion itself is operator-approved, per the autonomy limits of §3. + +### 4. Report result + +Surface the CLI output verbatim (counters, alerts, created TDE paths). Example after a pre-commit sync: + +``` +✓ Extracted 4 entries from 1 AILOG(s) into `## Bucket: ready`. + ! 1 extracted as suspected-closed (closure marker in source AILOG) — confirm at the next triage. + Counters recomputed: 3 open / 1 suspected-closed / 0 promoted (total 4). + +StrayMark: registry synced — commit it together with the AILOG. +``` + +## What this skill does NOT do + +- **It does not edit the frontmatter counters** (`total_open`, `total_promoted`, `total_suspected_closed`, …). They are CLI-owned: every write command recomputes them. Hand-editing them is a §13 violation. +- **It does not promote without the operator.** `straymark followups promote` is proposed, never auto-run — prioritization and assignment stay human (`AGENT-RULES.md §3`). +- **It does not delete `suspected-closed` entries.** The operator confirms (→ `closed`) or reopens them at the next triage. +- **It does not re-scan AILOGs to answer "what's pending?"** when the registry exists — the registry is canonical; `drift` tells you when it is not trustworthy. +- **It does not replace the per-AILOG `§Follow-ups` section.** That stays the write-time capture point; the registry aggregates it via `drift --apply`. + +> **Terminal compatibility**: If the terminal does not support box-drawing characters (Unicode), use plain-text formatting with dashes and pipes instead (e.g., `+--+` instead of `╔══╗`). diff --git a/.straymark/.checksums.json b/.straymark/.checksums.json index a7e083d..0f4a5b4 100644 --- a/.straymark/.checksums.json +++ b/.straymark/.checksums.json @@ -1,262 +1,265 @@ { - "version": "fw-4.20.0", + "version": "fw-4.22.0", "files": { - ".straymark/00-governance/i18n/es/GB-45438-LABELING-GUIDE.md": "8e447687d00e3dfb9c07498e673b4f62207a749fb244d2f5e36551014bf8643e", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-010-implement-stage5-write-operations.md": "17c99a39b87aa1310c3c4d42172a45af364a190140e77e2afadb77d32bfa206f", - ".straymark/00-governance/i18n/zh-CN/GIT-BRANCHING-STRATEGY.md": "8c3c3b1815fcc15a8a8608bc791135da00b39f6a28028dd66a5aad630f58c9a3", - ".straymark/00-governance/i18n/es/C4-DIAGRAM-GUIDE.md": "a453d2ac88e8f574d94c3c31a671adb619d90f9c5f6e6e7ab1e8e07ffcebbbae", - ".straymark/07-ai-audit/agent-logs/gnome/AILOG-2026-02-07-001-implement-conflict-resolution-ui.md": "3ff8ef2260fe283370e154dd2dec252da6938bba04889be7c4a4ed0c701d0c5b", - ".straymark/templates/i18n/es/TEMPLATE-ETH.md": "499c3da42ad145370f5270b4e6dcb786774d8fed58eb8a2e3082ae90cf447e3b", - ".straymark/templates/i18n/zh-CN/TEMPLATE-DPIA.md": "c5b4a8ccf766cd9e9d2b54b453bd8188d0c06f9af4659805335f9f6b30a545b7", - ".straymark/templates/i18n/zh-CN/TEMPLATE-TES.md": "8e0537b8c3fa9883c235d5e8a8ff9a825deea193be4ecd85e78cc7b28d4220e3", - ".straymark/audits/CHARTER-01/report-gpt-5-2-codex.md": "da314e05715c543e6d8bc975efd580e2a5b83dfb283412f13343e5b99372741d", - ".straymark/05-operations/incidents/.gitkeep": "a0face4379a29d0f518afeb57eb4a1e6f1b6025d38ca02b06ee0fac6febfdfdc", - ".straymark/00-governance/exceptions/.gitkeep": "b4aaf3d190e7dc76189a91d721842a6b74aa9aa9fcb5619ce0d1c5a16f60bf6d", - ".straymark/config.yml": "147df29bc8217097bec143436d3fc51d74250de72789a944837efeecc263f088", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-07-005-integration-testing-session5.md": "1b82138cf872b469358c2ed8205c22aed56c427dc01f9ab77071a30aa1e69316", + ".straymark/00-governance/PRINCIPLES.md": "c9eaa65879fbfa80027ce58e41065de080458420d42faf69f5dff5209f49f883", ".straymark/templates/i18n/es/TEMPLATE-AILOG.md": "f9a16d52eb91be70e8f05fa86e40643ac1ce51eadabcbeecbfc60d7180a8702b", - ".straymark/00-governance/i18n/zh-CN/AGENT-RULES.md": "a69722214839ac9884c0c631dd0b276348b65fd7768d102cae647627e3c96d5b", - ".straymark/templates/i18n/zh-CN/TEMPLATE-MCARD.md": "a44b6839f8e99b348070b11860fc72d5f7dc994d5fd0e604e5875d9653fdbabf", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-001-implement-sync-item-entity.md": "d5cbfc604dc623ccecebe9e5190b857a9a70bf8525007e6da464fef9a29102d0", - ".straymark/00-governance/i18n/zh-CN/SPECKIT-CHARTER-BRIDGE.md": "86c8325c1edb5874ef4e4f4d60f93707a413217b46c1c87b48aa1b49c940ada7", - ".straymark/00-governance/AI-KPIS.md": "ff87081ff4155ddc2fa8c706521d1d23ec4287a5254918f7c77be074d00d09e2", - ".straymark/00-governance/i18n/zh-CN/PIPL-PIPIA-GUIDE.md": "ea36b2fb28167a2991059430fdb5941f65df78a1857779c843dd399ea014de0b", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-001-implement-inode-entry.md": "6937c62c4adbb1b887f0b46d0108a13e1d6d6410768e339ad43bd264356e5696", - ".straymark/templates/i18n/es/TEMPLATE-CACFILE.md": "f66f5e6036162ccb69dbbb04d88b580d0c6e1b0813e89bc9434c8a2975bc5aca", - ".straymark/04-testing/.gitkeep": "1d8198124b57687ba4120fc888f855ffa707c93113d54d3c46c77f5152bd430f", - ".straymark/templates/i18n/zh-CN/TEMPLATE-REQ.md": "12b88923720af80f77910699fedfe80d798131612fe824a592d93334c03169f7", - ".straymark/07-ai-audit/agent-logs/gnome/AILOG-2026-02-05-002-implement-gnome-shell-extension.md": "be1ccf4ff28f1d5f13be0a4e6bd56f4dfa8a5f0457547524042a689462fc0613", - ".straymark/audits/CHARTER-01/report-gemini-3-1-pro-high.md": "3bd2738d6da093d38a76d5b9b7b9f9408986f6033103b4cc58da4148785df3aa", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-009-implement-download-url-streaming.md": "be3fd32be94cfe757b4161fef9ae4b0f5ed7418572a85e8c7ee43e8dafbb91e5", - ".straymark/audits/CHARTER-01/review-fase-1.md": "a7bf7099f46f934324062b55987a2a382801c6d45d43f07a3572834c87124b2c", - ".straymark/03-implementation/i18n/zh-CN/NIST-AI-RMF-MAP-GUIDE.md": "34a5e94e79afcf0ab5de2fdc6c6e732301f4eb08bfc67d9296e270c575117d0d", - ".straymark/templates/i18n/zh-CN/TEMPLATE-SEC.md": "2e92dc4ccf07896b94f3666f975dfb744d430dcede01090ad4f533d33b368fb1", - ".straymark/00-governance/i18n/es/SPECKIT-CHARTER-BRIDGE.md": "eb25b2893d621e25d596ebd1fe0a6946350e50c21023ddf7b48ded34e2b29409", - ".straymark/audits/CHARTER-01/phase-3-gtk4-panel-audit.md": "db3dcf0fac7131e34579c973aec3a7d5d7e3851088ae82a12fca7023b39012fb", ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-010-implement-rate-limiting.md": "a0b187f7c12bf1c50e15ac77ff4280008198b620026991eac13ab2dec719f93a", - ".straymark/00-governance/CHINA-REGULATORY-FRAMEWORK.md": "206be07ad39be89f30ab21e6ba63b54291935132cbd5acbc4ff376f2986a01fb", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-002-add-inodetable-tests.md": "82fb982b5c2e4570b1671356e26e5ba3cf3d1571bf0319f74ec5de03799b9148", - ".straymark/templates/i18n/es/TEMPLATE-INC.md": "85c72cfcdf8ffe1a90654fbb92e9617ae039945ca6b400a326ae93a0eca460bd", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-010-implement-fuse-file-operations.md": "b245ed650d3601ae7d0391b182a35bd76bf819d2dea3f685080cffee64c58ba7", - ".straymark/00-governance/QUICK-REFERENCE.md": "90c9593b001349718df0e1b18833932ec2c88037e2264f47a8f7fb41efe6b7d8", - ".straymark/templates/i18n/zh-CN/TEMPLATE-CACFILE.md": "4375023df05f18c03539fa761cc94c2be503d893a29de5ca6f240b7a400674ad", - ".straymark/templates/TEMPLATE-AILABEL.md": "bd80dc0e46b29b035fed3a6fa072d8d6b10bf4e9a9c2143a456177b6495f05ae", + ".straymark/00-governance/i18n/es/CAC-FILING-GUIDE.md": "b65ab776feb241c7b9d3d876a437dab3e2b48bc5f11e67ac0f3dd95141816deb", + ".straymark/charters/01-road-to-v0-1-0-alpha-1.md": "99c800cd7596aa17c691b06a88af018d8405a1d74da8097f8e84eb44332a4f1a", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-003-implement-mount-unmount.md": "1711e1cd9e0fb4a03771ea350298b983dabd82038b05de630b8f0fa54f762c64", + ".straymark/templates/follow-ups-backlog.md": "fde6fd125dc95e8e14544bbdb64040fe1151b21b8357f2fe38314d0ab6055fe9", + ".straymark/audits/CHARTER-01/phase-3-gtk4-panel-audit.md": "db3dcf0fac7131e34579c973aec3a7d5d7e3851088ae82a12fca7023b39012fb", + ".straymark/00-governance/i18n/zh-CN/QUICK-REFERENCE.md": "2d1f67591c9be998f61f625a1aa2c7452cd7a0c4bee22d1599b032d0848350d0", + ".straymark/07-ai-audit/agent-logs/gnome/AILOG-2026-02-22-001-fix-nautilus-icon-colors-and-invalidation.md": "ffd28e1491b06307b274ba0daa893fa5ff620d288b5f39d0a41a84bc87655cab", ".straymark/00-governance/OBSERVABILITY-GUIDE.md": "43cc4ef2ac9f3f959748095de398c1e3e0bc5af3b0bcfc01a8e8f65686c916d1", - ".straymark/00-governance/C4-DIAGRAM-GUIDE.md": "4fcd9ac522c8638212cfa4f3e4a52bc11db9b58e7a6a5243336bcd3d3c5b632f", - ".straymark/00-governance/i18n/es/PRINCIPLES.md": "e4a36aa9dde25d24644fc1b4cbb7352ab087ced6c1a58be8b16d934b2ec17556", - ".straymark/00-governance/EMERGENT-OBSERVATION-DESIGN.md": "c59c56086e9e1175114a5cbc40f3658744ab6421eb5b872c9f5b85266d9f1727", - ".straymark/03-implementation/i18n/es/NIST-AI-RMF-MEASURE-GUIDE.md": "9e68b6a0c4bb191c970ad3efe384c37c9556cdcf3b3cf6fb33b13dae14545cf4", - ".straymark/06-evolution/technical-debt/TDE-2026-05-28-001-workspace-rustfmt-debt.md": "2eaa6f18a62ac4c7cf09f32842ec0c128b49b083c4bfa70ea7b7f11e654f9aaa", - ".straymark/templates/i18n/es/TEMPLATE-REQ.md": "05df6fda9689f10f5686133c053de0690f7e5f2c987ed54449c522386e010803", - ".straymark/00-governance/TC260-IMPLEMENTATION-GUIDE.md": "b872176b2c69024c64d8642aa495e98c92ed0c06cb4d1b38bea3aaa141bd785e", - ".straymark/00-governance/i18n/es/MANAGEMENT-REVIEW-TEMPLATE.md": "dca187565a315d625f5950e8df05e713b185f74d2f419828be420de775da72cd", - ".straymark/02-design/diagrams/SEQ-005-state-machine-transitions.puml": "b2ad6645e71d839b7017e0505062228db2725d4af39c4c8a1029457add0c44bb", - ".straymark/03-implementation/i18n/es/NIST-AI-RMF-MAP-GUIDE.md": "7147d6e6bcc57b188984f8f532904c545c74c19883947127ca7b03d7b957e28c", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-07-002-implement-sync-status-auth-settings-manager-interfaces.md": "85c4267646d9d9f14888a48a09203d5e77d29af2ee9f5e0e7d3849b4b88b795a", - ".straymark/00-governance/i18n/es/ISO-25010-2023-REFERENCE.md": "d702e5ea546486beb935e2bc49d221d9bc9bdc2228906833ded15bf5b602d9c0", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-05-28-001-mitigate-risk-003-fuse-write-during-hydration.md": "4b353d2210d539e96034e0dd83da90591e248a79cd09a9a97c7f84185df9421f", ".straymark/scripts/check-charter-drift.sh": "a5f4eb92dab38ef4bb96492b994ee37beb90bffa441e5f2331d3b71058460c74", - ".straymark/00-governance/PRINCIPLES.md": "c9eaa65879fbfa80027ce58e41065de080458420d42faf69f5dff5209f49f883", - ".straymark/00-governance/i18n/es/CAC-FILING-GUIDE.md": "b65ab776feb241c7b9d3d876a437dab3e2b48bc5f11e67ac0f3dd95141816deb", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-006-implement-fuse-metadata-ops.md": "7da0129bed0f895de0f5da8add2cc1a1a2fc83d1489708c040f88b361d893409", + ".straymark/audit-prompts/audit-prompt.md": "714ef62051f407ae609350b2ce06e6d153f62c61c0c21819ad92106083f61493", + ".straymark/audits/CHARTER-01/audit-prompt.md": "a9853714885b340d7f8c55a36a56b6d1e42bf2ea614bfd2f8355697a878bf020", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-04-003-create-fuse-migration.md": "dc0c02cdc91f7051820cb4570e6ed2c7830ba85009555db506cc0fc3baac59d8", + ".straymark/templates/i18n/es/TEMPLATE-AILABEL.md": "45896f5548fa688e3d7af47cf7fd70a0b3a21b1a72a652eb3720fabb6fc7c031", + ".straymark/00-governance/exceptions/.gitkeep": "b4aaf3d190e7dc76189a91d721842a6b74aa9aa9fcb5619ce0d1c5a16f60bf6d", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-007-implement-download-upload-operations.md": "fe158b78d81cb93e8381e189751ca6e4117fdac93556f3c98ae19147c61ce7bd", + ".straymark/templates/i18n/zh-CN/TEMPLATE-SEC.md": "2e92dc4ccf07896b94f3666f975dfb744d430dcede01090ad4f533d33b368fb1", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-007-implement-graph-delta-api.md": "8a595e91291633c853f0139563d3b63053a1bea8d351d119e65a7dadff440e08", + ".straymark/audits/CHARTER-01/external-audit-pending-fase-1.yaml": "de6569fb7a7018fa0479ed45c62f7cc74902423db28c66b2167628bdf9f473ae", + ".straymark/02-design/diagrams/SEQ-003-delta-token-expiry.puml": "37b9ab48f382167b4991335a957055ce923c320ab80354d9b80e5a97015f5d4c", + ".straymark/schemas/charter.schema.v0.json": "8088aed6bdf2fd2c0baf080f3f3cbc72c97c9fad59e6767b476541f6bb97c625", + ".straymark/templates/i18n/es/TEMPLATE-ETH.md": "499c3da42ad145370f5270b4e6dcb786774d8fed58eb8a2e3082ae90cf447e3b", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-002-implement-config-module.md": "e7a257c02a4b85751e9eb578e9ae000f72ec5377a81f2e101fba212ac36383ea", + ".straymark/07-ai-audit/ethical-reviews/ETH-2026-05-29-001-oauth-token-keyring-handling.md": "5d1f2cb144f510a98b2d5e8f93f6cb955efcb71add08f506f606f41e7f975819", + ".straymark/07-ai-audit/agent-logs/gnome/AILOG-2026-02-05-001-implement-mock-dbus-daemon.md": "a868e337e700b02021c392f050b72e5d8d0a46140027ced2d8cff898746bbdae", + ".straymark/00-governance/FOLLOW-UPS-BACKLOG-PATTERN.md": "2bda77fa245416559a263b9361faef3fb1e085d21477aaa2841439f64320ecb9", + ".straymark/00-governance/i18n/es/QUICK-REFERENCE.md": "07527a21e42f7611fe08bd675b8d314f237c33dec163e545bbaa0901129918fe", + ".straymark/templates/i18n/es/TEMPLATE-REQ.md": "05df6fda9689f10f5686133c053de0690f7e5f2c987ed54449c522386e010803", + ".straymark/templates/TEMPLATE-CACFILE.md": "dabfc70f42a4b441cd6e5bbd92d9cff35f3e37aabb8e9eaa3c68dd57d3e47816", + ".straymark/00-governance/i18n/zh-CN/OBSERVABILITY-GUIDE.md": "13754aef4f75e8325acc7cc00e94fc29177ae5b6ded163bab1796bdab25f3511", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-009-implement-cli-sync-command.md": "519a1a1459585e8e1c480990997425599b81ade201728150778e146f86bdefab", + ".straymark/templates/i18n/es/TEMPLATE-SBOM.md": "91405d08eb76c063be7b245e73b79c833f9cf9ad6e1c1290675593bd476c974c", + ".straymark/templates/i18n/zh-CN/TEMPLATE-AIDEC.md": "3bd1649c19e6f56d085b003799609ee2594da47f91da9aa9ec62842e789daad8", + ".straymark/templates/TEMPLATE-SEC.md": "233afc81358b9b9aabad8634b50b4a8577d6eec0e2393cfad14af7a4a3cac380", + ".straymark/05-operations/runbooks/.gitkeep": "165100a8abe03040590c2ee3b051950527bf0250f8c5febaf529a27089751bc3", + ".straymark/templates/TEMPLATE-SBOM.md": "63b12459a75baac37a6ca69008bded565e9d4876dcafc8636e8e9a05ac87193f", + ".straymark/00-governance/i18n/zh-CN/TC260-IMPLEMENTATION-GUIDE.md": "fbcf0f709084fc2b0729b5c040d8e440f13a412c9594cba4bfe0c246e8e410bc", ".straymark/audits/CHARTER-01/report-gemini-3-1-pro-high-fase-1.md": "602c99d6e70094c88c4d6eb6299ed485cc0265004dbe2cce6da28fb494e2d2e7", - ".straymark/09-ai-models/.gitkeep": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", - ".straymark/templates/i18n/zh-CN/TEMPLATE-SBOM.md": "0c0294b3981ea6fa21357aaf619a3117b607b87e1b814386566c7ed0e03f34b1", + ".straymark/07-ai-audit/agent-logs/gnome/AILOG-2026-05-31-002-fase-3-gtk4-panel-audit-and-fixes.md": "3d876d6a7308f0e4934f903f7c63ca31391887f68dedb47b910d5b367c4788e5", + ".straymark/templates/i18n/es/TEMPLATE-TC260RA.md": "04f1daad1f11b39586b2fc59e7c3738b67471cf445f7124e477ebab91e0185f7", + ".straymark/templates/i18n/zh-CN/TEMPLATE-AILABEL.md": "c60d8b9cfff6732928c85e1db1cf81ffc3f5cac006865bf5f454db152281d4d9", + ".straymark/templates/i18n/zh-CN/TEMPLATE-INC.md": "10d572b5ee347c79e5dc4d135fada22662f0b1a7e7fd245126f0cb89a2b4d2ca", + ".straymark/templates/TEMPLATE-DPIA.md": "526f2bc1fe4449138fb3a80bfd8c9bde432d2c0e48ccb14003734f0fba2119ef", + ".straymark/03-implementation/i18n/es/NIST-AI-RMF-MEASURE-GUIDE.md": "9e68b6a0c4bb191c970ad3efe384c37c9556cdcf3b3cf6fb33b13dae14545cf4", + ".straymark/03-implementation/i18n/zh-CN/NIST-AI-RMF-MEASURE-GUIDE.md": "2465b6bc4750b1c61d8fdd321dd1ad10c94fad8e65094e2e74f2c745b344157b", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-009-implement-download-url-streaming.md": "be3fd32be94cfe757b4161fef9ae4b0f5ed7418572a85e8c7ee43e8dafbb91e5", ".straymark/07-ai-audit/agent-logs/guide/AILOG-2026-01-31-001-architectural-simulation.md": "7c448db7641b39462d6c813a21bb0abf3cc55f1e6f9be08766ba032cb5625ab5", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-007-implement-local-filesystem-adapter.md": "135270ed26bd1d5b377c94931155681dec70f75d4499e33e443888b5f1b68175", - ".straymark/03-implementation/i18n/es/NIST-AI-RMF-GOVERN-GUIDE.md": "88381cca102901e983194404d5445d4696b73dbaf641a6128b205af6b0286984", - ".straymark/00-governance/ISO-25010-2023-REFERENCE.md": "28641b79cef89279abb6ce8bf00fae3b909524965920828b7517a80dc22a3dd0", - ".straymark/templates/TEMPLATE-AIDEC.md": "169119a5e9e386817cba67778c6f3201390bcb0c5120aab2e77aea44f3e39b10", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-006-implement-graph-auth-client.md": "6cbb22ecbdf24525e5e3e56e30cfbc2726a0bf239e0048b2db0ae5dd6335d22a", - ".straymark/08-security/.gitkeep": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-07-005-integration-testing-session5.md": "1b82138cf872b469358c2ed8205c22aed56c427dc01f9ab77071a30aa1e69316", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-016-implement-t086-dehydration-lifecycle.md": "7769261dd4b6c8a9a836bf71eaf358089176e29531492bae6ca5ca0acf2b46b7", + ".straymark/audits/CHARTER-01/upstream-feedback-drafts.md": "0c3a4b0512b0607af7178f797b5408f95cd1ff081150e23408697c06f9961b0e", + ".straymark/02-design/risk-analysis/BACKLOG-simulation-issues.md": "6f2c63971c5f5c75ee286d46e84709a69efc979b567a3e2744d7e2c9ede7c541", + ".straymark/03-implementation/NIST-AI-RMF-MANAGE-GUIDE.md": "dc336008b7e8af796b0698e9f6f9561ffa64659d1315611ae0d7106dd9408c2e", + ".straymark/templates/i18n/zh-CN/TEMPLATE-ADR.md": "0382b299ee60dea18cee148026f4cefb953738a7b5ee3a6f18f1f14c78d7031a", ".straymark/templates/i18n/zh-CN/TEMPLATE-PIPIA.md": "6ab14be9646855e2f59d4ad23e6388309d48fe1f9db474ae541ed5d9ba3f99ed", - ".straymark/07-ai-audit/agent-logs/.gitkeep": "9f44184239ba322e5771ca92e19e789d0dcd4d59475e2474fdb7bb5eff99048f", - ".straymark/charters/01-road-to-v0-1-0-alpha-1.md": "99c800cd7596aa17c691b06a88af018d8405a1d74da8097f8e84eb44332a4f1a", - ".straymark/templates/i18n/es/TEMPLATE-TES.md": "5243b4cad67e626c0446aab7b16e9a04d837c14e37d60eab09f71b5ba59b059c", - ".straymark/templates/TEMPLATE-SBOM.md": "63b12459a75baac37a6ca69008bded565e9d4876dcafc8636e8e9a05ac87193f", - ".straymark/06-evolution/technical-debt/.gitkeep": "a1e8aa0b06407e59dee1a6f3f52e47a6044aeca3fcc2a2108c853cb775428a6a", - ".straymark/templates/i18n/es/TEMPLATE-MCARD.md": "cc4b9587b03e5a400e024f012932de8f1ff6bf1deef5e86f58e5bd1a9310893f", - ".straymark/templates/i18n/es/TEMPLATE-SBOM.md": "91405d08eb76c063be7b245e73b79c833f9cf9ad6e1c1290675593bd476c974c", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-20-001-mvp-closure-blocks-1-3-daemon.md": "a574b2ea4ab5ddfbb67ead8cb0cc7802bbc74128d2253e2cf83331551fc33e98", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-002-implement-config-module.md": "e7a257c02a4b85751e9eb578e9ae000f72ec5377a81f2e101fba212ac36383ea", - ".straymark/templates/TEMPLATE-CACFILE.md": "dabfc70f42a4b441cd6e5bbd92d9cff35f3e37aabb8e9eaa3c68dd57d3e47816", - ".straymark/07-ai-audit/agent-logs/gnome/AILOG-2026-02-05-003-implement-nautilus-extension.md": "c9361e884623f9e6a85e8c04a200c87e80352d17a4e847c399ccfe5aeb985dc4", - ".straymark/00-governance/i18n/zh-CN/AI-GOVERNANCE-POLICY.md": "e82bcd63f0146cb66d3beb35a39d3604a2ca43461eeb2873606096bbd684f00f", - ".straymark/07-ai-audit/decisions/AIDEC-2026-05-28-001-yaml-parser-serde-norway.md": "d32f0b6b7c156a2fdb48ef3e088f7ab46711ce616c9ccfed1564358ae52b9fdd", - ".straymark/00-governance/i18n/es/TC260-IMPLEMENTATION-GUIDE.md": "ec6a617388a5ebbdc2d7821c4193ba876131e007c8713d75f483df8b36a971f6", - ".straymark/templates/TEMPLATE-INC.md": "1c7c35e1c1124b0b3511b78ba73ae6f6ee16e671b41e3f541f1f68cf37aff2ba", - ".straymark/00-governance/i18n/zh-CN/POLISH-CHARTER-PATTERN.md": "50bb0c37ca27179414448eabf9c304ddcb93b09ca2200326a311577f2c22a55d", - ".straymark/02-design/diagrams/SEQ-002-dbus-recovery.puml": "15075011fd301f28fb3b37b2df835f1db25c092537b94aa62681db83ff811bb8", - ".straymark/templates/charter/i18n/es/charter-template.md": "6adec14c9ae797002638d05d7a76d089f6575db085143f5a2703649c45bbc972", - ".straymark/07-ai-audit/agent-logs/guide/AILOG-2026-05-29-001-roadmap-v0-1-0-alpha-foundation.md": "60b8c0887790bdcab0d3159b2f197c03d8363e7a299673206673cd0c6d4e4b1f", - ".straymark/00-governance/AI-GOVERNANCE-POLICY.md": "9d3218cbc810ac82e173b47ec01d260e8e0944080fb9d34bc6e655988d3c52bf", - ".straymark/00-governance/CAC-FILING-GUIDE.md": "e8eb5997947eda98a529673b1a33c67d5c7045bee691e2785a17487eaf5e1259", - ".straymark/00-governance/i18n/es/DOCUMENTATION-POLICY.md": "41718dd2d80b30ed80fe48ed95111966def9d63a29d2c31438cbf5aafa3956ec", - ".straymark/00-governance/i18n/zh-CN/CAC-FILING-GUIDE.md": "64342c55cd989eda5572671f3b5002868427eec018babe4d191e8ce1e255f0c9", - ".straymark/03-implementation/i18n/zh-CN/NIST-AI-RMF-MANAGE-GUIDE.md": "2a2d6c099ab1afa7da9afc612bfe601d1ae046155ccd93c89a95e28afa4ae674", + ".straymark/config.yml": "147df29bc8217097bec143436d3fc51d74250de72789a944837efeecc263f088", + ".straymark/03-implementation/NIST-AI-RMF-MAP-GUIDE.md": "5250919126a82e6e1fcbb138d07c9cf6032dfa7b65982be2624b7301f4a1e660", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-05-28-001-mitigate-risk-003-fuse-write-during-hydration.md": "4b353d2210d539e96034e0dd83da90591e248a79cd09a9a97c7f84185df9421f", + ".straymark/03-implementation/NIST-AI-600-1-GENAI-RISKS.md": "39925646e8f493e4086b19c478cef32c703bb303192316c2f287837b21fb52fe", + ".straymark/schemas/follow-ups-backlog.schema.v1.json": "3bcfd009db4e78bae8c20e388b69b09cc68ab04ea9942f9d8df52ed6af33507b", + ".straymark/00-governance/i18n/es/MANAGEMENT-REVIEW-TEMPLATE.md": "dca187565a315d625f5950e8df05e713b185f74d2f419828be420de775da72cd", + ".straymark/templates/i18n/es/TEMPLATE-AIDEC.md": "bb8beb96d469feb7ee75b51c7e4fb224207d2732de372fcd3c6070d0a119b72c", + ".straymark/07-ai-audit/agent-logs/governance/AILOG-2026-06-01-001-straymark-fw-4-20-0-upgrade.md": "15b40cdc5c6746cfe6283f5c78fd84a77f4cec6e30db0dac91ba7360f42bf1d8", + ".straymark/00-governance/i18n/es/DOCUMENTATION-POLICY.md": "b9fd11afe14a1300574d88dad52f7e9264fd6d0f6fac80a6c8fbbf745aa2ce9e", + "STRAYMARK.md": "e073c77f5b030f2f20f9dbab276af2639edb89369245910035222daf4a1d2866", + ".straymark/templates/TEMPLATE-ADR.md": "8f5fda2aa1a029b2f0280f34d4cbb4e7240422fd18a91c41670a745bd2046011", + ".straymark/templates/i18n/es/TEMPLATE-CACFILE.md": "f66f5e6036162ccb69dbbb04d88b580d0c6e1b0813e89bc9434c8a2975bc5aca", + ".straymark/00-governance/i18n/zh-CN/MANAGEMENT-REVIEW-TEMPLATE.md": "50edbc0de0c2f1096432ea4330acad2b909a0408d3ee011581185dcbb83678f1", + ".straymark/00-governance/i18n/zh-CN/GB-45438-LABELING-GUIDE.md": "d1575f05c03cb32331df7fe6d4465532d3a0fdf75e46daa51b7f1502703e5b3d", + ".straymark/dist-manifest.yml": "44bc13a2d1b27102e0028f9727ce2b8969541e9621ac29ae5ac18736d2850f77", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-05-28-002-mitigate-risk-001-dbus-health-monitor.md": "501690cbaedd7ffc17a8ef7633acc5dc1cf72f8c576c129d54649524664cce8a", + ".straymark/templates/i18n/es/TEMPLATE-ADR.md": "a1c654bd1a999f5e874c59ddc406179cb1f4ada98bec606355197bcba19c468a", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-007-implement-local-filesystem-adapter.md": "135270ed26bd1d5b377c94931155681dec70f75d4499e33e443888b5f1b68175", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-015-implement-stage10-polish.md": "9ac1d61de3c142b38dae285775eb9ad50cdf1c08993f006f5d88e50c1d80bc6e", + ".straymark/03-implementation/i18n/zh-CN/NIST-AI-RMF-MAP-GUIDE.md": "34a5e94e79afcf0ab5de2fdc6c6e732301f4eb08bfc67d9296e270c575117d0d", ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-008-implement-stage2-foundational.md": "6ff68ddce42c84e86023468ecd7162b005bab8bd0d8c55f9bb4084e3ee0b2c8f", - ".straymark/07-ai-audit/agent-logs/gnome/AILOG-2026-03-17-001-implement-goa-provider.md": "e37835325af5b923804aa9d315c77b4c7926a7d1c6f8e9d6a3b31641109f4499", - ".straymark/templates/TEMPLATE-MCARD.md": "f72567856ab5f78129a03695f6976dd8cfbb64ef6974b3a5c671123732f19ca3", - ".straymark/02-design/diagrams/SEQ-001-fuse-hydration-race.puml": "55184dabe4dea6224aa379c065d3cf25183bb5041d7e5662877f5b291bb89203", - ".straymark/00-governance/i18n/es/AGENT-RULES.md": "68800ba06cf3813492a6f0cb5e2857fe4984ac865044d6520417cb2a6df556fb", + ".straymark/07-ai-audit/agent-logs/.gitkeep": "9f44184239ba322e5771ca92e19e789d0dcd4d59475e2474fdb7bb5eff99048f", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-010-implement-fuse-file-operations.md": "b245ed650d3601ae7d0391b182a35bd76bf819d2dea3f685080cffee64c58ba7", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-05-29-002-mitigate-risk-002-oauth-keyring-session-handle.md": "e2ba03354c2a84b4cef5c49a50bf08909e9d3c280052cb9f9ff5d22cc6d9e12b", + ".straymark/07-ai-audit/decisions/AIDEC-2026-05-31-001-defer-system-settings-group.md": "73482d85d561478c583d0f91d1235dd2a4b0c2ad56ff764915447a359b3567b3", + ".straymark/templates/i18n/zh-CN/TEMPLATE-CACFILE.md": "4375023df05f18c03539fa761cc94c2be503d893a29de5ca6f240b7a400674ad", + ".straymark/00-governance/i18n/es/SPECKIT-CHARTER-BRIDGE.md": "eb25b2893d621e25d596ebd1fe0a6946350e50c21023ddf7b48ded34e2b29409", + ".straymark/templates/i18n/zh-CN/TEMPLATE-DPIA.md": "c5b4a8ccf766cd9e9d2b54b453bd8188d0c06f9af4659805335f9f6b30a545b7", ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-018-validate-quickstart.md": "b3bddf435aa2d26965dc38607d03bb560f028baf903b34d51ee8d73a29c30acb", - ".straymark/audits/CHARTER-01/audit-prompt-fase-1.md": "a3406d73e4583df58b2b8d65c4e09c7a5c66e46f341b865320629e09344c55c4", - ".straymark/templates/i18n/es/TEMPLATE-SEC.md": "2371394f9f8863adfa571baae9abc2a33c451775a995c40f3e2cac256630b04f", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-005-implement-cli-auth-commands-output.md": "ca7c60d2013079dcb1afdc4dc8f163306e295ec15f46ff4c311a77f5789ace34", - ".straymark/00-governance/i18n/es/POLISH-CHARTER-PATTERN.md": "2d9c28cb3912b10c0c7102935c9f9691d7a5be2c55043a17eedae9dd9c00e727", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-04-002-complete-phases-0-1.md": "d6f4e6302846aa39f670bb8f1375c2e88244585a043ef23f09b40531bde25180", - ".straymark/audits/CHARTER-01/review.md": "58e43d2b8e9b0ddff65212e61a8f16528b4dfd854b7515e8a22a3686c60cb735", - ".straymark/00-governance/i18n/zh-CN/GB-45438-LABELING-GUIDE.md": "d1575f05c03cb32331df7fe6d4465532d3a0fdf75e46daa51b7f1502703e5b3d", - ".straymark/00-governance/i18n/zh-CN/ISO-25010-2023-REFERENCE.md": "0007111673a3901cd0ef8e7c182be853cdb3d2b9b5e8e87d7cca71bbb2479d7e", - ".straymark/templates/TEMPLATE-AILOG.md": "9ab5eb8131285dbf37fdd7fb92d0376bfb99cf506432f562c3c490ea96ce4135", - ".straymark/02-design/diagrams/SEQ-004-conflict-resolution.puml": "a0b642d8421ca3151eca5ffa868c87abb6e2720d0a1ed54fae2f6d301e30a6f8", - ".straymark/02-design/risk-analysis/RISK-001-critical-paths.md": "f5d093dcb0c0119479e67128f55af3a512bae4b660a0bf03a53c4c83e90d3629", - ".straymark/02-design/risk-analysis/TRACE-risks-mitigations.md": "e05a24584c0591f4a4dcc6c1720fefd5747aad0116a7667ab1d564c9ee7e89d4", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-05-28-003-mitigate-issue-002-yaml-billion-laughs.md": "132a88866c6b5164145338114008c2c8acdc7bcabab74576d233904bd1e7efee", - ".straymark/audit-prompts/i18n/es/audit-prompt.md": "2ef095a7e15e70ae2a23e53fc62b0444835c18aebbf5616bcfc2d3425e60c8ce", - ".straymark/00-governance/SPECKIT-CHARTER-BRIDGE.md": "fc940600a27ed9a4fc6437fb1613d7f2bff6aa49285a05351afc582e705e3eeb", - ".straymark/07-ai-audit/agent-logs/gnome/AILOG-2026-05-31-002-fase-3-gtk4-panel-audit-and-fixes.md": "3d876d6a7308f0e4934f903f7c63ca31391887f68dedb47b910d5b367c4788e5", - ".straymark/templates/TEMPLATE-TC260RA.md": "8c0ef4be7a9c9811d3c3dee8262270cc5d3501c88cb1c798f8d7f4038429df71", - ".straymark/templates/charter/charter-telemetry-template.yaml": "1f22bfd50b1d581699818c09cd3d8ca6873c3dbea148af29a6d1522698c4a4b6", - ".straymark/templates/TEMPLATE-REQ.md": "736eda155f48484c437a3754055ebf9d8705d9bbc00af43a6a9d5ec9216a31c4", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-007-implement-download-upload-operations.md": "fe158b78d81cb93e8381e189751ca6e4117fdac93556f3c98ae19147c61ce7bd", - ".straymark/templates/i18n/es/TEMPLATE-AILABEL.md": "45896f5548fa688e3d7af47cf7fd70a0b3a21b1a72a652eb3720fabb6fc7c031", - ".straymark/00-governance/DOCUMENTATION-POLICY.md": "310a1a768fe201f748dbbffd3d23a58947323edc817edc01305d4d1a4146cde3", - ".straymark/00-governance/i18n/es/FOLLOW-UPS-BACKLOG-PATTERN.md": "22765efe9778ff90f83d6ea359962c741264e424e2288a4c78e30a1272d4cfdc", - ".straymark/00-governance/i18n/es/PIPL-PIPIA-GUIDE.md": "1eaba2df6eff107f7126b7ef990110615eabf57dd139f87981c95040525c5909", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-003-implement-mount-unmount.md": "1711e1cd9e0fb4a03771ea350298b983dabd82038b05de630b8f0fa54f762c64", - ".straymark/templates/i18n/zh-CN/TEMPLATE-ETH.md": "dc53846625e4e10f6f6026bc51a3a10969fd664f5147fc3923b7e448da644cff", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-005-implement-lnxdrivefs-struct.md": "9a85cf9a96e8a69684e728ac8ab1d2f13e75e95fee41426a56c4fd07dca4197b", - ".straymark/05-operations/runbooks/.gitkeep": "165100a8abe03040590c2ee3b051950527bf0250f8c5febaf529a27089751bc3", - ".straymark/00-governance/i18n/es/QUICK-REFERENCE.md": "93feaa37a5ec05526610cb6092e90fdecaf7f4417324d7150b3a95be313064bc", - ".straymark/00-governance/FOLLOW-UPS-BACKLOG-PATTERN.md": "f6ddd5b2c71988e97abc1c1ad776fa8f214a5e53df67a73608374469fb5efad7", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-04-001-implement-container-functional-testing.md": "a2fe201dc937b18e2faac088c0000ad1c7c96867c9dbf3b3d0f82fc265e596cd", - ".straymark/templates/i18n/zh-CN/TEMPLATE-TC260RA.md": "4440a8b052a00e3ced4894a6860b67f4642a8bf02b1fc0ad2855c00f3c5ffdaa", - ".straymark/templates/TEMPLATE-ETH.md": "768e6e32d3f83158fa81816c646e05810042adbcd3d007907007a1cf777c0ca8", - ".straymark/00-governance/AGENT-RULES.md": "d66e603ec97066d0833b110502d62507a9123b5f26d79cf6cffd6237f6f1df9a", ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-013-implement-stage8-xattr.md": "74c7008239a7b1d54e5b4685e3974072aa330c498c190e6f6d6e1bc7c28937cf", - ".straymark/templates/TEMPLATE-DPIA.md": "526f2bc1fe4449138fb3a80bfd8c9bde432d2c0e48ccb14003734f0fba2119ef", - ".straymark/00-governance/i18n/zh-CN/AI-LIFECYCLE-TRACKER.md": "342be350dd7a7bc7135b081b91064c1fabafcc0bff6b40d762b90d0add050fa3", - ".straymark/00-governance/i18n/es/AI-RISK-CATALOG.md": "03fd6b95a2917b6fb16f31e7622be34fd2d77ae23e35b47b67c6b86a0aa4be3b", - ".straymark/00-governance/i18n/zh-CN/QUICK-REFERENCE.md": "1be823289ac5eaf90b095b4f57b698d502d104ab4b10b78ae78585cf8889cb67", - ".straymark/00-governance/i18n/zh-CN/DOCUMENTATION-POLICY.md": "0505f29c0f3f5462f5a051fb59f9b2183ddb2a9202efd8680caf023f1f32556b", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-004-implement-cli-mount-commands.md": "6fec43ed94bbd9a6af97b18cfd9c1ecf4d0a9df87387217c120b49d2919805c1", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-20-002-mvp-closure-block-4-distribution-infra.md": "ac063bbe14abe81a37e9c74ed69073c69cc4eed2d765299a3ad252791599af97", - ".straymark/templates/i18n/es/TEMPLATE-PIPIA.md": "7560a634a0484fcb16192146d617812cc1048204ffd761f749ebbaaa2326759a", - ".straymark/templates/charter/charter-template.md": "02c08051a159fd3497d1a61d130235b4a96c51ade47e0b5c05661bfc0dcb5c78", - ".straymark/03-implementation/NIST-AI-600-1-GENAI-RISKS.md": "39925646e8f493e4086b19c478cef32c703bb303192316c2f287837b21fb52fe", - ".straymark/07-ai-audit/agent-logs/gnome/AILOG-2026-02-05-001-implement-mock-dbus-daemon.md": "a868e337e700b02021c392f050b72e5d8d0a46140027ced2d8cff898746bbdae", - ".straymark/templates/i18n/zh-CN/TEMPLATE-AILABEL.md": "c60d8b9cfff6732928c85e1db1cf81ffc3f5cac006865bf5f454db152281d4d9", - ".straymark/00-governance/i18n/zh-CN/CHARTER-CHAIN-EVOLUTION.md": "aaf80f8276e6c80d9b2138660512afbca7b9253562dfbb8b58496780e75c592d", - ".straymark/templates/charter/i18n/zh-CN/charter-template.md": "af740d28384519220f74a08642c95454b22ea4342bfa8d23176676ab499e666c", - ".straymark/templates/i18n/es/TEMPLATE-DPIA.md": "7690eefdb6a1592fe4d642f6242cdf7ad2a651c403e175c0282abdf3459b362b", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-002-create-usecase-layer.md": "ecf05eff05f0c52ff20891e7af0445d270dfe0366445457118a23b8add4faaf0", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-04-003-create-fuse-migration.md": "dc0c02cdc91f7051820cb4570e6ed2c7830ba85009555db506cc0fc3baac59d8", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-05-31-001-fase-2-fuse-functional-hardening-t101.md": "6731fdb3073f8d90e537fd5e1095ef73f9c401fdf224c90456ff8eb9504ccfb2", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-05-28-004-ci-hardening-relocate-cargo-deny.md": "ac0756d9222d351e7bf90c24f4dbc9126dae77ca32052c4af0f703a32d5efe3a", + ".straymark/00-governance/AI-GOVERNANCE-POLICY.md": "9d3218cbc810ac82e173b47ec01d260e8e0944080fb9d34bc6e655988d3c52bf", ".straymark/07-ai-audit/agent-logs/gnome/AILOG-2026-02-05-005-implement-preferences-panel.md": "d0fd4aef2193c74218f351c0f0ded30ae36cb79f6a34e98649d4ac4c34c514b2", + ".straymark/audits/CHARTER-01/report-gemini-3-1-pro-high.md": "3bd2738d6da093d38a76d5b9b7b9f9408986f6033103b4cc58da4148785df3aa", + ".straymark/07-ai-audit/agent-logs/guide/AILOG-2026-02-07-001-packaging-desktop-integration-doc.md": "55bbd1642d6b685cca51c1648a296df6e2658c44d369e37791705ea8d219808c", + ".straymark/03-implementation/i18n/zh-CN/NIST-AI-RMF-GOVERN-GUIDE.md": "d9841a73a8fbd7add3a27ca90d6af96fa43ab10e33858d501a1e0a02e9436613", + ".straymark/00-governance/SPECKIT-CHARTER-BRIDGE.md": "fc940600a27ed9a4fc6437fb1613d7f2bff6aa49285a05351afc582e705e3eeb", + ".straymark/audits/CHARTER-01/review.md": "58e43d2b8e9b0ddff65212e61a8f16528b4dfd854b7515e8a22a3686c60cb735", + ".straymark/templates/i18n/zh-CN/TEMPLATE-MCARD.md": "a44b6839f8e99b348070b11860fc72d5f7dc994d5fd0e604e5875d9653fdbabf", + ".straymark/00-governance/i18n/es/AI-KPIS.md": "a1ffca74c637f33ee57ba929390479c4f8ffce0eeab5182cc9702bdba1ddc27d", ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-07-004-complete-conflict-resolution-ui.md": "10329dabf316315d617368eb46ee07f14a0965ec17121cf063730ee1944657eb", - ".straymark/00-governance/i18n/es/CHARTER-CHAIN-EVOLUTION.md": "cb0d5271383d2664a42f87d1288796f53e62c9aba8937e9d1747bcaa9b1d04d7", - ".straymark/03-implementation/NIST-AI-RMF-MAP-GUIDE.md": "5250919126a82e6e1fcbb138d07c9cf6032dfa7b65982be2624b7301f4a1e660", - ".straymark/00-governance/i18n/es/CHINA-REGULATORY-FRAMEWORK.md": "7982f83ca64893b8b220f823178d8394ba1ede957927104eb83e7c0d8bd2728e", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-014-implement-stage8-9.md": "664f667253110953082cdc18c7011fbde7eb257f7806ca2aa9c2f100faac0e5a", - ".straymark/templates/i18n/zh-CN/TEMPLATE-INC.md": "10d572b5ee347c79e5dc4d135fada22662f0b1a7e7fd245126f0cb89a2b4d2ca", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-21-001-fix-conflicts-resolve-test.md": "ae433c4ca688391d5ce7a2964181fd977db4500e134848af1c413a6b41a019e4", - ".straymark/00-governance/i18n/es/AI-LIFECYCLE-TRACKER.md": "6c45520beed409bf59dbf496ce30be3ff02dcb870290dd40649383799d74fee5", - ".straymark/00-governance/i18n/zh-CN/FOLLOW-UPS-BACKLOG-PATTERN.md": "9475b696d5b68c970b533d3b8ca897fe8ec0aa46fa30aa2023711d44138aae61", - ".straymark/00-governance/i18n/es/GIT-BRANCHING-STRATEGY.md": "e2d0b91577d5a3df99858c5df25cfd76a887e46b7a6cf40058df50ab3b9475db", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-008-implement-sync-engine-graph-provider.md": "46d22e85c068ff9603e7e3308f5787cc97edd34116fda654c3d64cfe068c084c", ".straymark/00-governance/POLISH-CHARTER-PATTERN.md": "834c5dd9521d71f499c3a5be70eaef486a7669072619314bf321a76775cfa0f2", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-006-implement-fuse-metadata-ops.md": "7da0129bed0f895de0f5da8add2cc1a1a2fc83d1489708c040f88b361d893409", - ".straymark/00-governance/i18n/zh-CN/OBSERVABILITY-GUIDE.md": "13754aef4f75e8325acc7cc00e94fc29177ae5b6ded163bab1796bdab25f3511", - ".straymark/templates/i18n/es/TEMPLATE-TC260RA.md": "04f1daad1f11b39586b2fc59e7c3738b67471cf445f7124e477ebab91e0185f7", - ".straymark/templates/TEMPLATE-ADR.md": "8f5fda2aa1a029b2f0280f34d4cbb4e7240422fd18a91c41670a745bd2046011", - ".straymark/audits/CHARTER-01/audit-prompt.md": "a9853714885b340d7f8c55a36a56b6d1e42bf2ea614bfd2f8355697a878bf020", - ".straymark/00-governance/CHARTER-CHAIN-EVOLUTION.md": "e0993158ac0285753ddd06ee64aff1cf5dd3da89ca14ccad493e6533541a1ee6", + ".straymark/03-implementation/i18n/es/NIST-AI-RMF-GOVERN-GUIDE.md": "88381cca102901e983194404d5445d4696b73dbaf641a6128b205af6b0286984", + ".straymark/00-governance/i18n/es/POLISH-CHARTER-PATTERN.md": "2d9c28cb3912b10c0c7102935c9f9691d7a5be2c55043a17eedae9dd9c00e727", + ".straymark/00-governance/i18n/zh-CN/AGENT-RULES.md": "921d47490122219e1d4eea77abfd8afdf9f99aa69c8767ad6099aa1710f39b95", + ".straymark/02-design/risk-analysis/TRACE-risks-mitigations.md": "e05a24584c0591f4a4dcc6c1720fefd5747aad0116a7667ab1d564c9ee7e89d4", + ".straymark/00-governance/i18n/es/OBSERVABILITY-GUIDE.md": "b1198fc690eaba122b246a6951743edd9fd1d91f095a4369c0a6a13c21848eee", + ".straymark/00-governance/i18n/zh-CN/CHINA-REGULATORY-FRAMEWORK.md": "15d663444b13880b2fec9bec7242a461469fbc29a2e868469dc0c1342dd8d3d1", + ".straymark/03-implementation/NIST-AI-RMF-MEASURE-GUIDE.md": "0b2c5e6704b0aa51abebd4982ac739466a0949424204ba4929055b8a7a351423", + ".straymark/00-governance/i18n/es/C4-DIAGRAM-GUIDE.md": "8fb39129741c67e389051e0615ebf6b15c35ffa69dfc7ae2c89b884fe186f707", ".straymark/03-implementation/i18n/zh-CN/NIST-AI-600-1-GENAI-RISKS.md": "f6fe254f84622ada39e2537c5ff088f54cf07ab2402a3779b7aa2371ba250ad0", + ".straymark/04-testing/.gitkeep": "1d8198124b57687ba4120fc888f855ffa707c93113d54d3c46c77f5152bd430f", + ".straymark/06-evolution/technical-debt/TDE-2026-05-28-001-workspace-rustfmt-debt.md": "2eaa6f18a62ac4c7cf09f32842ec0c128b49b083c4bfa70ea7b7f11e654f9aaa", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-002-create-usecase-layer.md": "ecf05eff05f0c52ff20891e7af0445d270dfe0366445457118a23b8add4faaf0", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-017-verify-functional-requirements.md": "0ac54abf025c44b6f2812442296196e977a45df817c408c620b44df9f9e11fd2", + ".straymark/07-ai-audit/decisions/AIDEC-2026-05-28-001-yaml-parser-serde-norway.md": "d32f0b6b7c156a2fdb48ef3e088f7ab46711ce616c9ccfed1564358ae52b9fdd", + ".straymark/00-governance/DOCUMENTATION-POLICY.md": "23cc81654e4b57e0baf7ff47b4eac47a793b327e784f521df61428c9a44f3124", + ".straymark/03-implementation/NIST-AI-RMF-GOVERN-GUIDE.md": "32f32b1f90ad83ab117ecbc134b869301004af85f8426ec84164447780b30752", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-009-implement-stage4-hydration.md": "c95b52155c47d3d8ca2250e357a16ee5cc63ed86f5043c8a8dfe9704e8b4b96c", + ".straymark/audit-prompts/i18n/es/audit-prompt.md": "2ef095a7e15e70ae2a23e53fc62b0444835c18aebbf5616bcfc2d3425e60c8ce", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-20-002-mvp-closure-block-4-distribution-infra.md": "ac063bbe14abe81a37e9c74ed69073c69cc4eed2d765299a3ad252791599af97", + ".straymark/templates/TEMPLATE-PIPIA.md": "420c38163c61bfc04fd6909218fa44b5b94a33c63a9d9e4cc24185eb0e489ba5", + ".straymark/templates/i18n/es/TEMPLATE-PIPIA.md": "7560a634a0484fcb16192146d617812cc1048204ffd761f749ebbaaa2326759a", + ".straymark/templates/TEMPLATE-AILOG.md": "9ab5eb8131285dbf37fdd7fb92d0376bfb99cf506432f562c3c490ea96ce4135", ".straymark/templates/i18n/zh-CN/TEMPLATE-AILOG.md": "8411505375160f85d107bb24ae5052e29dd2e6fbe12c3b929334e1653573fe87", - ".straymark/audits/CHARTER-01/external-audit-pending.yaml": "c7e7d705900236f7eab6ea27437d6e7d29d094a2a2c678f4da9163d0d7a30f39", - ".straymark/07-ai-audit/ethical-reviews/ETH-2026-05-29-001-oauth-token-keyring-handling.md": "5d1f2cb144f510a98b2d5e8f93f6cb955efcb71add08f506f606f41e7f975819", - ".straymark/00-governance/i18n/zh-CN/EMERGENT-OBSERVATION-DESIGN.md": "ceecf73cf0ed531ac4cde8f76bb5cf009affdf74d230c75f790cc9ac09f28e66", - ".straymark/00-governance/GB-45438-LABELING-GUIDE.md": "cf0b61ccb9672a5d7c0d681d972e32bb029cb029117205ce9831b11ec5adda67", - ".straymark/02-design/risk-analysis/RISK-003-data-integrity.md": "d9b05bc8d84aeeff710ea9fb8ad73cb8d5bf5a05c6ad55fa2b403ba4a46a4c26", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-007-implement-fuse-directory-ops.md": "e572d7352813ea95f80ba4b559f5c61b78fcbf92c219d4cdfaf94698a014c353", - ".straymark/templates/TEMPLATE-TES.md": "ac97cf9426d3ce9808b35c1bae75f02a6a3fe0653401864161ba878a74460112", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-003-implement-sqlite-repository.md": "2174f5df2b1df09baefca438924dddffda40aca34b3cd9dec4f61c48c2ed735b", + ".straymark/templates/i18n/zh-CN/TEMPLATE-TC260RA.md": "4440a8b052a00e3ced4894a6860b67f4642a8bf02b1fc0ad2855c00f3c5ffdaa", + ".straymark/QUICK-REFERENCE.md": "e15baf1d03c35e20aff5ceb0e667fb33f2a98590b5e2b39b47bec019f3db8905", + ".straymark/templates/i18n/zh-CN/TEMPLATE-TDE.md": "3c76d7dceb9ab04269af2f2cfaf4e87d34569093ec8bf76232f5788db6285ac9", + ".straymark/02-design/diagrams/SEQ-004-conflict-resolution.puml": "a0b642d8421ca3151eca5ffa868c87abb6e2720d0a1ed54fae2f6d301e30a6f8", + ".straymark/templates/i18n/es/TEMPLATE-TES.md": "5243b4cad67e626c0446aab7b16e9a04d837c14e37d60eab09f71b5ba59b059c", + ".straymark/00-governance/i18n/es/GIT-BRANCHING-STRATEGY.md": "e2d0b91577d5a3df99858c5df25cfd76a887e46b7a6cf40058df50ab3b9475db", + ".straymark/00-governance/i18n/es/PIPL-PIPIA-GUIDE.md": "1eaba2df6eff107f7126b7ef990110615eabf57dd139f87981c95040525c5909", + ".straymark/00-governance/CAC-FILING-GUIDE.md": "e8eb5997947eda98a529673b1a33c67d5c7045bee691e2785a17487eaf5e1259", + ".straymark/00-governance/i18n/es/PRINCIPLES.md": "e4a36aa9dde25d24644fc1b4cbb7352ab087ced6c1a58be8b16d934b2ec17556", + ".straymark/00-governance/i18n/zh-CN/AI-LIFECYCLE-TRACKER.md": "342be350dd7a7bc7135b081b91064c1fabafcc0bff6b40d762b90d0add050fa3", + ".straymark/03-implementation/.gitkeep": "6f47b5c66f0e61dc78e4e57f7a4d858336bdc3866f3a26a397f3e2a1869810c0", + ".straymark/05-operations/incidents/.gitkeep": "a0face4379a29d0f518afeb57eb4a1e6f1b6025d38ca02b06ee0fac6febfdfdc", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-014-implement-stage8-9.md": "664f667253110953082cdc18c7011fbde7eb257f7806ca2aa9c2f100faac0e5a", + ".straymark/templates/charter/charter-template.md": "02c08051a159fd3497d1a61d130235b4a96c51ade47e0b5c05661bfc0dcb5c78", ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-011-implement-fuse-rename.md": "9a7b5bd02331d6b5e766ef64da7810ca4ffc6d1b8a7ec1a332deaea4e027bdd0", - ".straymark/02-design/risk-analysis/BACKLOG-simulation-issues.md": "6f2c63971c5f5c75ee286d46e84709a69efc979b567a3e2744d7e2c9ede7c541", - ".straymark/schemas/audit-output.schema.v0.json": "4c8d857b7ac77a64056dacaba4bbbe86a3a80ccac087797ae5527e18febfa28a", - ".straymark/00-governance/AI-RISK-CATALOG.md": "586411737da2936d9728855bbeacf0baba163b7afccbbf091495e95ab341097e", - ".straymark/00-governance/i18n/es/AI-GOVERNANCE-POLICY.md": "95bbda3ae9825b40b09173774e14a37b54b6c4838208b8a3bca00b3e9fe524c1", - ".straymark/templates/TEMPLATE-TDE.md": "87a95beebe0f46c853650e3a49fb7e4d32a1b2cb1a663599431b2c10bd0be7d1", - ".straymark/schemas/charter-telemetry.schema.v0.json": "fc5c784ddf4f36c3ece03a970fcd24b7789d0e3686e635a2cebbd6f606a6ece3", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-015-implement-stage10-polish.md": "9ac1d61de3c142b38dae285775eb9ad50cdf1c08993f006f5d88e50c1d80bc6e", - ".straymark/02-design/diagrams/SEQ-003-delta-token-expiry.puml": "37b9ab48f382167b4991335a957055ce923c320ab80354d9b80e5a97015f5d4c", - ".straymark/00-governance/i18n/zh-CN/MANAGEMENT-REVIEW-TEMPLATE.md": "50edbc0de0c2f1096432ea4330acad2b909a0408d3ee011581185dcbb83678f1", - ".straymark/00-governance/i18n/es/AI-KPIS.md": "a1ffca74c637f33ee57ba929390479c4f8ffce0eeab5182cc9702bdba1ddc27d", - ".straymark/03-implementation/NIST-AI-RMF-MANAGE-GUIDE.md": "dc336008b7e8af796b0698e9f6f9561ffa64659d1315611ae0d7106dd9408c2e", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-007-implement-graph-delta-api.md": "8a595e91291633c853f0139563d3b63053a1bea8d351d119e65a7dadff440e08", - ".straymark/03-implementation/NIST-AI-RMF-MEASURE-GUIDE.md": "0b2c5e6704b0aa51abebd4982ac739466a0949424204ba4929055b8a7a351423", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-05-29-002-mitigate-risk-002-oauth-keyring-session-handle.md": "e2ba03354c2a84b4cef5c49a50bf08909e9d3c280052cb9f9ff5d22cc6d9e12b", - ".straymark/07-ai-audit/agent-logs/gnome/AILOG-2026-02-05-004-implement-onboarding-wizard-scaffold.md": "8f383be930e8ed98dffe341a30eb41f0c0e1b607f6a20ff5f4f9d84fe9660518", - ".straymark/02-design/decisions/.gitkeep": "d268c27da8232243534ae5dbcbfc52629f1112c2bfc018462a41fbe1a233b164", - ".straymark/07-ai-audit/agent-logs/gnome/AILOG-2026-02-22-001-fix-nautilus-icon-colors-and-invalidation.md": "ffd28e1491b06307b274ba0daa893fa5ff620d288b5f39d0a41a84bc87655cab", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-05-28-002-mitigate-risk-001-dbus-health-monitor.md": "501690cbaedd7ffc17a8ef7633acc5dc1cf72f8c576c129d54649524664cce8a", - ".straymark/audit-prompts/audit-prompt.md": "714ef62051f407ae609350b2ce06e6d153f62c61c0c21819ad92106083f61493", + ".straymark/00-governance/i18n/zh-CN/SPECKIT-CHARTER-BRIDGE.md": "86c8325c1edb5874ef4e4f4d60f93707a413217b46c1c87b48aa1b49c940ada7", + ".straymark/templates/i18n/es/TEMPLATE-INC.md": "85c72cfcdf8ffe1a90654fbb92e9617ae039945ca6b400a326ae93a0eca460bd", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-005-implement-cli-auth-commands-output.md": "ca7c60d2013079dcb1afdc4dc8f163306e295ec15f46ff4c311a77f5789ace34", ".straymark/03-implementation/i18n/es/NIST-AI-RMF-MANAGE-GUIDE.md": "19251b01178286bc5c48baa70797d7b9f00954d8f838aedd05a1cf3c56eb0048", - ".straymark/07-ai-audit/agent-logs/guide/AILOG-2026-05-28-001-devtrail-to-straymark-rename.md": "3050b4341ae7d36873164915823b437de627f9e00dae38621029cea35a336ef4", - ".straymark/07-ai-audit/agent-logs/guide/AILOG-2026-02-07-001-packaging-desktop-integration-doc.md": "55bbd1642d6b685cca51c1648a296df6e2658c44d369e37791705ea8d219808c", + ".straymark/templates/i18n/zh-CN/TEMPLATE-SBOM.md": "0c0294b3981ea6fa21357aaf619a3117b607b87e1b814386566c7ed0e03f34b1", + ".straymark/00-governance/i18n/zh-CN/AI-GOVERNANCE-POLICY.md": "e82bcd63f0146cb66d3beb35a39d3604a2ca43461eeb2873606096bbd684f00f", + ".straymark/00-governance/i18n/zh-CN/CAC-FILING-GUIDE.md": "64342c55cd989eda5572671f3b5002868427eec018babe4d191e8ce1e255f0c9", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-002-add-inodetable-tests.md": "82fb982b5c2e4570b1671356e26e5ba3cf3d1571bf0319f74ec5de03799b9148", + ".straymark/00-governance/i18n/es/TC260-IMPLEMENTATION-GUIDE.md": "ec6a617388a5ebbdc2d7821c4193ba876131e007c8713d75f483df8b36a971f6", + ".straymark/02-design/risk-analysis/RISK-001-critical-paths.md": "f5d093dcb0c0119479e67128f55af3a512bae4b660a0bf03a53c4c83e90d3629", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-006-implement-graph-auth-client.md": "6cbb22ecbdf24525e5e3e56e30cfbc2726a0bf239e0048b2db0ae5dd6335d22a", + ".straymark/schemas/audit-output.schema.v0.json": "4c8d857b7ac77a64056dacaba4bbbe86a3a80ccac087797ae5527e18febfa28a", + ".straymark/02-design/risk-analysis/RISK-002-security-vulns.md": "58dd6eaff6da1c6b46088972b89d378901b89726808311d6a032b32f6e3f16be", ".straymark/06-evolution/technical-debt/TDE-2026-05-29-001-graphclient-tokensource-trait.md": "c050413629354a1b0a30036c2344ebc5ca4fe84efb623a0ddaaf22eecb6f3016", - ".straymark/audits/CHARTER-01/report-gpt-5-2-codex-fase-1.md": "fc26a430c42cb9c91bf7ca8b92d7164d10c62772c65b82d566f9060472cbb3e3", - ".straymark/templates/i18n/es/TEMPLATE-AIDEC.md": "bb8beb96d469feb7ee75b51c7e4fb224207d2732de372fcd3c6070d0a119b72c", - ".straymark/00-governance/i18n/zh-CN/TC260-IMPLEMENTATION-GUIDE.md": "fbcf0f709084fc2b0729b5c040d8e440f13a412c9594cba4bfe0c246e8e410bc", - ".straymark/00-governance/i18n/zh-CN/AI-RISK-CATALOG.md": "7c62918f40b04c4e15749199b845916fa46c80a1eb217a482b5409880d2d9fb0", - ".straymark/01-requirements/.gitkeep": "b87527d29d1ec75b950d6b5fcdac2063a5426486c2cabee43841e1fb2780190c", - ".straymark/03-implementation/i18n/zh-CN/NIST-AI-RMF-GOVERN-GUIDE.md": "d9841a73a8fbd7add3a27ca90d6af96fa43ab10e33858d501a1e0a02e9436613", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-07-001-implement-files-dbus-interface.md": "d781b5a2395cfd4bd0562b5bffb22a74436d420d3092c99a0fd9b7a7814892ff", - ".straymark/00-governance/MANAGEMENT-REVIEW-TEMPLATE.md": "2c789489a83c2def1c869c344186fbac5d1ba9c18f431e32711e740a2f0246b3", - ".straymark/00-governance/i18n/es/OBSERVABILITY-GUIDE.md": "b1198fc690eaba122b246a6951743edd9fd1d91f095a4369c0a6a13c21848eee", - ".straymark/templates/i18n/zh-CN/TEMPLATE-AIDEC.md": "3bd1649c19e6f56d085b003799609ee2594da47f91da9aa9ec62842e789daad8", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-009-implement-cli-sync-command.md": "519a1a1459585e8e1c480990997425599b81ade201728150778e146f86bdefab", - "STRAYMARK.md": "5292db4e6825523a33cd407bf3c0a1cd25738e4e285cd6fedc7959ad6b32e913", + ".straymark/02-design/diagrams/SEQ-001-fuse-hydration-race.puml": "55184dabe4dea6224aa379c065d3cf25183bb5041d7e5662877f5b291bb89203", + ".straymark/07-ai-audit/agent-logs/gnome/AILOG-2026-02-05-006-stage8-polish-cross-cutting.md": "35a901680df1c968741f00d662a86d2baa9d0210b215477e3f5e8f392e1053cf", ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-012-implement-stage7-dehydration.md": "dd30347b4bf3f3a5ba5d2967a44265acf3f564918b41b67d525bf8c5b9aa9ed1", - ".straymark/03-implementation/.gitkeep": "6f47b5c66f0e61dc78e4e57f7a4d858336bdc3866f3a26a397f3e2a1869810c0", - ".straymark/07-ai-audit/decisions/AIDEC-2026-05-31-001-defer-system-settings-group.md": "73482d85d561478c583d0f91d1235dd2a4b0c2ad56ff764915447a359b3567b3", + ".straymark/00-governance/i18n/es/AI-LIFECYCLE-TRACKER.md": "6c45520beed409bf59dbf496ce30be3ff02dcb870290dd40649383799d74fee5", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-04-002-complete-phases-0-1.md": "d6f4e6302846aa39f670bb8f1375c2e88244585a043ef23f09b40531bde25180", + ".straymark/00-governance/i18n/zh-CN/POLISH-CHARTER-PATTERN.md": "50bb0c37ca27179414448eabf9c304ddcb93b09ca2200326a311577f2c22a55d", + ".straymark/00-governance/i18n/zh-CN/C4-DIAGRAM-GUIDE.md": "f625e0587df12d52a0029b90918687e067fe1e0218d59e1559b9a7b990fa727f", + ".straymark/03-implementation/i18n/zh-CN/NIST-AI-RMF-MANAGE-GUIDE.md": "2a2d6c099ab1afa7da9afc612bfe601d1ae046155ccd93c89a95e28afa4ae674", + ".straymark/00-governance/i18n/es/CHARTER-CHAIN-EVOLUTION.md": "cb0d5271383d2664a42f87d1288796f53e62c9aba8937e9d1747bcaa9b1d04d7", + ".straymark/00-governance/i18n/es/AI-RISK-CATALOG.md": "03fd6b95a2917b6fb16f31e7622be34fd2d77ae23e35b47b67c6b86a0aa4be3b", + ".straymark/.checksums.json": "5dac6b8985eb1bff3a7dfcea949fd0560b01a7eeea373b648d7a8f2353c6b6f7", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-04-001-implement-container-functional-testing.md": "a2fe201dc937b18e2faac088c0000ad1c7c96867c9dbf3b3d0f82fc265e596cd", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-001-implement-sync-item-entity.md": "d5cbfc604dc623ccecebe9e5190b857a9a70bf8525007e6da464fef9a29102d0", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-004-implement-cli-mount-commands.md": "6fec43ed94bbd9a6af97b18cfd9c1ecf4d0a9df87387217c120b49d2919805c1", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-05-31-001-fase-2-fuse-functional-hardening-t101.md": "6731fdb3073f8d90e537fd5e1095ef73f9c401fdf224c90456ff8eb9504ccfb2", + ".straymark/08-security/.gitkeep": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", + ".straymark/00-governance/i18n/zh-CN/FOLLOW-UPS-BACKLOG-PATTERN.md": "3df3feefb780750aeb4a8149bca318232bc2f6bb16476c6594d4c236f2d6f4cf", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-007-implement-fuse-directory-ops.md": "e572d7352813ea95f80ba4b559f5c61b78fcbf92c219d4cdfaf94698a014c353", + ".straymark/00-governance/i18n/zh-CN/CHARTER-CHAIN-EVOLUTION.md": "aaf80f8276e6c80d9b2138660512afbca7b9253562dfbb8b58496780e75c592d", + ".straymark/07-ai-audit/agent-logs/gnome/AILOG-2026-02-05-004-implement-onboarding-wizard-scaffold.md": "8f383be930e8ed98dffe341a30eb41f0c0e1b607f6a20ff5f4f9d84fe9660518", + ".straymark/09-ai-models/.gitkeep": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-005-implement-lnxdrivefs-struct.md": "9a85cf9a96e8a69684e728ac8ab1d2f13e75e95fee41426a56c4fd07dca4197b", + ".straymark/00-governance/i18n/zh-CN/ISO-25010-2023-REFERENCE.md": "0007111673a3901cd0ef8e7c182be853cdb3d2b9b5e8e87d7cca71bbb2479d7e", + ".straymark/00-governance/CHARTER-CHAIN-EVOLUTION.md": "e0993158ac0285753ddd06ee64aff1cf5dd3da89ca14ccad493e6533541a1ee6", ".straymark/00-governance/i18n/zh-CN/AI-KPIS.md": "5be08376dcc7ec4406216762350b72dac7ed765ddbc334bd5c4504171db50ca5", - ".straymark/00-governance/PIPL-PIPIA-GUIDE.md": "d5525118b2a96f199594b6970de1435167b8d376fbda06c01000d5d569c8e4f3", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-003-implement-sqlite-repository.md": "2174f5df2b1df09baefca438924dddffda40aca34b3cd9dec4f61c48c2ed735b", + ".straymark/00-governance/TC260-IMPLEMENTATION-GUIDE.md": "b872176b2c69024c64d8642aa495e98c92ed0c06cb4d1b38bea3aaa141bd785e", + ".straymark/07-ai-audit/agent-logs/guide/AILOG-2026-05-28-001-devtrail-to-straymark-rename.md": "3050b4341ae7d36873164915823b437de627f9e00dae38621029cea35a336ef4", ".straymark/06-evolution/technical-debt/TDE-2026-05-28-002-deferred-dependency-advisories.md": "716e04207c6214d54f14eb0e754d11f86baf32e24d7e153d9275d80d16f1f2b7", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-05-28-003-mitigate-issue-002-yaml-billion-laughs.md": "132a88866c6b5164145338114008c2c8acdc7bcabab74576d233904bd1e7efee", + ".straymark/templates/TEMPLATE-ETH.md": "768e6e32d3f83158fa81816c646e05810042adbcd3d007907007a1cf777c0ca8", + ".straymark/07-ai-audit/agent-logs/gnome/AILOG-2026-02-05-002-implement-gnome-shell-extension.md": "be1ccf4ff28f1d5f13be0a4e6bd56f4dfa8a5f0457547524042a689462fc0613", + ".straymark/07-ai-audit/agent-logs/gnome/AILOG-2026-02-20-001-mvp-closure-dbus-bus-name-unification.md": "4fbe0f3a7fe2bf294850a3eb24778e0cc96845c7da9e9f8c7a24285b122c5d50", ".straymark/00-governance/i18n/es/EMERGENT-OBSERVATION-DESIGN.md": "985adb71bcf52f12d2bc7b7a9d901de5594ccbcb3db7bc348c489a9266325fc3", - ".straymark/07-ai-audit/agent-logs/gnome/AILOG-2026-02-05-006-stage8-polish-cross-cutting.md": "35a901680df1c968741f00d662a86d2baa9d0210b215477e3f5e8f392e1053cf", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-011-implement-phases-5-11.md": "a2eed62fca07eb4282b227addf6654f7602fe71c3ab17d39157472e3622f6fc8", - ".straymark/schemas/charter.schema.v0.json": "8088aed6bdf2fd2c0baf080f3f3cbc72c97c9fad59e6767b476541f6bb97c625", - ".straymark/templates/i18n/zh-CN/TEMPLATE-TDE.md": "3c76d7dceb9ab04269af2f2cfaf4e87d34569093ec8bf76232f5788db6285ac9", - ".straymark/hooks/pre-pr.sh": "dcc25301efc70123e9afdfa33a7de175a45abc3edd72eb1ff6cb414ad92b83df", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-017-verify-functional-requirements.md": "0ac54abf025c44b6f2812442296196e977a45df817c408c620b44df9f9e11fd2", - ".straymark/00-governance/i18n/zh-CN/CHINA-REGULATORY-FRAMEWORK.md": "15d663444b13880b2fec9bec7242a461469fbc29a2e868469dc0c1342dd8d3d1", - ".straymark/03-implementation/i18n/es/NIST-AI-600-1-GENAI-RISKS.md": "302b05589fd548b637166ecbeaa4c63c2ac563b7cfa8b78c20123cd3b51504b7", - ".straymark/03-implementation/i18n/zh-CN/NIST-AI-RMF-MEASURE-GUIDE.md": "2465b6bc4750b1c61d8fdd321dd1ad10c94fad8e65094e2e74f2c745b344157b", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-009-implement-stage4-hydration.md": "c95b52155c47d3d8ca2250e357a16ee5cc63ed86f5043c8a8dfe9704e8b4b96c", - ".straymark/audits/CHARTER-01/external-audit-pending-fase-1.yaml": "de6569fb7a7018fa0479ed45c62f7cc74902423db28c66b2167628bdf9f473ae", - ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-011-implement-stage6-pin-unpin.md": "40fc5dd022dc5344c9ace70194c683827a56c438f5f15652bc44160ce588b1fa", - ".straymark/02-design/risk-analysis/RISK-002-security-vulns.md": "58dd6eaff6da1c6b46088972b89d378901b89726808311d6a032b32f6e3f16be", - ".straymark/07-ai-audit/decisions/AIDEC-2026-02-02-001-sqlite-bundled-vs-system.md": "3518c0c14ced1fc516b2e5e02625f1a2856200bf2bc8deb1385ad19e61e47a09", - ".straymark/00-governance/GIT-BRANCHING-STRATEGY.md": "ca165418e42a396c66edf801fa71fc5da3add903c8c2ee35da706928d2194728", - ".straymark/00-governance/i18n/zh-CN/PRINCIPLES.md": "87cb90343b8b17c738bab44b2e356c22416f82a984a0901330df297bc45df68e", + ".straymark/templates/TEMPLATE-MCARD.md": "f72567856ab5f78129a03695f6976dd8cfbb64ef6974b3a5c671123732f19ca3", ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-07-003-complete-shell-extension-session3.md": "c1a3694a169fbbdbeee0b092c6ed7512431cfc63f54474e58d1f8152580d85e6", + ".straymark/audits/CHARTER-01/external-audit-pending.yaml": "c7e7d705900236f7eab6ea27437d6e7d29d094a2a2c678f4da9163d0d7a30f39", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-05-28-004-ci-hardening-relocate-cargo-deny.md": "ac0756d9222d351e7bf90c24f4dbc9126dae77ca32052c4af0f703a32d5efe3a", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-008-implement-sync-engine-graph-provider.md": "46d22e85c068ff9603e7e3308f5787cc97edd34116fda654c3d64cfe068c084c", ".straymark/templates/i18n/es/TEMPLATE-TDE.md": "322c2d861cfeb080ccc75a4728825502754282cc1c23e37ca4afdf4f0bd98503", - ".straymark/00-governance/i18n/zh-CN/C4-DIAGRAM-GUIDE.md": "e6dc05b533324f80791fffce5e95514b5ca3aece60b9b3e1d7ae70fa017b2161", - ".straymark/templates/i18n/zh-CN/TEMPLATE-ADR.md": "0382b299ee60dea18cee148026f4cefb953738a7b5ee3a6f18f1f14c78d7031a", - ".straymark/templates/TEMPLATE-SEC.md": "233afc81358b9b9aabad8634b50b4a8577d6eec0e2393cfad14af7a4a3cac380", - ".straymark/03-implementation/NIST-AI-RMF-GOVERN-GUIDE.md": "32f32b1f90ad83ab117ecbc134b869301004af85f8426ec84164447780b30752", - ".straymark/templates/TEMPLATE-PIPIA.md": "420c38163c61bfc04fd6909218fa44b5b94a33c63a9d9e4cc24185eb0e489ba5", - ".straymark/audits/CHARTER-01/upstream-feedback-drafts.md": "0c3a4b0512b0607af7178f797b5408f95cd1ff081150e23408697c06f9961b0e", + ".straymark/00-governance/i18n/es/CHINA-REGULATORY-FRAMEWORK.md": "7982f83ca64893b8b220f823178d8394ba1ede957927104eb83e7c0d8bd2728e", + ".straymark/audits/CHARTER-01/review-fase-1.md": "a7bf7099f46f934324062b55987a2a382801c6d45d43f07a3572834c87124b2c", + ".straymark/templates/charter/charter-telemetry-template.yaml": "1f22bfd50b1d581699818c09cd3d8ca6873c3dbea148af29a6d1522698c4a4b6", + ".straymark/00-governance/GIT-BRANCHING-STRATEGY.md": "ca165418e42a396c66edf801fa71fc5da3add903c8c2ee35da706928d2194728", + ".straymark/00-governance/i18n/zh-CN/DOCUMENTATION-POLICY.md": "0d194877ca092940c70f087caa6af0430645aa5dc11338eee6545427c71bf282", + ".straymark/schemas/charter-telemetry.schema.v0.json": "fc5c784ddf4f36c3ece03a970fcd24b7789d0e3686e635a2cebbd6f606a6ece3", + ".straymark/templates/TEMPLATE-INC.md": "1c7c35e1c1124b0b3511b78ba73ae6f6ee16e671b41e3f541f1f68cf37aff2ba", + ".straymark/templates/TEMPLATE-AIDEC.md": "169119a5e9e386817cba67778c6f3201390bcb0c5120aab2e77aea44f3e39b10", + ".straymark/07-ai-audit/agent-logs/gnome/AILOG-2026-02-07-001-implement-conflict-resolution-ui.md": "3ff8ef2260fe283370e154dd2dec252da6938bba04889be7c4a4ed0c701d0c5b", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-001-implement-inode-entry.md": "6937c62c4adbb1b887f0b46d0108a13e1d6d6410768e339ad43bd264356e5696", ".straymark/07-ai-audit/ethical-reviews/.gitkeep": "a300a8f3c231fbb98a5e04e3165ef8b3f4fe5af9cc7f77467c26244194ce0d45", + ".straymark/00-governance/MANAGEMENT-REVIEW-TEMPLATE.md": "2c789489a83c2def1c869c344186fbac5d1ba9c18f431e32711e740a2f0246b3", + ".straymark/00-governance/GB-45438-LABELING-GUIDE.md": "cf0b61ccb9672a5d7c0d681d972e32bb029cb029117205ce9831b11ec5adda67", + ".straymark/templates/i18n/zh-CN/TEMPLATE-REQ.md": "12b88923720af80f77910699fedfe80d798131612fe824a592d93334c03169f7", + ".straymark/00-governance/i18n/zh-CN/AI-RISK-CATALOG.md": "7c62918f40b04c4e15749199b845916fa46c80a1eb217a482b5409880d2d9fb0", + ".straymark/00-governance/i18n/zh-CN/EMERGENT-OBSERVATION-DESIGN.md": "ceecf73cf0ed531ac4cde8f76bb5cf009affdf74d230c75f790cc9ac09f28e66", + ".straymark/00-governance/i18n/zh-CN/GIT-BRANCHING-STRATEGY.md": "8c3c3b1815fcc15a8a8608bc791135da00b39f6a28028dd66a5aad630f58c9a3", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-07-002-implement-sync-status-auth-settings-manager-interfaces.md": "85c4267646d9d9f14888a48a09203d5e77d29af2ee9f5e0e7d3849b4b88b795a", + ".straymark/00-governance/EMERGENT-OBSERVATION-DESIGN.md": "c59c56086e9e1175114a5cbc40f3658744ab6421eb5b872c9f5b85266d9f1727", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-20-001-mvp-closure-blocks-1-3-daemon.md": "a574b2ea4ab5ddfbb67ead8cb0cc7802bbc74128d2253e2cf83331551fc33e98", + ".straymark/00-governance/C4-DIAGRAM-GUIDE.md": "f052a858f04639bb85db472115f827f5236911d9332e2cbcae8087652b7a5cf2", + ".straymark/templates/TEMPLATE-AILABEL.md": "bd80dc0e46b29b035fed3a6fa072d8d6b10bf4e9a9c2143a456177b6495f05ae", + ".straymark/02-design/diagrams/SEQ-002-dbus-recovery.puml": "15075011fd301f28fb3b37b2df835f1db25c092537b94aa62681db83ff811bb8", + ".straymark/templates/TEMPLATE-TDE.md": "87a95beebe0f46c853650e3a49fb7e4d32a1b2cb1a663599431b2c10bd0be7d1", + ".straymark/00-governance/CHINA-REGULATORY-FRAMEWORK.md": "206be07ad39be89f30ab21e6ba63b54291935132cbd5acbc4ff376f2986a01fb", + ".straymark/00-governance/i18n/es/AGENT-RULES.md": "d18d04c7dffd01e2574228e3b9f8ffdb1d1ff61c3cca52274c5fd228bc290607", + ".straymark/audits/CHARTER-01/report-gpt-5-2-codex.md": "da314e05715c543e6d8bc975efd580e2a5b83dfb283412f13343e5b99372741d", + ".straymark/00-governance/QUICK-REFERENCE.md": "a413a17db3d2eb402d6becc58ed25006d40c255494a16b0ff4b8e655f6867f77", + ".straymark/07-ai-audit/agent-logs/gnome/AILOG-2026-03-17-001-implement-goa-provider.md": "e37835325af5b923804aa9d315c77b4c7926a7d1c6f8e9d6a3b31641109f4499", + ".straymark/00-governance/ISO-25010-2023-REFERENCE.md": "28641b79cef89279abb6ce8bf00fae3b909524965920828b7517a80dc22a3dd0", + ".straymark/00-governance/AGENT-RULES.md": "ee4e8d9d6519427300889155d08cb9604967aa352258df897e754d7bcbb1750f", + ".straymark/07-ai-audit/agent-logs/guide/AILOG-2026-05-29-001-roadmap-v0-1-0-alpha-foundation.md": "60b8c0887790bdcab0d3159b2f197c03d8363e7a299673206673cd0c6d4e4b1f", + ".straymark/07-ai-audit/decisions/AIDEC-2026-02-02-001-sqlite-bundled-vs-system.md": "3518c0c14ced1fc516b2e5e02625f1a2856200bf2bc8deb1385ad19e61e47a09", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-016-implement-t086-dehydration-lifecycle.md": "7769261dd4b6c8a9a836bf71eaf358089176e29531492bae6ca5ca0acf2b46b7", + ".straymark/templates/i18n/es/TEMPLATE-MCARD.md": "cc4b9587b03e5a400e024f012932de8f1ff6bf1deef5e86f58e5bd1a9310893f", + ".straymark/00-governance/AI-KPIS.md": "ff87081ff4155ddc2fa8c706521d1d23ec4287a5254918f7c77be074d00d09e2", + ".straymark/03-implementation/i18n/es/NIST-AI-600-1-GENAI-RISKS.md": "302b05589fd548b637166ecbeaa4c63c2ac563b7cfa8b78c20123cd3b51504b7", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-07-001-implement-files-dbus-interface.md": "d781b5a2395cfd4bd0562b5bffb22a74436d420d3092c99a0fd9b7a7814892ff", ".straymark/00-governance/AI-LIFECYCLE-TRACKER.md": "39267295031e2ad3b1470bdb591b0c0ab8ae39f26524dcc01d7264bf15e704c2", - ".straymark/07-ai-audit/agent-logs/gnome/AILOG-2026-02-20-001-mvp-closure-dbus-bus-name-unification.md": "4fbe0f3a7fe2bf294850a3eb24778e0cc96845c7da9e9f8c7a24285b122c5d50", - ".straymark/QUICK-REFERENCE.md": "e15baf1d03c35e20aff5ceb0e667fb33f2a98590b5e2b39b47bec019f3db8905", - ".straymark/.checksums.json": "8ea15e7445230722b7bc20387b8e9380831fbd71c0863a593aa0464a0467cb07", + ".straymark/00-governance/PIPL-PIPIA-GUIDE.md": "d5525118b2a96f199594b6970de1435167b8d376fbda06c01000d5d569c8e4f3", + ".straymark/templates/charter/i18n/es/charter-template.md": "6adec14c9ae797002638d05d7a76d089f6575db085143f5a2703649c45bbc972", + ".straymark/06-evolution/technical-debt/.gitkeep": "a1e8aa0b06407e59dee1a6f3f52e47a6044aeca3fcc2a2108c853cb775428a6a", + ".straymark/01-requirements/.gitkeep": "b87527d29d1ec75b950d6b5fcdac2063a5426486c2cabee43841e1fb2780190c", + ".straymark/templates/i18n/es/TEMPLATE-SEC.md": "2371394f9f8863adfa571baae9abc2a33c451775a995c40f3e2cac256630b04f", + ".straymark/00-governance/i18n/zh-CN/PIPL-PIPIA-GUIDE.md": "ea36b2fb28167a2991059430fdb5941f65df78a1857779c843dd399ea014de0b", + ".straymark/03-implementation/i18n/es/NIST-AI-RMF-MAP-GUIDE.md": "7147d6e6bcc57b188984f8f532904c545c74c19883947127ca7b03d7b957e28c", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-010-implement-stage5-write-operations.md": "17c99a39b87aa1310c3c4d42172a45af364a190140e77e2afadb77d32bfa206f", + ".straymark/hooks/pre-pr.sh": "dcc25301efc70123e9afdfa33a7de175a45abc3edd72eb1ff6cb414ad92b83df", + ".straymark/templates/i18n/es/TEMPLATE-DPIA.md": "7690eefdb6a1592fe4d642f6242cdf7ad2a651c403e175c0282abdf3459b362b", + ".straymark/templates/i18n/zh-CN/TEMPLATE-TES.md": "8e0537b8c3fa9883c235d5e8a8ff9a825deea193be4ecd85e78cc7b28d4220e3", + ".straymark/02-design/diagrams/SEQ-005-state-machine-transitions.puml": "b2ad6645e71d839b7017e0505062228db2725d4af39c4c8a1029457add0c44bb", + ".straymark/templates/i18n/zh-CN/TEMPLATE-ETH.md": "dc53846625e4e10f6f6026bc51a3a10969fd664f5147fc3923b7e448da644cff", + ".straymark/templates/TEMPLATE-REQ.md": "736eda155f48484c437a3754055ebf9d8705d9bbc00af43a6a9d5ec9216a31c4", + ".straymark/02-design/risk-analysis/RISK-003-data-integrity.md": "d9b05bc8d84aeeff710ea9fb8ad73cb8d5bf5a05c6ad55fa2b403ba4a46a4c26", + ".straymark/00-governance/i18n/es/FOLLOW-UPS-BACKLOG-PATTERN.md": "47c3f6a611729a6caf09d04fe2bf47a78baef0eeca68bb30691cf97d9289642c", + ".straymark/templates/TEMPLATE-TC260RA.md": "8c0ef4be7a9c9811d3c3dee8262270cc5d3501c88cb1c798f8d7f4038429df71", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-03-011-implement-phases-5-11.md": "a2eed62fca07eb4282b227addf6654f7602fe71c3ab17d39157472e3622f6fc8", + ".straymark/audits/CHARTER-01/audit-prompt-fase-1.md": "a3406d73e4583df58b2b8d65c4e09c7a5c66e46f341b865320629e09344c55c4", ".straymark/07-ai-audit/decisions/.gitkeep": "c7c86a6c44e638da00088beeca6797a11ecdd84dafbaae6210905cc86a13486f", - ".straymark/templates/i18n/es/TEMPLATE-ADR.md": "a1c654bd1a999f5e874c59ddc406179cb1f4ada98bec606355197bcba19c468a", - ".straymark/dist-manifest.yml": "7019cc0e3239413a783e014ba0dab54f81beeb35a6cc444a98099ad02a33f361" + ".straymark/00-governance/i18n/es/AI-GOVERNANCE-POLICY.md": "95bbda3ae9825b40b09173774e14a37b54b6c4838208b8a3bca00b3e9fe524c1", + ".straymark/02-design/decisions/.gitkeep": "d268c27da8232243534ae5dbcbfc52629f1112c2bfc018462a41fbe1a233b164", + ".straymark/00-governance/i18n/zh-CN/PRINCIPLES.md": "87cb90343b8b17c738bab44b2e356c22416f82a984a0901330df297bc45df68e", + ".straymark/07-ai-audit/agent-logs/gnome/AILOG-2026-02-05-003-implement-nautilus-extension.md": "c9361e884623f9e6a85e8c04a200c87e80352d17a4e847c399ccfe5aeb985dc4", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-21-001-fix-conflicts-resolve-test.md": "ae433c4ca688391d5ce7a2964181fd977db4500e134848af1c413a6b41a019e4", + ".straymark/00-governance/i18n/es/ISO-25010-2023-REFERENCE.md": "d702e5ea546486beb935e2bc49d221d9bc9bdc2228906833ded15bf5b602d9c0", + ".straymark/templates/TEMPLATE-TES.md": "ac97cf9426d3ce9808b35c1bae75f02a6a3fe0653401864161ba878a74460112", + ".straymark/00-governance/AI-RISK-CATALOG.md": "586411737da2936d9728855bbeacf0baba163b7afccbbf091495e95ab341097e", + ".straymark/00-governance/i18n/es/GB-45438-LABELING-GUIDE.md": "8e447687d00e3dfb9c07498e673b4f62207a749fb244d2f5e36551014bf8643e", + ".straymark/templates/charter/i18n/zh-CN/charter-template.md": "af740d28384519220f74a08642c95454b22ea4342bfa8d23176676ab499e666c", + ".straymark/audits/CHARTER-01/report-gpt-5-2-codex-fase-1.md": "fc26a430c42cb9c91bf7ca8b92d7164d10c62772c65b82d566f9060472cbb3e3", + ".straymark/07-ai-audit/agent-logs/daemon/AILOG-2026-02-05-011-implement-stage6-pin-unpin.md": "40fc5dd022dc5344c9ace70194c683827a56c438f5f15652bc44160ce588b1fa" } } \ No newline at end of file diff --git a/.straymark/00-governance/AGENT-RULES.md b/.straymark/00-governance/AGENT-RULES.md index acf9089..2cda7be 100644 --- a/.straymark/00-governance/AGENT-RULES.md +++ b/.straymark/00-governance/AGENT-RULES.md @@ -381,10 +381,34 @@ These are heuristics, not rigid rules — you are close to the context, refine t --- +## 13. Follow-ups Backlog (registry maintenance) + +When the project maintains the central follow-ups registry (`.straymark/follow-ups-backlog.md` — see [`FOLLOW-UPS-BACKLOG-PATTERN.md`](FOLLOW-UPS-BACKLOG-PATTERN.md) and `STRAYMARK.md §16`), the agent is its **primary maintainer**. Three directives: + +### Session start + +Glance at `.straymark/follow-ups-backlog.md` (or run `straymark followups status`) to know what is pending across the project. When the operator asks *"what's pending?"* / *"what follow-ups do we have?"*, **the registry is the canonical source** — answer from it (`straymark followups list`), not by re-scanning AILOGs. Only fall back to an AILOG scan when the registry does not exist or `followups drift` reports unextracted AILOGs. + +### Pre-commit + +Created or modified any AILOG with `## Follow-ups` or `R (new, not in Charter)` entries? → run `straymark followups drift --apply` so the registry extension rides **the same commit** as the AILOG. Entries the AILOG text already marks as resolved in-Charter are extracted as `suspected-closed` automatically — do not delete them; the operator confirms at the next triage. + +### Post-Charter close + +Review the registry entries the just-closed Charter resolved: + +- Mark them `closed` (with the closing Charter id in `Notes`) or `superseded`. +- Confirm or reopen any `suspected-closed` entries that the Charter's AILOGs produced. +- For un-resolved entries that meet the TDE criteria of §3 (heritage, transversal, dedicated Charter, human prioritization), propose promotion via `straymark followups promote FU-NNN` — promotion itself is operator-approved, per the autonomy limits of §3. + +Counters in the registry frontmatter (`total_open`, …) are **CLI-owned**: never edit them by hand; every write command recomputes them. + +--- + ## Patterns -When a project accumulates a high volume of AILOGs across multiple Charters and follow-ups become hard to track, see [FOLLOW-UPS-BACKLOG-PATTERN.md](FOLLOW-UPS-BACKLOG-PATTERN.md) for a reproducible convention (central registry + drift detection script + agent integration). Adopters at ~20+ AILOGs benefit; below that threshold the per-AILOG `§Follow-ups` convention alone is sufficient. +When a project accumulates a high volume of AILOGs across multiple Charters and follow-ups become hard to track, see [FOLLOW-UPS-BACKLOG-PATTERN.md](FOLLOW-UPS-BACKLOG-PATTERN.md) — a **first-class registry since fw-4.21.0 / cli-3.19.0** (central registry + native `straymark followups` CLI + the §13 directives above). Adopters at ~20+ AILOGs benefit; below that threshold the per-AILOG `§Follow-ups` convention alone is sufficient. --- -*StrayMark fw-4.20.0 | [Strange Days Tech](https://strangedays.tech)* +*StrayMark fw-4.22.0 | [Strange Days Tech](https://strangedays.tech)* diff --git a/.straymark/00-governance/C4-DIAGRAM-GUIDE.md b/.straymark/00-governance/C4-DIAGRAM-GUIDE.md index e21abeb..85defe8 100644 --- a/.straymark/00-governance/C4-DIAGRAM-GUIDE.md +++ b/.straymark/00-governance/C4-DIAGRAM-GUIDE.md @@ -234,4 +234,4 @@ Use a Level 1 (Context) diagram to illustrate: --- -*StrayMark fw-4.20.0 | [Strange Days Tech](https://strangedays.tech)* +*StrayMark fw-4.22.0 | [Strange Days Tech](https://strangedays.tech)* diff --git a/.straymark/00-governance/DOCUMENTATION-POLICY.md b/.straymark/00-governance/DOCUMENTATION-POLICY.md index 2f511fd..a991c06 100644 --- a/.straymark/00-governance/DOCUMENTATION-POLICY.md +++ b/.straymark/00-governance/DOCUMENTATION-POLICY.md @@ -260,6 +260,7 @@ For documents that require multiple reviewers (e.g., ETH with both legal and eng │ └── ethical-reviews/ # ETH ├── 08-security/ # SEC — Security assessments ├── 09-ai-models/ # MCARD — Model/System cards +├── follow-ups-backlog.md # Follow-ups registry (first-class, CLI-owned counters — not a doc type; see FOLLOW-UPS-BACKLOG-PATTERN.md) └── templates/ # Templates ``` @@ -318,4 +319,4 @@ See also [ADR-2025-01-20-001] for architectural context. --- -*StrayMark fw-4.20.0 | [Strange Days Tech](https://strangedays.tech)* +*StrayMark fw-4.22.0 | [Strange Days Tech](https://strangedays.tech)* diff --git a/.straymark/00-governance/FOLLOW-UPS-BACKLOG-PATTERN.md b/.straymark/00-governance/FOLLOW-UPS-BACKLOG-PATTERN.md index 0d9702d..cd2e85b 100644 --- a/.straymark/00-governance/FOLLOW-UPS-BACKLOG-PATTERN.md +++ b/.straymark/00-governance/FOLLOW-UPS-BACKLOG-PATTERN.md @@ -1,6 +1,6 @@ # Follow-ups Backlog Pattern - StrayMark -> Reproducible convention for managing accumulated `§Follow-ups` and `R (new, not in Charter)` entries across many AILOGs and Charters. +> First-class registry for managing accumulated `§Follow-ups` and `R (new, not in Charter)` entries across many AILOGs and Charters. **Languages**: English | [Español](i18n/es/FOLLOW-UPS-BACKLOG-PATTERN.md) | [简体中文](i18n/zh-CN/FOLLOW-UPS-BACKLOG-PATTERN.md) @@ -8,9 +8,17 @@ ## Status -**v0 — proven in N=1 domain** (`StrangeDaysTech/sentinel` CHARTER-12, 2026-05-06). +**v1 — first-class entity since fw-4.21.0 / cli-3.19.0** (experimental; hard stabilization gated on a second adopter, per design principle #12 and ADR-2026-06-03-001). -This is a **convention**, not a CLI feature. Adopters reproduce it locally with markdown + a portable bash script. The pattern may evolve into a `straymark followups` subcommand once a second adopter validates it (see [Open questions](#open-questions)). +Maturation chronology, mirroring the Charter lane: + +| Stage | Release | What landed | +|-------|---------|-------------| +| Convention (v0) | fw-4.10.0 | Pattern doc + adopter-side bash script (Sentinel CHARTER-12, N=47) | +| Refinement (v0.1) | fw-4.13.1 | FU → TDE promotion path (2 shapes), `total_promoted` counter | +| **First-class (v1)** | **fw-4.21.0 / cli-3.19.0** | JSON schema, native `straymark followups` CLI, `explore`/`status` integration, agent directives shipped in `AGENT-RULES.md §13`, registry template | + +The registry is a **first-class artifact** like Charter — not one of the 16 document types. It has its own canonical path, its own schema, its own CLI namespace, and its own synthetic group in the `explore` TUI. --- @@ -27,6 +35,10 @@ Adopt this pattern when **any** of these conditions hold: Below that volume, the per-AILOG convention alone is sufficient — adopting this pattern early adds maintenance overhead without payoff. +### The registry as planning input + +Empirical lesson from the reference adopter (issue #214, N=91 entries): the backlog is more than a list of deferred chores. Follow-ups originate not only from planning (ex-ante) but from **execution reality** — test runs, telemetry readings, staging incidents, bugs observed in real (non-simulated) environments — and they feed planning back: they become chores, mini-charters, or even reshape Charters that were already planned. The registry is the **ex-post counterpart of SpecKit**: SpecKit feeds planning from intent; the backlog feeds it from execution. The v1 dimensions (`Origin-class`, `Severity`, `Labels`, the `Destination` vocabulary) exist to make that planning loop queryable. + --- ## Shape @@ -39,17 +51,20 @@ Single markdown file at the canonical path: .straymark/follow-ups-backlog.md ``` +A template with empty frontmatter and the five bucket headers ships at `.straymark/templates/follow-ups-backlog.md`. + ### Frontmatter (YAML) ```yaml --- -last_scan: 2026-05-06 +last_scan: 2026-06-03 last_scan_range: AILOG-NNNN-NN-NN-NNN..AILOG-NNNN-NN-NN-NNN # optional — first..last AILOG covered -schema_version: v0 -total_open: 0 # count of entries currently `open` -total_promoted: 0 # count of entries currently `promoted` (added in schema v0.1 — see "Promotion to TDE") -total_closed_in_session: 0 # count of `closed` entries since last session (optional, operator-maintained) -total_phase_blocked: 0 # count of `phase-blocked` entries (optional) +schema_version: v1 +total_open: 0 # CLI-owned — recomputed on every write +total_promoted: 0 # CLI-owned +total_closed_in_session: 0 # CLI-owned +total_phase_blocked: 0 # CLI-owned +total_suspected_closed: 0 # CLI-owned (new in v1) buckets: - ready - time-triggered @@ -63,13 +78,15 @@ fully_extracted_ailogs: --- ``` -The `total_*` counters are **operator-maintained metadata**. The drift script doesn't update them automatically — they live in the header so a session-start glance shows the registry's pulse without scrolling through buckets. `total_promoted` was canonicalized in schema v0.1 (Sentinel adopter empirical signal, fw-4.13.1) to mirror the existing `total_open` / `total_closed_in_session` / `total_phase_blocked` pattern. +**The `total_*` counters are CLI-owned since v1.** Every write command (`straymark followups drift --apply`, `straymark followups promote`) recomputes them from the actual entry statuses. Do not maintain them by hand — stale hand-edited values are corrected on the next write. This closes the silent counter-drift failure mode observed at N=91 (declared `total_open: 47` vs 65 real after 4 weeks — issue #214 Signal 2). `straymark followups status` always shows counts recomputed on the fly, so the pulse is trustworthy even if the file is stale. The `fully_extracted_ailogs` list is the **load-bearing metadata** for drift detection. Every AILOG whose `§Follow-ups` and `R` entries have been transferred into the registry (or explicitly classified as superseded) belongs in this list. Drift detection compares this list against AILOGs that have follow-up content in the repo. +The formal frontmatter schema is `.straymark/schemas/follow-ups-backlog.schema.v1.json` (experimental v1 — see Status above). + ### Buckets -Five buckets organize entries by trigger type: +Five buckets organize entries by trigger type — *when actionable*: - `ready` — actionable now, no dependency on external trigger. - `time-triggered` — calendar-based trigger (audit cycle, periodic review). @@ -77,27 +94,40 @@ Five buckets organize entries by trigger type: - `phase-blocked` — gated on a future component or phase that does not yet exist. - `operational` — manual operator decision or external system action. -### Entry schema +The vocabulary is stable at N=91 entries in the reference adopter — no sixth bucket has been needed. Severity (*how much it hurts to skip*) is intentionally **not** a bucket: it is an orthogonal per-entry field (see below). + +### Entry schema (v1) -Each entry inside a bucket follows this shape: +Each entry inside a bucket follows this shape (v1 fields marked; all of them optional — v0 entries remain valid): ```markdown ### FU-NNN — - **Origin**: AILOG-NNNN-NN-NN-NNN -- **Status**: open | in-progress | closed | superseded | promoted +- **Origin-class**: ex-ante-planning | testing | telemetry | staging | real-env-bug (v1, optional) +- **Status**: open | in-progress | suspected-closed | closed | superseded | promoted +- **Severity**: normal | blocking (v1, optional; default normal) - **Trigger**: ready | | when | -- **Destination**: +- **Destination**: chore | mini-charter | charter-replanning | operations | | - **Cost**: +- **Labels**: (v1, optional) - **Notes**: - **Promoted to**: ``` `FU-NNN` is monotonically increasing across the registry's lifetime; do not renumber when entries close. +**The v1 dimensions**, each canonicalizing an empirically observed need (issue #214): + +- **`Origin-class`** — where the entry was born: planning artifacts (ex-ante) vs execution reality (testing, telemetry, staging, real-environment bugs). Makes the ex-post planning loop queryable. +- **`Severity`** — `blocking` marks reliability-class issues that must land before a production cutover. Canonicalizes the `PROD-BLOCKER` prose convention that emerged in the reference adopter's `Notes` field (Signal 3). Orthogonal to the bucket: a `charter-triggered` entry can be `blocking`. +- **`Labels`** — free tags for grouping entries into planned Charters / mini-charters / chores during triage. Queryable via `straymark followups list --label `. +- **`Destination` vocabulary** — formalizes where the work lands when triggered: `chore`, `mini-charter`, `charter-replanning` (the entry reshapes an already-planned Charter rather than adding a task to it), `operations`, a specific Charter id, or a TDE id. Free-form values remain accepted (lenient parsing). + ### Status vocabulary - `open` — pending, not yet acted on. - `in-progress` — a Charter has been declared or is executing that addresses this entry. +- `suspected-closed` *(new in v1)* — auto-extracted by `drift --apply` from an AILOG whose text carries an explicit closure marker (`closed in-Charter`, `fixed in batch N`, a commit hash). The operator confirms (→ `closed`) or reopens (→ `open`) at the next triage. See "Drift detection" below. - `closed` — entry resolved (Charter merged, operational task done, time elapsed and reviewed). - `superseded` — addressed by other work that did not reference this entry directly. - `promoted` — the entry was elevated to a TDE document because it met the transversal-debt criteria (see "Promotion to TDE" below). The `Promoted to:` field carries the TDE id. @@ -117,20 +147,26 @@ Some FU entries are not just deferred tasks — they describe **transversal tech When any of these holds, promote the FU entry to a TDE document under `.straymark/06-evolution/technical-debt/`: -1. Create the TDE via `/straymark-new tde` (or `straymark new --type tde`). Fill `impact`, `effort`, `type`, and the body sections from the FU entry's context. -2. Add `promoted_from_followup: FU-NNN` to the TDE frontmatter for traceability. -3. In the FU entry, set `Status: promoted`, set `Destination: TDE-YYYY-MM-DD-NNN`, and add `Promoted to: TDE-YYYY-MM-DD-NNN`. Move the entry to the `## Bucket: closed` section if you maintain one; otherwise leave it in place with the new status. +```bash +straymark followups promote FU-NNN +``` + +The command automates the three-step flow that was manual in v0: + +1. Creates the TDE document (same machinery as `straymark new --type tde`), pre-filling `impact`, `effort`, `type`, and body context from the FU entry. +2. Adds `promoted_from_followup: FU-NNN` to the TDE frontmatter for traceability. +3. In the FU entry, sets `Status: promoted`, `Destination: TDE-YYYY-MM-DD-NNN`, and `Promoted to: TDE-YYYY-MM-DD-NNN`; recomputes the frontmatter counters. The FU entry is **not deleted** after promotion — its presence in the registry is the audit trail showing where the TDE came from. ### Two promotion shapes — promotion-of-existing vs retroactive-at-creation -The workflow above covers the **standard case**: an `open` FU entry already exists in the registry and gets elevated to a TDE during periodic review. There is a second case that is equally valid and that emerged empirically from the Sentinel CHARTER-13 retrospective: +The flow above covers the **standard case**: an `open` FU entry already exists in the registry and gets elevated to a TDE during periodic review. There is a second case that is equally valid and that emerged empirically from the Sentinel CHARTER-13 retrospective: -- **Promotion of existing entry** — an FU was registered (typically via `--apply`) as `open` weeks or Charters ago, lived through ≥1 Charter close without resolution, and meets the four criteria above. Standard flow. +- **Promotion of existing entry** — an FU was registered (typically via `drift --apply`) as `open` weeks or Charters ago, lived through ≥1 Charter close without resolution, and meets the four criteria above. Standard flow. - **Retroactive promotion at creation** — the debt is recognized as TDE-worthy *during* a retrospective (Charter close ceremony, audit cycle, RFC writeup) and never existed as an `open` FU. The TDE is created first; an FU entry is added to the registry *with `Status: promoted`* from birth, providing the audit trail back from the TDE to the originating context (an `R` in an AILOG, a calibrator finding, a deferred classification). -Both shapes produce the same end state in the registry: an entry with `Status: promoted` and a `Promoted to: TDE-YYYY-MM-DD-NNN` pointer. The difference is whether the entry pre-existed as `open` or was born `promoted`. The drift script treats them identically (it doesn't differentiate by birth status), and adopter analytics counting `total_promoted` get the same number either way. +Both shapes produce the same end state in the registry: an entry with `Status: promoted` and a `Promoted to: TDE-YYYY-MM-DD-NNN` pointer. The difference is whether the entry pre-existed as `open` or was born `promoted`. Drift detection treats them identically, and analytics counting `total_promoted` get the same number either way. When in doubt, prefer creating the FU entry — even retroactively — because it cross-references the TDE back to the AILOG / R-number / source context that triggered the recognition. A TDE with `promoted_from_followup: FU-NNN` pointing to an entry that exists in the backlog is more navigable than one pointing to a fictional FU. @@ -140,52 +176,62 @@ When in doubt, prefer creating the FU entry — even retroactively — because i - **Charter close** — when reviewing entries the just-closed Charter resolved, if you find entries that were *not* resolved and meet the criteria above, promote them rather than leaving them as `open`. - **Pre-Charter declaration** — if you're about to declare a Charter and notice the registry contains entries that this Charter would *partially* address, the un-addressed portion may belong as a TDE rather than as another deferred FU. -The drift script (`scripts/check-followups-drift.sh`) is **not extended** for promotion candidates in v0 — promotion is operator-driven. A future v1 enhancement could flag entries meeting the "lived through ≥2 Charters" heuristic, but that crystallizes after a second adopter validates the pattern (same gate as the rest of v0 → v1). - --- -## Drift detection +## Drift detection — native since cli-3.19.0 + +Drift detection keeps the registry in sync with new AILOGs. Since cli-3.19.0 it is a **native CLI command** — no external script: -A small bash script is the verification layer that keeps the registry in sync with new AILOGs. The script lives in the adopter's repo (suggested path: `scripts/check-followups-drift.sh`) and has three modes. +```bash +straymark followups drift # scan AILOGs changed in git diff origin/main..HEAD (fallback HEAD~1..HEAD); exit 1 on drift +straymark followups drift --apply # same scan + extract new entries into the registry +straymark followups drift --scan-all # periodic full sweep over every AILOG +``` -### Modes +### What `--apply` does -- **Default** — scan AILOGs modified in `git diff origin/main..HEAD` (with `HEAD~1..HEAD` fallback). Warn on any AILOG with `§Follow-ups` / `R (new)` content that is not in `fully_extracted_ailogs`. Exit 1 on drift. -- **`--apply`** — same scan, but auto-append new entries under `## Bucket: ready` with auto-generated `FU-NNN` ids and append the AILOG id to `fully_extracted_ailogs`. The operator reclassifies into the correct bucket later. -- **`--scan-all`** — scan every AILOG in the project (periodic full sweep). +1. Extracts every `§Follow-ups` bullet and `R (new, not in Charter)` risk from AILOGs not yet in `fully_extracted_ailogs`, appending them under `## Bucket: ready` with auto-numbered `FU-NNN` ids. The operator reclassifies bucket/trigger/destination at the next triage. +2. **Anti-noise refinement** *(v1 — resolves issue #214 Signal 1)*: bullets whose AILOG text carries an explicit closure marker (`closed in-Charter`, `fixed in batch N`, a commit hash reference) are extracted with `Status: suspected-closed` instead of `open`, instead of polluting the `ready` bucket as TBD noise. Across both documented occurrences in the reference adopter, 20–75% of auto-appended entries per batch were already resolved in-Charter — this refinement removes the single recurring cost of the v0 workflow. +3. Appends the AILOG id to `fully_extracted_ailogs`. +4. **Recomputes all `total_*` counters** from actual entry statuses (Signal 2). +5. If the registry is `schema_version: v0`, upgrades it to `v1` in place — non-destructively and idempotently (all v1 fields are optional; nothing is rewritten except the version marker and the counters). ### Per-AILOG vs per-bullet granularity -Tracking is **per-AILOG**, not per-bullet. An AILOG is either fully extracted (its id is in `fully_extracted_ailogs` — trust the registry) or it is not (extract everything). Per-bullet matching would require fingerprinting (text hashing or fuzzy comparison), which produces false positives whenever a registry entry paraphrases the AILOG bullet — and curated entries always paraphrase. +Tracking is **per-AILOG**, not per-bullet. An AILOG is either fully extracted (its id is in `fully_extracted_ailogs` — trust the registry) or it is not (extract everything). Per-bullet matching would require fingerprinting (text hashing or fuzzy comparison), which produces false positives whenever a registry entry paraphrases the AILOG bullet — and curated entries always paraphrase. This design choice is empirically validated: **0 false positives across 76 AILOGs and ~10 apply runs** in the reference adopter. -The cost of per-AILOG granularity: when a follow-up is added to an already-extracted AILOG post-Charter close, drift detection misses it. The remediation is operator-driven — manually remove the AILOG from `fully_extracted_ailogs` and re-run with `--apply`. This trade-off is intentional for v0 because most AILOGs are write-once after Charter close. +The cost of per-AILOG granularity: when a follow-up is added to an already-extracted AILOG post-Charter close, drift detection misses it. The remediation is operator-driven — manually remove the AILOG from `fully_extracted_ailogs` and re-run with `--apply`. This trade-off is intentional because most AILOGs are write-once after Charter close. -### Script template +### Legacy bash script (deprecated) + +The v0 reference implementation (`scripts/check-followups-drift.sh`, ~296 lines of POSIX bash in the Sentinel adopter's repo) is **deprecated as of cli-3.19.0**. It keeps working for v0 registries but is no longer maintained and lacks the anti-noise refinement and counter recompute. Migration path: delete the script, run `straymark followups drift --apply` once (this also upgrades the registry to v1), and update any pre-commit hook to call the CLI instead. + +--- -A reference implementation (~290 lines of POSIX bash) is in `StrangeDaysTech/sentinel` at `scripts/check-followups-drift.sh`. Copy it into your repo and adjust the constants at the top: +## CLI surface ```bash -BACKLOG_FILE=".straymark/follow-ups-backlog.md" -AILOG_DIR=".straymark/07-ai-audit/agent-logs" +straymark followups list # enumerate entries: FU id, status, severity, bucket, destination +straymark followups list --bucket ready --status open --severity blocking --label +straymark followups status # registry pulse: counters (recomputed on the fly), per-bucket/severity breakdown +straymark followups status FU-NNN # detail view of one entry +straymark followups drift [--apply|--scan-all] # drift detection (see above) +straymark followups promote FU-NNN # automate FU → TDE promotion (see above) ``` -The script uses `awk` and `grep` only — no jq, no yq, no heavyweight dependencies. Portable across Linux and macOS. +The registry also appears as a synthetic **Follow-ups** group in the `straymark explore` TUI (sub-nodes per bucket) and as a counts block in `straymark status`. --- ## Agent integration -The agent (Claude / Gemini / etc.) becomes the primary maintainer of the registry. Add to your `CLAUDE.md` / `AGENT.md`: +Since fw-4.21.0 the agent directives **ship with the framework** in [`AGENT-RULES.md §13`](AGENT-RULES.md) — adopters no longer copy a block into their own `CLAUDE.md` / `AGENT.md`. In summary: -```markdown -## Follow-ups backlog - -- **Session start**: glance at `.straymark/follow-ups-backlog.md` to know what is pending across the project. -- **Pre-commit checklist**: created or modified any AILOG with `## Follow-ups` or `R (new, not in Charter)` entries? → run `scripts/check-followups-drift.sh --apply` to extend the backlog in the same commit. -- **Post-Charter close**: review entries the Charter resolved; mark them `closed` (with the closing Charter id in `Notes`) or `superseded`. For un-resolved entries that meet the TDE criteria (heritage from prior Charter, transversal, requires dedicated Charter, needs human prioritization), promote them to a TDE document (see "Promotion to TDE" in this pattern + `AGENT-RULES.md §3`). -``` +- **Session start**: glance at `.straymark/follow-ups-backlog.md` (or run `straymark followups status`) to know what is pending across the project. +- **Pre-commit**: created or modified any AILOG with `## Follow-ups` or `R (new, not in Charter)` entries? → run `straymark followups drift --apply` in the same commit. +- **Post-Charter close**: review entries the Charter resolved; mark them `closed` (with the closing Charter id in `Notes`) or `superseded`; confirm or reopen any `suspected-closed` entries; promote un-resolved entries that meet the TDE criteria via `straymark followups promote`. -This makes the agent the maintainer, the script the verification layer, and the operator the periodic reviewer (re-bucketing, marking closed, pruning superseded, promoting to TDE when criteria apply). +This makes the agent the registry's primary maintainer, the CLI the verification layer, and the operator the periodic reviewer (re-bucketing, confirming suspected-closed, pruning superseded, promoting to TDE when criteria apply). --- @@ -193,45 +239,46 @@ This makes the agent the maintainer, the script the verification layer, and the For an adopter starting fresh: -1. Create `.straymark/follow-ups-backlog.md` with the frontmatter above (empty `fully_extracted_ailogs:` list initially) and the five `## Bucket: ` headers. -2. Copy the reference script from `StrangeDaysTech/sentinel` to `scripts/check-followups-drift.sh`. Adjust `AILOG_DIR` if your AILOGs live elsewhere. -3. Run `scripts/check-followups-drift.sh --scan-all --apply` to seed the registry from existing AILOGs. -4. Reclassify the auto-generated `## Bucket: ready` entries into the correct buckets manually. This is one-time triage, typically 30-60 min for a backlog of ~50 entries. -5. Add the agent integration block to `CLAUDE.md` / `AGENT.md`. -6. Optionally wire `scripts/check-followups-drift.sh` into a pre-commit hook for hard enforcement. +1. Copy `.straymark/templates/follow-ups-backlog.md` to `.straymark/follow-ups-backlog.md` (empty `fully_extracted_ailogs:` list, five `## Bucket:` headers). +2. Run `straymark followups drift --scan-all --apply` to seed the registry from existing AILOGs. +3. Reclassify the auto-generated `## Bucket: ready` entries into the correct buckets manually; fill `Origin-class`/`Severity`/`Labels` where they add signal. This is one-time triage, typically 30-60 min for a backlog of ~50 entries. +4. Done — the agent directives in `AGENT-RULES.md §13` are already active; no `CLAUDE.md` edits needed. -For an adopter migrating from ad-hoc tracking: the same flow, but step 4 may require deciding which entries are already `closed` or `superseded` — that classification is what makes the registry useful. +For an adopter migrating from the v0 convention: run `straymark followups drift --apply` once (auto-upgrades the registry to v1), delete the local bash script, and update any pre-commit hook to call the CLI. --- ## Reference implementation -`StrangeDaysTech/sentinel` CHARTER-12, merged 2026-05-06: +`StrangeDaysTech/sentinel` — the originating adopter: -- Implementation PR: [sentinel#53](https://github.com/StrangeDaysTech/sentinel/pull/53) (registry + script + CLAUDE.md additions). -- Close-out PR: [sentinel#54](https://github.com/StrangeDaysTech/sentinel/pull/54) (post-merge verification + Charter close). - -Empirical context: 47 entries seeded from CHARTER-08 → CHARTER-11 retrospective (~30 min of multi-agent triage). The chain demonstrated the gap that motivated the pattern — without the registry, the operator could not see "what is pending across the project" without re-classifying each Charter's follow-ups in isolation. With the registry, session-start glance is one file read. +- v0 pattern: CHARTER-12, merged 2026-05-06 ([sentinel#53](https://github.com/StrangeDaysTech/sentinel/pull/53), [sentinel#54](https://github.com/StrangeDaysTech/sentinel/pull/54)). 47 entries seeded from the CHARTER-08 → CHARTER-11 retrospective. +- Scale validation: post-Etapa-3 triage at **N=91 FUs / 76 AILOGs extracted / 65 open** ([issue #214](https://github.com/StrangeDaysTech/straymark/issues/214)) — the empirical input that drove the v1 schema and the native CLI (ADR-2026-06-03-001). --- ## Open questions -These are not resolved in v0. Future revisions of this pattern, or a CLI helper, may address them: +Resolved in v1: + +- ~~**Schema validation.**~~ → `.straymark/schemas/follow-ups-backlog.schema.v1.json` (frontmatter), entry-shape validation in the CLI parser. +- ~~**Cristalization as `straymark followups` CLI.**~~ → native `list / status / drift / promote` since cli-3.19.0. +- ~~**Bucket classification heuristic** (partially).~~ → `suspected-closed` removes the dominant noise class; full bucket suggestion (using AILOG `tags` / Charter `effort_estimate`) remains open. + +Still open for future revisions: -- **Bucket classification heuristic**. Today `--apply` dumps every new entry into `## Bucket: ready`; the operator reclassifies manually. A heuristic using AILOG `tags` and Charter `effort_estimate` could suggest a bucket automatically. -- **Schema validation**. The registry follows a tacit schema; no `.straymark/schemas/follow-ups-backlog.schema.v0.json` exists yet. Validation today is human review. -- **Integration with the audit cycle**. When `straymark charter audit --merge-reports` produces real-debt findings that are not remediated atomically pre-close, those findings live only in `.straymark/audits//review.md`. They do not auto-flow into the central registry. Surfacing them automatically would close a known gap. -- **`closed` vs `superseded` semantics**. Today the difference is whether the resolving work explicitly referenced the entry. A stricter convention may emerge. -- **Cristalization as `straymark followups` CLI**. Once a second adopter validates the pattern, the framework may ship a subcommand mirroring the existing `straymark charter` trio: `list` / `close` / `drift`. Adopters at v0 (this pattern) migrate by deleting their local script and switching the agent instruction. +- **Integration with the audit cycle.** When `straymark charter audit --merge-reports` produces real-debt findings that are not remediated atomically pre-close, those findings live only in `.straymark/audits//review.md`. They do not auto-flow into the central registry. Surfacing them automatically would close a known gap. +- **`closed` vs `superseded` semantics.** Today the difference is whether the resolving work explicitly referenced the entry. A stricter convention may emerge. +- **Soft integration with `charter close`** (issue #135 Tier 3): auto-invoking `followups drift --apply` after a Charter close, with an interactive promotion prompt. Gated on a friction signal from a second adopter. +- **Hard schema stabilization (v1.0).** Gated on validation by a second adopter in another domain, per design principle #12. --- ## Credits -Contributed via [issue #111](https://github.com/StrangeDaysTech/straymark/issues/111) by the Sentinel adopter. Empirical foundation: CHARTER-08 → CHARTER-11 chain in `StrangeDaysTech/sentinel`. Author: José Villaseñor Montfort. +Contributed via [issue #111](https://github.com/StrangeDaysTech/straymark/issues/111) by the Sentinel adopter; matured to first-class via [issue #214](https://github.com/StrangeDaysTech/straymark/issues/214) and ADR-2026-06-03-001. Empirical foundation: CHARTER-08 → CHARTER-11 chain and the post-Etapa-3 triage at N=91 in `StrangeDaysTech/sentinel`. Author: José Villaseñor Montfort. -*This document was produced with assistance from generative AI tools (Claude 4.7); all responsibility for the content rests with the human author.* +*This document was produced with assistance from generative AI tools (Claude 4.7 / Opus 4.8); all responsibility for the content rests with the human author.* --- @@ -239,8 +286,9 @@ Contributed via [issue #111](https://github.com/StrangeDaysTech/straymark/issues - [EMERGENT-OBSERVATION-DESIGN.md](EMERGENT-OBSERVATION-DESIGN.md) — the meta-pattern that this drift-detection convention instantiates at the per-AILOG ↔ registry surface. - [CHARTER-CHAIN-EVOLUTION.md](CHARTER-CHAIN-EVOLUTION.md) — sibling pattern that operates at chain level (Pattern 1) and cycle level (Pattern 2). -- [AGENT-RULES.md §3](AGENT-RULES.md) — TDE-vs-`R` escalation criteria that may promote follow-ups to dedicated debt entries. +- [AGENT-RULES.md §3](AGENT-RULES.md) — TDE-vs-`R` escalation criteria that may promote follow-ups to dedicated debt entries; §13 — the shipped agent directives for registry maintenance. +- `STRAYMARK.md §16` — the onboarding-level summary of the registry as a first-class artifact. --- -*StrayMark fw-4.19.0 | [Strange Days Tech](https://strangedays.tech)* +*StrayMark fw-4.22.0 | [Strange Days Tech](https://strangedays.tech)* diff --git a/.straymark/00-governance/GIT-BRANCHING-STRATEGY.md b/.straymark/00-governance/GIT-BRANCHING-STRATEGY.md old mode 100755 new mode 100644 diff --git a/.straymark/00-governance/PRINCIPLES.md b/.straymark/00-governance/PRINCIPLES.md old mode 100755 new mode 100644 diff --git a/.straymark/00-governance/QUICK-REFERENCE.md b/.straymark/00-governance/QUICK-REFERENCE.md index 933248f..94e9e44 100644 --- a/.straymark/00-governance/QUICK-REFERENCE.md +++ b/.straymark/00-governance/QUICK-REFERENCE.md @@ -76,6 +76,20 @@ Charters are **not** doc types — they wrap a multi-session implementation bloc > See section 15 of `STRAYMARK.md` and `.straymark/00-governance/SPECKIT-CHARTER-BRIDGE.md` for granularity heuristics, lifecycle, and the SpecKit ↔ Charter bridge. +### First-Class Registries — Follow-ups Backlog *(fw-4.21.0+)* + +The follow-ups backlog is **not** a doc type either — a single-file registry aggregating `§Follow-ups` / `R (new)` entries across AILOGs. Entry ids `FU-NNN`; five buckets by trigger type; statuses `open | in-progress | suspected-closed | closed | superseded | promoted`. Counters are CLI-owned. + +| Concept | File | Agent Autonomy | +|---------|------|---------------| +| `Follow-ups registry` | `.straymark/follow-ups-backlog.md` (schema: `follow-ups-backlog.schema.v1.json`, experimental) | Agent extracts via `followups drift --apply` (pre-commit); operator owns triage and promotion approval | + +```bash +straymark followups list / status / drift [--apply] / promote FU-NNN +``` + +> See section 16 of `STRAYMARK.md`, `FOLLOW-UPS-BACKLOG-PATTERN.md`, and AGENT-RULES.md §13 for the shipped agent directives. + --- ## When to Document @@ -91,6 +105,7 @@ Charters are **not** doc types — they wrap a multi-session implementation bloc | OTel instrumentation changes | AILOG + tag `observabilidad` | | Multi-session implementation block (>1 day, >5 tasks across phases) | Declare a **Charter** (`straymark charter new`) | | Transversal technical debt (heritage from prior Charter, applies to multiple modules, requires dedicated Charter, needs human prioritization) | **TDE** — distinct from per-Charter `R`; see AGENT-RULES.md §3 | +| AILOG created/modified with `## Follow-ups` or `R (new, not in Charter)` entries | `straymark followups drift --apply` in the same commit — see AGENT-RULES.md §13 | **DO NOT document**: credentials, tokens, PII, secrets. @@ -153,7 +168,8 @@ Mark `review_required: true` when: ├── 09-ai-models/ ← MCARD │ └── labeling/ ← AILABEL* ├── charters/ ← Charter (NN-slug.md + NN-slug.telemetry.yaml) -└── templates/ ← Templates (incl. charter/ subdir) +├── follow-ups-backlog.md ← Follow-ups registry (FU-NNN entries, first-class since fw-4.21.0) +└── templates/ ← Templates (incl. charter/ subdir + follow-ups-backlog.md) * Only created when regional_scope: china is enabled. ``` @@ -227,6 +243,7 @@ Mark `review_required: true` when: | `/straymark-ailog` / `/straymark-aidec` / `/straymark-adr` | Quick shortcuts for AILOG / AIDEC / ADR | | `/straymark-mcard` / `/straymark-sec` | Interactive flows for Model Card / SEC assessment | | `/straymark-charter-new` | Scaffold a Charter (declarative ex-ante work unit) | +| `/straymark-followups` *(fw-4.22.0+)* | Maintain the follow-ups backlog registry — "what's pending?", pre-commit drift, post-close triage/promote | | `/straymark-audit-prompt CHARTER-XX` *(fw-4.9.0+, refactored in fw-4.9.0)* | External multi-model audit — write unified prompt at canonical path | | `/straymark-audit-execute [CHARTER-XX]` *(fw-4.9.0+)* | Run inside an auditor CLI — read prompt, audit with tool use, write report | | `/straymark-audit-review CHARTER-XX` *(fw-4.9.0+, expanded in fw-4.9.0)* | Consolidate N reports into review.md (6 sections) + merge YAML into telemetry | @@ -237,9 +254,9 @@ Mark `review_required: true` when: | Pattern | Document | |---------|----------| -| Follow-ups backlog (central registry + drift detection) *(fw-4.10.0+)* | [FOLLOW-UPS-BACKLOG-PATTERN.md](FOLLOW-UPS-BACKLOG-PATTERN.md) | +| Follow-ups backlog (first-class registry + native `followups` CLI) *(fw-4.10.0+, first-class fw-4.21.0+)* | [FOLLOW-UPS-BACKLOG-PATTERN.md](FOLLOW-UPS-BACKLOG-PATTERN.md) | | Polish Charter as debt-detection ("surface declaration without wiring" anti-pattern) *(fw-4.18.0+)* | [POLISH-CHARTER-PATTERN.md](POLISH-CHARTER-PATTERN.md) | --- -*StrayMark fw-4.20.0 | [Strange Days Tech](https://strangedays.tech)* +*StrayMark fw-4.22.0 | [Strange Days Tech](https://strangedays.tech)* diff --git a/.straymark/00-governance/i18n/es/AGENT-RULES.md b/.straymark/00-governance/i18n/es/AGENT-RULES.md index dc1634f..2904b11 100644 --- a/.straymark/00-governance/i18n/es/AGENT-RULES.md +++ b/.straymark/00-governance/i18n/es/AGENT-RULES.md @@ -381,10 +381,34 @@ Son heurísticas, no reglas rígidas — estás cerca del contexto, afínalas co --- +## 13. Follow-ups Backlog (mantenimiento del registry) + +Cuando el proyecto mantiene el registry central de follow-ups (`.straymark/follow-ups-backlog.md` — ver [`FOLLOW-UPS-BACKLOG-PATTERN.md`](FOLLOW-UPS-BACKLOG-PATTERN.md) y `STRAYMARK.md §16`), el agente es su **mantenedor primario**. Tres directivas: + +### Session start + +Echa un vistazo a `.straymark/follow-ups-backlog.md` (o ejecuta `straymark followups status`) para saber qué está pendiente en el proyecto. Cuando el operador pregunta *"¿qué está pendiente?"* / *"¿qué follow-ups tenemos?"*, **el registry es la fuente canónica** — responde desde él (`straymark followups list`), no reescaneando AILOGs. Recurre a un escaneo de AILOGs solo cuando el registry no exista o `followups drift` reporte AILOGs sin extraer. + +### Pre-commit + +¿Creaste o modificaste algún AILOG con entradas `## Follow-ups` o `R (new, not in Charter)`? → ejecuta `straymark followups drift --apply` para que la extensión del registry viaje en **el mismo commit** que el AILOG. Las entradas que el texto del AILOG ya marca como resueltas in-Charter se extraen como `suspected-closed` automáticamente — no las elimines; el operador las confirma en el siguiente triage. + +### Post-Charter close + +Revisa las entradas del registry que el Charter recién cerrado resolvió: + +- Márcalas `closed` (con el id del Charter de cierre en `Notes`) o `superseded`. +- Confirma o reabre cualquier entrada `suspected-closed` que produjeron los AILOGs del Charter. +- Para entradas no resueltas que cumplen los criterios de TDE de §3 (herencia, transversal, Charter dedicado, priorización humana), propón la promoción vía `straymark followups promote FU-NNN` — la promoción misma es aprobada por el operador, según los límites de autonomía de §3. + +Los contadores en el frontmatter del registry (`total_open`, …) son **CLI-owned**: nunca los edites a mano; cada comando de escritura los recalcula. + +--- + ## Patrones -Cuando un proyecto acumula un volumen alto de AILOGs a lo largo de múltiples Charters y los follow-ups se vuelven difíciles de rastrear, ver [FOLLOW-UPS-BACKLOG-PATTERN.md](FOLLOW-UPS-BACKLOG-PATTERN.md) para una convención reproducible (registro central + script de detección de drift + integración con agentes). Los adopters con ~20+ AILOGs se benefician; por debajo de ese umbral la convención per-AILOG `§Follow-ups` por sí sola es suficiente. +Cuando un proyecto acumula un volumen alto de AILOGs a lo largo de múltiples Charters y los follow-ups se vuelven difíciles de rastrear, ver [FOLLOW-UPS-BACKLOG-PATTERN.md](FOLLOW-UPS-BACKLOG-PATTERN.md) — un **registry de primera clase desde fw-4.21.0 / cli-3.19.0** (registry central + CLI nativo `straymark followups` + las directivas de §13 anteriores). Los adopters con ~20+ AILOGs se benefician; por debajo de ese umbral la convención per-AILOG `§Follow-ups` por sí sola es suficiente. --- -*StrayMark fw-4.20.0 | [Strange Days Tech](https://strangedays.tech)* +*StrayMark fw-4.22.0 | [Strange Days Tech](https://strangedays.tech)* diff --git a/.straymark/00-governance/i18n/es/C4-DIAGRAM-GUIDE.md b/.straymark/00-governance/i18n/es/C4-DIAGRAM-GUIDE.md index 5ca2614..907eab1 100644 --- a/.straymark/00-governance/i18n/es/C4-DIAGRAM-GUIDE.md +++ b/.straymark/00-governance/i18n/es/C4-DIAGRAM-GUIDE.md @@ -234,4 +234,4 @@ Usar un diagrama de Nivel 1 (Contexto) para ilustrar: --- -*StrayMark fw-4.20.0 | [Strange Days Tech](https://strangedays.tech)* +*StrayMark fw-4.22.0 | [Strange Days Tech](https://strangedays.tech)* diff --git a/.straymark/00-governance/i18n/es/DOCUMENTATION-POLICY.md b/.straymark/00-governance/i18n/es/DOCUMENTATION-POLICY.md index c6908a9..f54e730 100644 --- a/.straymark/00-governance/i18n/es/DOCUMENTATION-POLICY.md +++ b/.straymark/00-governance/i18n/es/DOCUMENTATION-POLICY.md @@ -261,6 +261,7 @@ Para documentos que requieren múltiples revisores (p. ej., ETH con sign-off de │ └── ethical-reviews/ # ETH ├── 08-security/ # SEC — Evaluaciones de seguridad ├── 09-ai-models/ # MCARD — Tarjetas de modelo/sistema +├── follow-ups-backlog.md # Registro de follow-ups (primera clase, contadores CLI-owned — no es un tipo de documento; ver FOLLOW-UPS-BACKLOG-PATTERN.md) └── templates/ # Plantillas ``` @@ -311,4 +312,4 @@ Ver también [ADR-2025-01-20-001] para contexto arquitectónico. --- -*StrayMark fw-4.20.0 | [Strange Days Tech](https://strangedays.tech)* +*StrayMark fw-4.22.0 | [Strange Days Tech](https://strangedays.tech)* diff --git a/.straymark/00-governance/i18n/es/FOLLOW-UPS-BACKLOG-PATTERN.md b/.straymark/00-governance/i18n/es/FOLLOW-UPS-BACKLOG-PATTERN.md index 800efc1..f4756ab 100644 --- a/.straymark/00-governance/i18n/es/FOLLOW-UPS-BACKLOG-PATTERN.md +++ b/.straymark/00-governance/i18n/es/FOLLOW-UPS-BACKLOG-PATTERN.md @@ -1,6 +1,6 @@ # Patrón de Backlog de Follow-ups - StrayMark -> Convención reproducible para gestionar entradas acumuladas de `§Follow-ups` y `R (new, not in Charter)` a lo largo de muchos AILOGs y Charters. +> Registry de primera clase para gestionar entradas acumuladas de `§Follow-ups` y `R (new, not in Charter)` a lo largo de muchos AILOGs y Charters. **Idiomas**: [English](../../FOLLOW-UPS-BACKLOG-PATTERN.md) | Español | [简体中文](../zh-CN/FOLLOW-UPS-BACKLOG-PATTERN.md) @@ -8,9 +8,17 @@ ## Estado -**v0 — validado en N=1 dominio** (`StrangeDaysTech/sentinel` CHARTER-12, 2026-05-06). +**v1 — entidad de primera clase desde fw-4.21.0 / cli-3.19.0** (experimental; la estabilización dura está condicionada a un segundo adopter, según el principio de diseño #12 y ADR-2026-06-03-001). -Esto es una **convención**, no una funcionalidad del CLI. Los adopters la reproducen localmente con markdown + un script bash portable. El patrón puede evolucionar a un subcomando `straymark followups` una vez que un segundo adopter lo valide (ver [Preguntas abiertas](#preguntas-abiertas)). +Cronología de maduración, espejando el carril del Charter: + +| Etapa | Release | Qué aterrizó | +|-------|---------|--------------| +| Convención (v0) | fw-4.10.0 | Documento del patrón + script bash del lado del adopter (Sentinel CHARTER-12, N=47) | +| Refinamiento (v0.1) | fw-4.13.1 | Ruta de promoción FU → TDE (2 formas), contador `total_promoted` | +| **Primera clase (v1)** | **fw-4.21.0 / cli-3.19.0** | Schema JSON, CLI nativo `straymark followups`, integración con `explore`/`status`, directivas de agente shippeadas en `AGENT-RULES.md §13`, template del registry | + +El registry es un **artefacto de primera clase** como el Charter — no es uno de los 16 tipos de documento. Tiene su propia ruta canónica, su propio schema, su propio namespace de CLI y su propio grupo sintético en la TUI de `explore`. --- @@ -27,11 +35,15 @@ Adopta este patrón cuando se cumpla **cualquiera** de estas condiciones: Por debajo de ese volumen, la convención per-AILOG por sí sola es suficiente — adoptar este patrón temprano agrega overhead de mantenimiento sin retorno. +### El registry como input de planificación + +Lección empírica del adopter de referencia (issue #214, N=91 entradas): el backlog es más que una lista de chores diferidos. Los follow-ups se originan no solo de la planificación (ex-ante) sino de la **realidad de ejecución** — corridas de tests, lecturas de telemetría, incidentes de staging, bugs observados en entornos reales (no simulados) — y retroalimentan la planificación: se vuelven chores, mini-charters, o incluso reconfiguran Charters que ya estaban planeados. El registry es el **contraparte ex-post de SpecKit**: SpecKit alimenta la planificación desde la intención; el backlog la alimenta desde la ejecución. Las dimensiones de v1 (`Origin-class`, `Severity`, `Labels`, el vocabulario de `Destination`) existen para hacer ese bucle de planificación consultable. + --- ## Forma -### Archivo de registro +### Archivo del registry Único archivo markdown en la ruta canónica: @@ -39,17 +51,20 @@ Por debajo de ese volumen, la convención per-AILOG por sí sola es suficiente .straymark/follow-ups-backlog.md ``` +Un template con frontmatter vacío y los cinco headers de bucket se shippea en `.straymark/templates/follow-ups-backlog.md`. + ### Frontmatter (YAML) ```yaml --- -last_scan: 2026-05-06 +last_scan: 2026-06-03 last_scan_range: AILOG-NNNN-NN-NN-NNN..AILOG-NNNN-NN-NN-NNN # opcional — primer..último AILOG cubierto -schema_version: v0 -total_open: 0 # cuenta de entradas actualmente `open` -total_promoted: 0 # cuenta de entradas actualmente `promoted` (agregado en schema v0.1 — ver "Promoción a TDE") -total_closed_in_session: 0 # cuenta de entradas `closed` desde la última sesión (opcional, operator-maintained) -total_phase_blocked: 0 # cuenta de entradas `phase-blocked` (opcional) +schema_version: v1 +total_open: 0 # CLI-owned — recalculado en cada escritura +total_promoted: 0 # CLI-owned +total_closed_in_session: 0 # CLI-owned +total_phase_blocked: 0 # CLI-owned +total_suspected_closed: 0 # CLI-owned (nuevo en v1) buckets: - ready - time-triggered @@ -63,13 +78,15 @@ fully_extracted_ailogs: --- ``` -Los contadores `total_*` son **metadatos operator-maintained**. El script de drift no los actualiza automáticamente — viven en el header para que un vistazo a inicio de sesión muestre el pulso del registro sin scrollear por buckets. `total_promoted` se canonicalizó en schema v0.1 (señal empírica del adopter Sentinel, fw-4.13.1) para reflejar el patrón existente de `total_open` / `total_closed_in_session` / `total_phase_blocked`. +**Los contadores `total_*` son CLI-owned desde v1.** Cada comando de escritura (`straymark followups drift --apply`, `straymark followups promote`) los recalcula desde los estados reales de las entradas. No los mantengas a mano — los valores rancios editados a mano se corrigen en la siguiente escritura. Esto cierra el modo de fallo de drift silencioso de contadores observado en N=91 (declarado `total_open: 47` vs 65 real tras 4 semanas — issue #214 Señal 2). `straymark followups status` siempre muestra conteos recalculados al vuelo, así que el pulso es confiable incluso si el archivo está rancio. + +La lista `fully_extracted_ailogs` es el **metadato cargante** para la detección de drift. Todo AILOG cuyas entradas de `§Follow-ups` y `R` han sido transferidas al registry (o explícitamente clasificadas como superseded) pertenece a esta lista. La detección de drift compara esta lista contra los AILOGs que tienen contenido de follow-ups en el repo. -La lista `fully_extracted_ailogs` es el **metadato cargante** para la detección de drift. Todo AILOG cuyas entradas de `§Follow-ups` y `R` han sido transferidas al registro (o explícitamente clasificadas como superseded) pertenece a esta lista. La detección de drift compara esta lista contra los AILOGs que tienen contenido de follow-ups en el repo. +El schema formal del frontmatter es `.straymark/schemas/follow-ups-backlog.schema.v1.json` (v1 experimental — ver Estado arriba). ### Buckets -Cinco buckets organizan las entradas por tipo de trigger: +Cinco buckets organizan las entradas por tipo de trigger — *cuándo son accionables*: - `ready` — accionable ahora, sin dependencia de trigger externo. - `time-triggered` — trigger basado en calendario (ciclo de auditoría, revisión periódica). @@ -77,27 +94,40 @@ Cinco buckets organizan las entradas por tipo de trigger: - `phase-blocked` — bloqueado por un componente o fase futura que aún no existe. - `operational` — decisión manual del operador o acción de sistema externo. -### Esquema de entrada +El vocabulario es estable en N=91 entradas en el adopter de referencia — no se ha necesitado un sexto bucket. La Severity (*cuánto duele saltársela*) intencionalmente **no** es un bucket: es un campo per-entry ortogonal (ver abajo). + +### Esquema de entrada (v1) -Cada entrada dentro de un bucket sigue esta forma: +Cada entrada dentro de un bucket sigue esta forma (campos v1 marcados; todos opcionales — las entradas v0 siguen siendo válidas): ```markdown ### FU-NNN — - **Origin**: AILOG-NNNN-NN-NN-NNN -- **Status**: open | in-progress | closed | superseded | promoted +- **Origin-class**: ex-ante-planning | testing | telemetry | staging | real-env-bug (v1, opcional) +- **Status**: open | in-progress | suspected-closed | closed | superseded | promoted +- **Severity**: normal | blocking (v1, opcional; default normal) - **Trigger**: ready | | when | -- **Destination**: +- **Destination**: chore | mini-charter | charter-replanning | operations | | - **Cost**: +- **Labels**: (v1, opcional) - **Notes**: - **Promoted to**: ``` -`FU-NNN` es monotónicamente creciente a lo largo de la vida del registro; no se renumera cuando las entradas se cierran. +`FU-NNN` es monotónicamente creciente a lo largo de la vida del registry; no se renumera cuando las entradas se cierran. + +**Las dimensiones de v1**, cada una canonicalizando una necesidad observada empíricamente (issue #214): + +- **`Origin-class`** — dónde nació la entrada: artefactos de planificación (ex-ante) vs realidad de ejecución (testing, telemetry, staging, bugs de entorno real). Hace consultable el bucle de planificación ex-post. +- **`Severity`** — `blocking` marca issues de clase fiabilidad que deben aterrizar antes de un cutover a producción. Canonicaliza la convención en prosa `PROD-BLOCKER` que emergió en el campo `Notes` del adopter de referencia (Señal 3). Ortogonal al bucket: una entrada `charter-triggered` puede ser `blocking`. +- **`Labels`** — tags libres para agrupar entradas en Charters / mini-charters / chores planeados durante el triage. Consultable vía `straymark followups list --label `. +- **Vocabulario de `Destination`** — formaliza dónde aterriza el trabajo cuando se dispara: `chore`, `mini-charter`, `charter-replanning` (la entrada reconfigura un Charter ya planeado en vez de agregarle una tarea), `operations`, un id de Charter específico, o un id de TDE. Los valores free-form siguen siendo aceptados (parsing tolerante). ### Vocabulario de status - `open` — pendiente, sin acción aún. - `in-progress` — un Charter ha sido declarado o está en ejecución para atender esta entrada. +- `suspected-closed` *(nuevo en v1)* — auto-extraído por `drift --apply` desde un AILOG cuyo texto carga un marcador de cierre explícito (`closed in-Charter`, `fixed in batch N`, un hash de commit). El operador confirma (→ `closed`) o reabre (→ `open`) en el siguiente triage. Ver "Detección de drift" abajo. - `closed` — entrada resuelta (Charter mergeado, tarea operativa hecha, tiempo transcurrido y revisado). - `superseded` — atendida por otro trabajo que no referenció esta entrada directamente. - `promoted` — la entrada fue elevada a un documento TDE porque cumple los criterios de deuda transversal (ver "Promoción a TDE" abajo). El campo `Promoted to:` carga el id del TDE. @@ -111,26 +141,32 @@ Las entradas closed, superseded y promoted permanecen en el archivo (historia au Algunas entradas FU no son solo tareas diferidas — describen **deuda técnica transversal** que merece su propio documento de gobernanza (TDE). Los criterios para promoción reflejan la desambiguación TDE-vs-`R` en `AGENT-RULES.md §3`: - La entrada es *herencia de un Charter previo* (ya vivió ≥1 cierre de Charter sin remediación). -- La entrada *aplica a múltiples módulos o múltiples Charters* — el registro central la ha fragmentado en bullets que comparten una causa raíz. +- La entrada *aplica a múltiples módulos o múltiples Charters* — el registry central la ha fragmentado en bullets que comparten una causa raíz. - La entrada *requiere un Charter dedicado fuera del envelope de scope actual* para remediarse. - La entrada *requiere priorización o asignación humana* que la revisión periódica del operador no puede decidir desde el bullet solo (matriz impact × effort, ownership). Cuando cualquiera de estos se cumple, promueve la entrada FU a un documento TDE bajo `.straymark/06-evolution/technical-debt/`: -1. Crea el TDE vía `/straymark-new tde` (o `straymark new --type tde`). Llena `impact`, `effort`, `type`, y las secciones del body desde el contexto de la entrada FU. +```bash +straymark followups promote FU-NNN +``` + +El comando automatiza el flujo de tres pasos que era manual en v0: + +1. Crea el documento TDE (la misma maquinaria que `straymark new --type tde`), pre-llenando `impact`, `effort`, `type`, y el contexto del body desde la entrada FU. 2. Agrega `promoted_from_followup: FU-NNN` al frontmatter del TDE para trazabilidad. -3. En la entrada FU, establece `Status: promoted`, `Destination: TDE-YYYY-MM-DD-NNN`, y agrega `Promoted to: TDE-YYYY-MM-DD-NNN`. Mueve la entrada a la sección `## Bucket: closed` si mantienes una; si no, déjala en lugar con el nuevo status. +3. En la entrada FU, establece `Status: promoted`, `Destination: TDE-YYYY-MM-DD-NNN`, y `Promoted to: TDE-YYYY-MM-DD-NNN`; recalcula los contadores del frontmatter. -La entrada FU **no se elimina** tras la promoción — su presencia en el registro es el rastro auditable que muestra de dónde vino el TDE. +La entrada FU **no se elimina** tras la promoción — su presencia en el registry es el rastro auditable que muestra de dónde vino el TDE. ### Dos formas de promoción — promoción-de-existente vs retroactiva-en-la-creación -El workflow anterior cubre el **caso estándar**: una entrada FU `open` ya existe en el registro y se eleva a un TDE durante revisión periódica. Existe un segundo caso igualmente válido que emergió empíricamente del retrospectivo de Sentinel CHARTER-13: +El flujo anterior cubre el **caso estándar**: una entrada FU `open` ya existe en el registry y se eleva a un TDE durante revisión periódica. Existe un segundo caso igualmente válido que emergió empíricamente del retrospectivo de Sentinel CHARTER-13: -- **Promoción de entrada existente** — un FU fue registrado (típicamente vía `--apply`) como `open` semanas o Charters atrás, vivió ≥1 cierre de Charter sin resolución, y cumple los cuatro criterios. Flujo estándar. -- **Promoción retroactiva en la creación** — la deuda se reconoce como TDE-worthy *durante* un retrospectivo (ceremonia de cierre de Charter, ciclo de auditoría, redacción de RFC) y nunca existió como FU `open`. Se crea primero el TDE; se agrega una entrada FU al registro *con `Status: promoted`* desde el nacimiento, proporcionando el rastro auditable desde el TDE hacia el contexto originador (un `R` en un AILOG, un finding del calibrador, una clasificación diferida). +- **Promoción de entrada existente** — un FU fue registrado (típicamente vía `drift --apply`) como `open` semanas o Charters atrás, vivió ≥1 cierre de Charter sin resolución, y cumple los cuatro criterios anteriores. Flujo estándar. +- **Promoción retroactiva en la creación** — la deuda se reconoce como TDE-worthy *durante* un retrospectivo (ceremonia de cierre de Charter, ciclo de auditoría, redacción de RFC) y nunca existió como FU `open`. Se crea primero el TDE; se agrega una entrada FU al registry *con `Status: promoted`* desde el nacimiento, proporcionando el rastro auditable desde el TDE hacia el contexto originador (un `R` en un AILOG, un finding del calibrador, una clasificación diferida). -Ambas formas producen el mismo estado final en el registro: una entrada con `Status: promoted` y un puntero `Promoted to: TDE-YYYY-MM-DD-NNN`. La diferencia es si la entrada pre-existía como `open` o nació `promoted`. El script de drift las trata idénticamente (no diferencia por status de nacimiento), y las analíticas del adopter que cuentan `total_promoted` obtienen el mismo número en ambos casos. +Ambas formas producen el mismo estado final en el registry: una entrada con `Status: promoted` y un puntero `Promoted to: TDE-YYYY-MM-DD-NNN`. La diferencia es si la entrada pre-existía como `open` o nació `promoted`. La detección de drift las trata idénticamente, y las analíticas que cuentan `total_promoted` obtienen el mismo número en ambos casos. Ante la duda, prefiere crear la entrada FU — aunque sea retroactivamente — porque cross-referencia el TDE de vuelta al AILOG / número-R / contexto fuente que disparó el reconocimiento. Un TDE con `promoted_from_followup: FU-NNN` apuntando a una entrada que existe en el backlog es más navegable que uno apuntando a un FU ficticio. @@ -138,54 +174,64 @@ Ante la duda, prefiere crear la entrada FU — aunque sea retroactivamente — p - **Revisión periódica** — cuando el operador hace el pase manual de reclasificación, promueve cualquier entrada que haya vivido ≥2 cierres de Charter sin resolución y cumpla los criterios anteriores. - **Cierre de Charter** — al revisar entradas que el Charter recién cerrado resolvió, si encuentras entradas que *no* fueron resueltas y cumplen los criterios anteriores, promuévelas en vez de dejarlas como `open`. -- **Pre-declaración de Charter** — si estás a punto de declarar un Charter y notas que el registro contiene entradas que este Charter *parcialmente* atendería, la porción no atendida puede pertenecer como TDE en vez de como otro FU diferido. - -El script de drift (`scripts/check-followups-drift.sh`) **no se extiende** para candidatos a promoción en v0 — la promoción es operator-driven. Una mejora futura v1 podría flagear entradas que cumplan la heurística "vivió ≥2 Charters", pero eso cristaliza tras un segundo adopter que valide el patrón (misma puerta que el resto de v0 → v1). +- **Pre-declaración de Charter** — si estás a punto de declarar un Charter y notas que el registry contiene entradas que este Charter *parcialmente* atendería, la porción no atendida puede pertenecer como TDE en vez de como otro FU diferido. --- -## Detección de drift +## Detección de drift — nativa desde cli-3.19.0 + +La detección de drift mantiene el registry sincronizado con nuevos AILOGs. Desde cli-3.19.0 es un **comando nativo del CLI** — sin script externo: -Un pequeño script bash es la capa de verificación que mantiene el registro sincronizado con nuevos AILOGs. El script vive en el repo del adopter (ruta sugerida: `scripts/check-followups-drift.sh`) y tiene tres modos. +```bash +straymark followups drift # escanea AILOGs modificados en git diff origin/main..HEAD (fallback HEAD~1..HEAD); sale con 1 si hay drift +straymark followups drift --apply # mismo escaneo + extrae nuevas entradas al registry +straymark followups drift --scan-all # barrido completo periódico sobre cada AILOG +``` -### Modos +### Qué hace `--apply` -- **Default** — escanea AILOGs modificados en `git diff origin/main..HEAD` (con fallback a `HEAD~1..HEAD`). Avisa sobre cualquier AILOG con contenido `§Follow-ups` / `R (new)` que no esté en `fully_extracted_ailogs`. Sale con 1 si hay drift. -- **`--apply`** — mismo escaneo, pero auto-agrega nuevas entradas bajo `## Bucket: ready` con ids `FU-NNN` auto-generados y agrega el id del AILOG a `fully_extracted_ailogs`. El operador reclasifica al bucket correcto después. -- **`--scan-all`** — escanea cada AILOG en el proyecto (barrido completo periódico). +1. Extrae cada bullet `§Follow-ups` y riesgo `R (new, not in Charter)` de AILOGs que aún no están en `fully_extracted_ailogs`, agregándolos bajo `## Bucket: ready` con ids `FU-NNN` auto-numerados. El operador reclasifica bucket/trigger/destination en el siguiente triage. +2. **Refinamiento anti-ruido** *(v1 — resuelve issue #214 Señal 1)*: los bullets cuyo texto del AILOG carga un marcador de cierre explícito (`closed in-Charter`, `fixed in batch N`, una referencia de hash de commit) se extraen con `Status: suspected-closed` en vez de `open`, en lugar de contaminar el bucket `ready` como ruido TBD. A lo largo de ambas ocurrencias documentadas en el adopter de referencia, 20–75% de las entradas auto-agregadas por batch ya estaban resueltas in-Charter — este refinamiento elimina el único costo recurrente del workflow v0. +3. Agrega el id del AILOG a `fully_extracted_ailogs`. +4. **Recalcula todos los contadores `total_*`** desde los estados reales de las entradas (Señal 2). +5. Si el registry es `schema_version: v0`, lo actualiza a `v1` in situ — de forma no destructiva e idempotente (todos los campos v1 son opcionales; no se reescribe nada excepto el marcador de versión y los contadores). ### Granularidad per-AILOG vs per-bullet -El tracking es **per-AILOG**, no per-bullet. Un AILOG está totalmente extraído (su id está en `fully_extracted_ailogs` — confiar en el registro) o no lo está (extraer todo). El matching per-bullet requeriría fingerprinting (hashing de texto o comparación fuzzy), que produce falsos positivos cada vez que una entrada del registro parafrasea el bullet del AILOG — y las entradas curadas siempre parafrasean. +El tracking es **per-AILOG**, no per-bullet. Un AILOG está totalmente extraído (su id está en `fully_extracted_ailogs` — confiar en el registry) o no lo está (extraer todo). El matching per-bullet requeriría fingerprinting (hashing de texto o comparación fuzzy), que produce falsos positivos cada vez que una entrada del registry parafrasea el bullet del AILOG — y las entradas curadas siempre parafrasean. Esta decisión de diseño está validada empíricamente: **0 falsos positivos a lo largo de 76 AILOGs y ~10 corridas de apply** en el adopter de referencia. -El costo de la granularidad per-AILOG: cuando se agrega un follow-up a un AILOG ya extraído tras el cierre del Charter, la detección de drift no lo detecta. La remediación es manual del operador — quitar el AILOG de `fully_extracted_ailogs` y re-correr con `--apply`. Este trade-off es intencional para v0 porque la mayoría de AILOGs son write-once tras el cierre del Charter. +El costo de la granularidad per-AILOG: cuando se agrega un follow-up a un AILOG ya extraído tras el cierre del Charter, la detección de drift no lo detecta. La remediación es manual del operador — quitar el AILOG de `fully_extracted_ailogs` y re-correr con `--apply`. Este trade-off es intencional porque la mayoría de AILOGs son write-once tras el cierre del Charter. -### Plantilla de script +### Script bash legacy (deprecado) + +La implementación de referencia v0 (`scripts/check-followups-drift.sh`, ~296 líneas de bash POSIX en el repo del adopter Sentinel) está **deprecada a partir de cli-3.19.0**. Sigue funcionando para registries v0 pero ya no se mantiene y carece del refinamiento anti-ruido y del recálculo de contadores. Ruta de migración: borra el script, ejecuta `straymark followups drift --apply` una vez (esto también actualiza el registry a v1), y actualiza cualquier pre-commit hook para que llame al CLI en su lugar. + +--- -Una implementación de referencia (~290 líneas de bash POSIX) está en `StrangeDaysTech/sentinel` en `scripts/check-followups-drift.sh`. Cópiala a tu repo y ajusta las constantes al inicio: +## Superficie del CLI ```bash -BACKLOG_FILE=".straymark/follow-ups-backlog.md" -AILOG_DIR=".straymark/07-ai-audit/agent-logs" +straymark followups list # enumera entradas: id FU, status, severity, bucket, destination +straymark followups list --bucket ready --status open --severity blocking --label +straymark followups status # pulso del registry: contadores (recalculados al vuelo), desglose por bucket/severity +straymark followups status FU-NNN # vista de detalle de una entrada +straymark followups drift [--apply|--scan-all] # detección de drift (ver arriba) +straymark followups promote FU-NNN # automatiza la promoción FU → TDE (ver arriba) ``` -El script usa solo `awk` y `grep` — sin jq, sin yq, sin dependencias pesadas. Portable entre Linux y macOS. +El registry también aparece como un grupo sintético **Follow-ups** en la TUI de `straymark explore` (sub-nodos por bucket) y como un bloque de conteos en `straymark status`. --- ## Integración con agentes -El agente (Claude / Gemini / etc.) se vuelve el mantenedor primario del registro. Agrega a tu `CLAUDE.md` / `AGENT.md`: +Desde fw-4.21.0 las directivas de agente **se shippean con el framework** en [`AGENT-RULES.md §13`](AGENT-RULES.md) — los adopters ya no copian un bloque a su propio `CLAUDE.md` / `AGENT.md`. En resumen: -```markdown -## Backlog de follow-ups - -- **Inicio de sesión**: revisar `.straymark/follow-ups-backlog.md` para saber qué está pendiente en el proyecto. -- **Checklist pre-commit**: ¿creaste o modificaste algún AILOG con entradas `## Follow-ups` o `R (new, not in Charter)`? → ejecuta `scripts/check-followups-drift.sh --apply` para extender el backlog en el mismo commit. -- **Post-cierre de Charter**: revisar entradas que el Charter resolvió; marcarlas `closed` (con el id del Charter de cierre en `Notes`) o `superseded`. Para entradas no resueltas que cumplen los criterios de TDE (herencia de Charter previo, transversal, requiere Charter dedicado, necesita priorización humana), promuévelas a un documento TDE (ver "Promoción a TDE" en este patrón + `AGENT-RULES.md §3`). -``` +- **Session start**: echa un vistazo a `.straymark/follow-ups-backlog.md` (o ejecuta `straymark followups status`) para saber qué está pendiente en el proyecto. +- **Pre-commit**: ¿creaste o modificaste algún AILOG con entradas `## Follow-ups` o `R (new, not in Charter)`? → ejecuta `straymark followups drift --apply` en el mismo commit. +- **Post-Charter close**: revisa las entradas que el Charter resolvió; márcalas `closed` (con el id del Charter de cierre en `Notes`) o `superseded`; confirma o reabre cualquier entrada `suspected-closed`; promueve las entradas no resueltas que cumplen los criterios de TDE vía `straymark followups promote`. -Esto hace al agente el mantenedor, al script la capa de verificación, y al operador el revisor periódico (re-bucketing, marcar closed, podar superseded, promover a TDE cuando los criterios aplican). +Esto hace al agente el mantenedor primario del registry, al CLI la capa de verificación, y al operador el revisor periódico (re-bucketing, confirmar suspected-closed, podar superseded, promover a TDE cuando los criterios aplican). --- @@ -193,54 +239,56 @@ Esto hace al agente el mantenedor, al script la capa de verificación, y al oper Para un adopter empezando desde cero: -1. Crear `.straymark/follow-ups-backlog.md` con el frontmatter de arriba (lista `fully_extracted_ailogs:` vacía inicialmente) y los cinco headers `## Bucket: `. -2. Copiar el script de referencia desde `StrangeDaysTech/sentinel` a `scripts/check-followups-drift.sh`. Ajustar `AILOG_DIR` si tus AILOGs viven en otro lado. -3. Ejecutar `scripts/check-followups-drift.sh --scan-all --apply` para sembrar el registro desde AILOGs existentes. -4. Reclasificar manualmente las entradas auto-generadas en `## Bucket: ready` a los buckets correctos. Esto es triage one-time, típicamente 30-60 min para un backlog de ~50 entradas. -5. Agregar el bloque de integración con agentes a `CLAUDE.md` / `AGENT.md`. -6. Opcionalmente conectar `scripts/check-followups-drift.sh` a un pre-commit hook para enforcement duro. +1. Copia `.straymark/templates/follow-ups-backlog.md` a `.straymark/follow-ups-backlog.md` (lista `fully_extracted_ailogs:` vacía, cinco headers `## Bucket:`). +2. Ejecuta `straymark followups drift --scan-all --apply` para sembrar el registry desde AILOGs existentes. +3. Reclasifica manualmente las entradas auto-generadas en `## Bucket: ready` a los buckets correctos; llena `Origin-class`/`Severity`/`Labels` donde agreguen señal. Esto es triage one-time, típicamente 30-60 min para un backlog de ~50 entradas. +4. Listo — las directivas de agente en `AGENT-RULES.md §13` ya están activas; no se necesitan ediciones a `CLAUDE.md`. -Para un adopter migrando desde tracking ad-hoc: el mismo flujo, pero el paso 4 puede requerir decidir qué entradas ya están `closed` o `superseded` — esa clasificación es lo que hace al registro útil. +Para un adopter migrando desde la convención v0: ejecuta `straymark followups drift --apply` una vez (auto-actualiza el registry a v1), borra el script bash local, y actualiza cualquier pre-commit hook para que llame al CLI. --- ## Implementación de referencia -`StrangeDaysTech/sentinel` CHARTER-12, mergeado 2026-05-06: +`StrangeDaysTech/sentinel` — el adopter originador: -- PR de implementación: [sentinel#53](https://github.com/StrangeDaysTech/sentinel/pull/53) (registro + script + adiciones a CLAUDE.md). -- PR de cierre: [sentinel#54](https://github.com/StrangeDaysTech/sentinel/pull/54) (verificación post-merge + cierre del Charter). - -Contexto empírico: 47 entradas sembradas desde la retrospectiva CHARTER-08 → CHARTER-11 (~30 min de triage multi-agente). La cadena demostró el gap que motivó el patrón — sin el registro, el operador no podía ver "qué está pendiente en el proyecto" sin reclasificar los follow-ups de cada Charter en aislamiento. Con el registro, la revisión de inicio de sesión es una sola lectura de archivo. +- Patrón v0: CHARTER-12, mergeado 2026-05-06 ([sentinel#53](https://github.com/StrangeDaysTech/sentinel/pull/53), [sentinel#54](https://github.com/StrangeDaysTech/sentinel/pull/54)). 47 entradas sembradas desde la retrospectiva CHARTER-08 → CHARTER-11. +- Validación de escala: triage post-Etapa-3 en **N=91 FUs / 76 AILOGs extraídos / 65 open** ([issue #214](https://github.com/StrangeDaysTech/straymark/issues/214)) — el input empírico que impulsó el schema v1 y el CLI nativo (ADR-2026-06-03-001). --- ## Preguntas abiertas -Estas no se resuelven en v0. Revisiones futuras de este patrón, o un helper CLI, pueden atenderlas: +Resueltas en v1: + +- ~~**Validación de schema.**~~ → `.straymark/schemas/follow-ups-backlog.schema.v1.json` (frontmatter), validación de la forma de entrada en el parser del CLI. +- ~~**Cristalización como CLI `straymark followups`.**~~ → `list / status / drift / promote` nativos desde cli-3.19.0. +- ~~**Heurística de clasificación de bucket** (parcialmente).~~ → `suspected-closed` elimina la clase de ruido dominante; la sugerencia completa de bucket (usando `tags` del AILOG / `effort_estimate` del Charter) sigue abierta. + +Aún abiertas para revisiones futuras: -- **Heurística de clasificación de bucket**. Hoy `--apply` vuelca cada entrada nueva a `## Bucket: ready`; el operador reclasifica manualmente. Una heurística usando `tags` del AILOG y `effort_estimate` del Charter podría sugerir un bucket automáticamente. -- **Validación de schema**. El registro sigue un esquema tácito; aún no existe `.straymark/schemas/follow-ups-backlog.schema.v0.json`. La validación hoy es revisión humana. -- **Integración con el ciclo de auditoría**. Cuando `straymark charter audit --merge-reports` produce findings de deuda real que no son remediados atómicamente pre-cierre, esos findings viven solo en `.straymark/audits//review.md`. No fluyen automáticamente al registro central. Aflorarlos automáticamente cerraría un gap conocido. -- **Semántica `closed` vs `superseded`**. Hoy la diferencia es si el trabajo de resolución referenció explícitamente la entrada. Una convención más estricta puede emerger. -- **Cristalización como CLI `straymark followups`**. Una vez que un segundo adopter valide el patrón, el framework puede shippear un subcomando que espeje al trío existente `straymark charter`: `list` / `close` / `drift`. Los adopters en v0 (este patrón) migran borrando su script local y cambiando la instrucción del agente. +- **Integración con el ciclo de auditoría.** Cuando `straymark charter audit --merge-reports` produce findings de deuda real que no son remediados atómicamente pre-cierre, esos findings viven solo en `.straymark/audits//review.md`. No fluyen automáticamente al registry central. Aflorarlos automáticamente cerraría un gap conocido. +- **Semántica `closed` vs `superseded`.** Hoy la diferencia es si el trabajo de resolución referenció explícitamente la entrada. Una convención más estricta puede emerger. +- **Integración suave con `charter close`** (issue #135 Tier 3): auto-invocar `followups drift --apply` tras un cierre de Charter, con un prompt interactivo de promoción. Condicionada a una señal de fricción de un segundo adopter. +- **Estabilización dura del schema (v1.0).** Condicionada a la validación por un segundo adopter en otro dominio, según el principio de diseño #12. --- ## Créditos -Contribuido vía [issue #111](https://github.com/StrangeDaysTech/straymark/issues/111) por el adopter Sentinel. Fundamento empírico: cadena CHARTER-08 → CHARTER-11 en `StrangeDaysTech/sentinel`. Autor: José Villaseñor Montfort. +Contribuido vía [issue #111](https://github.com/StrangeDaysTech/straymark/issues/111) por el adopter Sentinel; madurado a primera clase vía [issue #214](https://github.com/StrangeDaysTech/straymark/issues/214) y ADR-2026-06-03-001. Fundamento empírico: cadena CHARTER-08 → CHARTER-11 y el triage post-Etapa-3 en N=91 en `StrangeDaysTech/sentinel`. Autor: José Villaseñor Montfort. -*Este documento fue elaborado con asistencia de herramientas de IA generativa (Claude 4.7); toda la responsabilidad del contenido recae en el autor humano.* +*Este documento fue elaborado con asistencia de herramientas de IA generativa (Claude 4.7 / Opus 4.8); toda la responsabilidad del contenido recae en el autor humano.* --- ## Relacionado -- [EMERGENT-OBSERVATION-DESIGN.md](EMERGENT-OBSERVATION-DESIGN.md) — el meta-patrón que esta convención de detección de drift instancia en la superficie per-AILOG ↔ registro. +- [EMERGENT-OBSERVATION-DESIGN.md](EMERGENT-OBSERVATION-DESIGN.md) — el meta-patrón que esta convención de detección de drift instancia en la superficie per-AILOG ↔ registry. - [CHARTER-CHAIN-EVOLUTION.md](CHARTER-CHAIN-EVOLUTION.md) — patrón hermano que opera a nivel de cadena (Pattern 1) y a nivel de ciclo (Pattern 2). -- [AGENT-RULES.md §3](AGENT-RULES.md) — criterios de escalación TDE-vs-`R` que pueden promover follow-ups a entradas de deuda dedicadas. +- [AGENT-RULES.md §3](AGENT-RULES.md) — criterios de escalación TDE-vs-`R` que pueden promover follow-ups a entradas de deuda dedicadas; §13 — las directivas de agente shippeadas para el mantenimiento del registry. +- `STRAYMARK.md §16` — el resumen a nivel onboarding del registry como artefacto de primera clase. --- -*StrayMark fw-4.19.0 | [Strange Days Tech](https://strangedays.tech)* +*StrayMark fw-4.22.0 | [Strange Days Tech](https://strangedays.tech)* diff --git a/.straymark/00-governance/i18n/es/QUICK-REFERENCE.md b/.straymark/00-governance/i18n/es/QUICK-REFERENCE.md index 921394e..59a590b 100644 --- a/.straymark/00-governance/i18n/es/QUICK-REFERENCE.md +++ b/.straymark/00-governance/i18n/es/QUICK-REFERENCE.md @@ -67,6 +67,20 @@ Los Charters **no** son tipos de documento — envuelven un bloque de implementa > Ver sección 15 de `STRAYMARK.md` y `.straymark/00-governance/SPECKIT-CHARTER-BRIDGE.md` para heurísticas de granularidad, ciclo de vida y el puente SpecKit ↔ Charter. +### Registros de Primera Clase — Backlog de Follow-ups *(fw-4.21.0+)* + +El backlog de follow-ups tampoco es un tipo de documento — un registry de un solo archivo que agrega entradas `§Follow-ups` / `R (new)` a lo largo de los AILOGs. Ids de entrada `FU-NNN`; cinco buckets por tipo de trigger; estados `open | in-progress | suspected-closed | closed | superseded | promoted`. Los contadores son CLI-owned. + +| Concepto | Archivo | Autonomía del Agente | +|----------|---------|---------------------| +| `Registry de follow-ups` | `.straymark/follow-ups-backlog.md` (schema: `follow-ups-backlog.schema.v1.json`, experimental) | El agente extrae vía `followups drift --apply` (pre-commit); el operador es dueño del triage y de la aprobación de promociones | + +```bash +straymark followups list / status / drift [--apply] / promote FU-NNN +``` + +> Ver sección 16 de `STRAYMARK.md`, `FOLLOW-UPS-BACKLOG-PATTERN.md` y AGENT-RULES.md §13 para las directivas de agente shippeadas. + --- ## Cuándo Documentar @@ -82,6 +96,7 @@ Los Charters **no** son tipos de documento — envuelven un bloque de implementa | Cambios en instrumentación OTel | AILOG + tag `observabilidad` | | Bloque de implementación multi-sesión (>1 día, >5 tareas en varias fases) | Declarar un **Charter** (`straymark charter new`) | | Deuda técnica transversal (herencia de Charter previo, aplica a múltiples módulos, requiere Charter dedicado, necesita priorización humana) | **TDE** — distinto del `R` por Charter; ver AGENT-RULES.md §3 | +| AILOG creado/modificado con entradas `## Follow-ups` o `R (new, not in Charter)` | `straymark followups drift --apply` en el mismo commit — ver AGENT-RULES.md §13 | **NO documentar**: credenciales, tokens, PII, secretos. @@ -141,7 +156,8 @@ Marcar `review_required: true` cuando: ├── 08-security/ ← SEC ├── 09-ai-models/ ← MCARD ├── charters/ ← Charter (NN-slug.md + NN-slug.telemetry.yaml) -└── templates/ ← Plantillas (incl. subdir charter/) +├── follow-ups-backlog.md ← Registry de follow-ups (entradas FU-NNN, primera clase desde fw-4.21.0) +└── templates/ ← Plantillas (incl. subdir charter/ + follow-ups-backlog.md) ``` --- @@ -202,6 +218,7 @@ Marcar `review_required: true` cuando: | `/straymark-ailog` / `/straymark-aidec` / `/straymark-adr` | Atajos rápidos para AILOG / AIDEC / ADR | | `/straymark-mcard` / `/straymark-sec` | Flujos interactivos para Model Card / SEC assessment | | `/straymark-charter-new` | Andamiar un Charter (unidad de trabajo declarativa ex-ante) | +| `/straymark-followups` *(fw-4.22.0+)* | Mantener el registry de follow-ups — "¿qué está pendiente?", drift pre-commit, triage/promoción post-cierre | | `/straymark-audit-prompt CHARTER-XX` *(fw-4.9.0+, refactorizada en fw-4.9.0)* | Auditoría externa multi-modelo — escribe prompt unificado en path canónico | | `/straymark-audit-execute [CHARTER-XX]` *(fw-4.9.0+)* | Corre en una CLI auditora — lee prompt, audita con tool use, escribe report | | `/straymark-audit-review CHARTER-XX` *(fw-4.9.0+, expandida en fw-4.9.0)* | Consolida N reports en review.md (6 secciones) + mergea YAML en telemetría | @@ -212,9 +229,9 @@ Marcar `review_required: true` cuando: | Patrón | Documento | |--------|-----------| -| Backlog de follow-ups (registro central + detección de drift) *(fw-4.10.0+)* | [FOLLOW-UPS-BACKLOG-PATTERN.md](FOLLOW-UPS-BACKLOG-PATTERN.md) | +| Backlog de follow-ups (registry de primera clase + CLI nativo `followups`) *(fw-4.10.0+, primera clase fw-4.21.0+)* | [FOLLOW-UPS-BACKLOG-PATTERN.md](FOLLOW-UPS-BACKLOG-PATTERN.md) | | Polish Charter como detección de deuda (anti-patrón "declaración de superficie sin cableado") *(fw-4.18.0+)* | [POLISH-CHARTER-PATTERN.md](POLISH-CHARTER-PATTERN.md) | --- -*StrayMark fw-4.20.0 | [Strange Days Tech](https://strangedays.tech)* +*StrayMark fw-4.22.0 | [Strange Days Tech](https://strangedays.tech)* diff --git a/.straymark/00-governance/i18n/zh-CN/AGENT-RULES.md b/.straymark/00-governance/i18n/zh-CN/AGENT-RULES.md index 0504610..978a055 100644 --- a/.straymark/00-governance/i18n/zh-CN/AGENT-RULES.md +++ b/.straymark/00-governance/i18n/zh-CN/AGENT-RULES.md @@ -376,10 +376,34 @@ confidence: high | medium | low --- +## 13. Follow-ups Backlog（注册表维护） + +当项目维护中央 follow-ups 注册表（`.straymark/follow-ups-backlog.md` —— 见 [`FOLLOW-UPS-BACKLOG-PATTERN.md`](FOLLOW-UPS-BACKLOG-PATTERN.md) 和 `STRAYMARK.md §16`）时,代理是它的**主要维护者**。三条指令: + +### 会话开始 + +扫视 `.straymark/follow-ups-backlog.md`（或运行 `straymark followups status`）以了解项目中所有待处理事项。当操作员询问 *"有什么待处理?"* / *"我们有哪些 follow-ups?"* 时,**注册表是规范来源** —— 从中作答（`straymark followups list`）,而不是重新扫描 AILOG。仅当注册表不存在或 `followups drift` 报告有未提取的 AILOG 时,才回退到 AILOG 扫描。 + +### Pre-commit + +创建或修改了任何带有 `## Follow-ups` 或 `R (new, not in Charter)` 条目的 AILOG 吗? → 运行 `straymark followups drift --apply`,使注册表扩展与 AILOG 搭乘**同一个 commit**。AILOG 文本已标记为在 Charter 内解决的条目会被自动提取为 `suspected-closed` —— 不要删除它们;操作员在下一次 triage 时确认。 + +### Charter 关闭后 + +审查刚关闭的 Charter 所解决的注册表条目: + +- 将其标记为 `closed`（在 `Notes` 中带有关闭 Charter id）或 `superseded`。 +- 确认或重新打开该 Charter 的 AILOG 产生的任何 `suspected-closed` 条目。 +- 对于符合 §3 TDE 标准（遗留、横向、专用 Charter、人工优先级）的未解决条目,通过 `straymark followups promote FU-NNN` 提议提升 —— 提升本身需操作员批准,依据 §3 的自主权限制。 + +注册表 frontmatter 中的计数器（`total_open`、…）为 **CLI-owned**:绝不手工编辑;每个写入命令都会重新计算它们。 + +--- + ## 模式 -当项目在多个 Charter 之间累积大量 AILOG 且 follow-ups 难以跟踪时,参见 [FOLLOW-UPS-BACKLOG-PATTERN.md](FOLLOW-UPS-BACKLOG-PATTERN.md) 了解可复制的约定(中央注册表 + drift 检测脚本 + 代理集成)。约 20+ AILOG 的 adopter 会受益;低于该阈值时,仅 per-AILOG 的 `§Follow-ups` 约定就足够了。 +当项目在多个 Charter 之间累积大量 AILOG 且 follow-ups 难以跟踪时,参见 [FOLLOW-UPS-BACKLOG-PATTERN.md](FOLLOW-UPS-BACKLOG-PATTERN.md) —— **自 fw-4.21.0 / cli-3.19.0 起的一等公民注册表**（中央注册表 + 原生 `straymark followups` CLI + 上方 §13 指令）。约 20+ AILOG 的 adopter 会受益;低于该阈值时,仅 per-AILOG 的 `§Follow-ups` 约定就足够了。 --- -*StrayMark fw-4.20.0 | [Strange Days Tech](https://strangedays.tech)* +*StrayMark fw-4.22.0 | [Strange Days Tech](https://strangedays.tech)* diff --git a/.straymark/00-governance/i18n/zh-CN/C4-DIAGRAM-GUIDE.md b/.straymark/00-governance/i18n/zh-CN/C4-DIAGRAM-GUIDE.md index 6347fcc..7180803 100644 --- a/.straymark/00-governance/i18n/zh-CN/C4-DIAGRAM-GUIDE.md +++ b/.straymark/00-governance/i18n/zh-CN/C4-DIAGRAM-GUIDE.md @@ -234,4 +234,4 @@ Rel(api, db, "Reads/Writes", "SQL") --- -*StrayMark fw-4.20.0 | [Strange Days Tech](https://strangedays.tech)* +*StrayMark fw-4.22.0 | [Strange Days Tech](https://strangedays.tech)* diff --git a/.straymark/00-governance/i18n/zh-CN/DOCUMENTATION-POLICY.md b/.straymark/00-governance/i18n/zh-CN/DOCUMENTATION-POLICY.md index b7a9788..0a79534 100644 --- a/.straymark/00-governance/i18n/zh-CN/DOCUMENTATION-POLICY.md +++ b/.straymark/00-governance/i18n/zh-CN/DOCUMENTATION-POLICY.md @@ -260,6 +260,7 @@ review_outcome: approved # approved | revisions_requested | rejec │ └── ethical-reviews/ # ETH ├── 08-security/ # SEC — 安全评估 ├── 09-ai-models/ # MCARD — 模型/系统卡 +├── follow-ups-backlog.md # Follow-ups 注册表（一等公民,CLI-owned 计数器 —— 不是文档类型;见 FOLLOW-UPS-BACKLOG-PATTERN.md） └── templates/ # 模板 ``` @@ -310,4 +311,4 @@ review_outcome: approved # approved | revisions_requested | rejec --- -*StrayMark fw-4.20.0 | [Strange Days Tech](https://strangedays.tech)* +*StrayMark fw-4.22.0 | [Strange Days Tech](https://strangedays.tech)* diff --git a/.straymark/00-governance/i18n/zh-CN/FOLLOW-UPS-BACKLOG-PATTERN.md b/.straymark/00-governance/i18n/zh-CN/FOLLOW-UPS-BACKLOG-PATTERN.md index 8efabf6..1236b58 100644 --- a/.straymark/00-governance/i18n/zh-CN/FOLLOW-UPS-BACKLOG-PATTERN.md +++ b/.straymark/00-governance/i18n/zh-CN/FOLLOW-UPS-BACKLOG-PATTERN.md @@ -1,6 +1,6 @@ # Follow-ups Backlog 模式 - StrayMark -> 用于跨多个 AILOG 和 Charter 管理累积的 `§Follow-ups` 与 `R (new, not in Charter)` 条目的可复制约定。 +> 用于跨多个 AILOG 和 Charter 管理累积的 `§Follow-ups` 与 `R (new, not in Charter)` 条目的一等公民注册表。 **语言**: [English](../../FOLLOW-UPS-BACKLOG-PATTERN.md) | [Español](../es/FOLLOW-UPS-BACKLOG-PATTERN.md) | 简体中文 @@ -8,15 +8,23 @@ ## 状态 -**v0 — 在 N=1 域中已验证**（`StrangeDaysTech/sentinel` CHARTER-12,2026-05-06）。 +**v1 — 自 fw-4.21.0 / cli-3.19.0 起为一等公民实体**（实验性；硬性稳定化以第二个 adopter 为门槛，依据设计原则 #12 与 ADR-2026-06-03-001）。 -这是一个**约定**,不是 CLI 功能。Adopter 使用 markdown + 一个可移植的 bash 脚本在本地复制此模式。在第二个 adopter 验证后,该模式可能演变为 `straymark followups` 子命令(参见[未决问题](#未决问题))。 +成熟历程，与 Charter 通道相对应： + +| 阶段 | 发布版本 | 落地内容 | +|------|---------|---------| +| 约定 (v0) | fw-4.10.0 | 模式文档 + adopter 端 bash 脚本（Sentinel CHARTER-12,N=47） | +| 精化 (v0.1) | fw-4.13.1 | FU → TDE 提升路径（2 种形态）、`total_promoted` 计数器 | +| **一等公民 (v1)** | **fw-4.21.0 / cli-3.19.0** | JSON schema、原生 `straymark followups` CLI、`explore`/`status` 集成、随 `AGENT-RULES.md §13` 发布的代理指令、注册表模板 | + +该注册表是一个**一等公民工件**,与 Charter 一样 —— 不属于 16 种文档类型之一。它有自己的规范路径、自己的 schema、自己的 CLI 命名空间,以及在 `explore` TUI 中自己的合成分组。 --- ## 何时适用此模式 -StrayMark 的 per-AILOG `§Follow-ups` 约定在写入时有效 — 创建 AILOG 时,实施者记录推迟到后续 Charter 或操作触发器的内容。在累积列表超出操作员可凭记忆扫描范围之前,这种方式都能正常工作。 +StrayMark 的 per-AILOG `§Follow-ups` 约定在写入时有效 —— 创建 AILOG 时,实施者记录推迟到后续 Charter 或操作触发器的内容。在累积列表超出操作员可凭记忆扫描范围之前,这种方式都能正常工作。 当满足**任一**以下条件时,采用此模式: @@ -25,7 +33,11 @@ StrayMark 的 per-AILOG `§Follow-ups` 约定在写入时有效 — 创建 AILOG - 一个"当 X 到来时执行"的 follow-up 几乎丢失,因为在 X 到来后从未重读过原始 AILOG。 - Charter 回顾揭示出本应在数周前被分类为 `closed`、但从未被索引的 follow-ups。 -低于此规模时,仅 per-AILOG 约定就足够了 — 过早采用此模式只会增加维护开销而无回报。 +低于此规模时,仅 per-AILOG 约定就足够了 —— 过早采用此模式只会增加维护开销而无回报。 + +### 注册表作为规划输入 + +来自参考 adopter 的经验教训（issue #214,N=91 个条目）:backlog 不仅仅是一份延期杂务清单。Follow-ups 不仅源自规划（ex-ante,事前）,也源自**执行现实** —— 测试运行、遥测读数、staging 事故、在真实（非模拟）环境中观察到的 bug —— 并且它们反过来反哺规划:它们变成杂务（chore）、迷你 Charter,甚至重塑已经规划好的 Charter。该注册表是 **SpecKit 的 ex-post（事后）对应物**:SpecKit 从意图反哺规划;backlog 从执行反哺规划。v1 维度（`Origin-class`、`Severity`、`Labels`、`Destination` 词汇表）的存在正是为了让这个规划闭环可被查询。 --- @@ -39,17 +51,20 @@ StrayMark 的 per-AILOG `§Follow-ups` 约定在写入时有效 — 创建 AILOG .straymark/follow-ups-backlog.md ``` +一个带有空 frontmatter 和五个 bucket 标题的模板随 `.straymark/templates/follow-ups-backlog.md` 一起发布。 + ### Frontmatter (YAML) ```yaml --- -last_scan: 2026-05-06 +last_scan: 2026-06-03 last_scan_range: AILOG-NNNN-NN-NN-NNN..AILOG-NNNN-NN-NN-NNN # 可选 —— 涵盖的首个..末尾 AILOG -schema_version: v0 -total_open: 0 # 当前为 `open` 状态的条目计数 -total_promoted: 0 # 当前为 `promoted` 状态的条目计数(schema v0.1 新增 —— 见"提升为 TDE") -total_closed_in_session: 0 # 上次会话以来 `closed` 条目计数(可选,operator-maintained) -total_phase_blocked: 0 # `phase-blocked` 条目计数(可选) +schema_version: v1 +total_open: 0 # CLI-owned —— 每次写入时重新计算 +total_promoted: 0 # CLI-owned +total_closed_in_session: 0 # CLI-owned +total_phase_blocked: 0 # CLI-owned +total_suspected_closed: 0 # CLI-owned（v1 新增） buckets: - ready - time-triggered @@ -63,13 +78,15 @@ fully_extracted_ailogs: --- ``` -`total_*` 计数器是**operator-maintained 的元数据**。drift 脚本不会自动更新它们 —— 它们位于 header 之中,使会话开始时的扫视就能看到注册表的脉搏,无需在 bucket 中翻页。`total_promoted` 在 schema v0.1 中固化(Sentinel adopter 的经验信号,fw-4.13.1),与现有的 `total_open` / `total_closed_in_session` / `total_phase_blocked` 模式保持一致。 +**自 v1 起,`total_*` 计数器为 CLI-owned。** 每个写入命令（`straymark followups drift --apply`、`straymark followups promote`）都会根据实际条目状态重新计算它们。不要手工维护它们 —— 陈旧的手工编辑值会在下一次写入时被纠正。这关闭了在 N=91 处观察到的静默计数器漂移失败模式（声明 `total_open: 47`,而 4 周后实际为 65 —— issue #214 信号 2）。`straymark followups status` 始终显示即时重新计算的计数,因此即便文件陈旧,脉搏也是可信的。 + +`fully_extracted_ailogs` 列表是漂移检测的**承重元数据**。所有 `§Follow-ups` 和 `R` 条目已被转移到注册表(或被显式分类为 superseded)的 AILOG 都属于此列表。漂移检测将此列表与 repo 中具有 follow-up 内容的 AILOG 进行比对。 -`fully_extracted_ailogs` 列表是 drift 检测的**承重元数据**。所有 `§Follow-ups` 和 `R` 条目已被转移到注册表(或被显式分类为 superseded)的 AILOG 都属于此列表。Drift 检测将此列表与 repo 中具有 follow-up 内容的 AILOG 进行比对。 +正式的 frontmatter schema 是 `.straymark/schemas/follow-ups-backlog.schema.v1.json`（实验性 v1 —— 见上方"状态"）。 ### Buckets -五个 bucket 按触发类型组织条目: +五个 bucket 按触发类型组织条目 —— *何时可执行*: - `ready` — 现在可执行,无外部触发器依赖。 - `time-triggered` — 基于日历的触发器(审计周期、周期性审查)。 @@ -77,27 +94,40 @@ fully_extracted_ailogs: - `phase-blocked` — 由尚不存在的未来组件或阶段阻塞。 - `operational` — 操作员手动决策或外部系统操作。 -### 条目 schema +在参考 adopter 的 N=91 个条目处,该词汇表是稳定的 —— 不需要第六个 bucket。Severity（*跳过它有多痛*）有意**不是**一个 bucket:它是一个正交的 per-entry 字段(见下文)。 + +### 条目 schema (v1) -bucket 内的每个条目遵循以下形式: +bucket 内的每个条目遵循以下形式（标注了 v1 字段;所有这些字段都是可选的 —— v0 条目仍然有效）: ```markdown ### FU-NNN — <简短描述> - **Origin**: AILOG-NNNN-NN-NN-NNN <指向源部分的指针> -- **Status**: open | in-progress | closed | superseded | promoted +- **Origin-class**: ex-ante-planning | testing | telemetry | staging | real-env-bug (v1, 可选) +- **Status**: open | in-progress | suspected-closed | closed | superseded | promoted +- **Severity**: normal | blocking (v1, 可选;默认 normal) - **Trigger**: ready | <日历日期> | when | <其他> -- **Destination**: +- **Destination**: chore | mini-charter | charter-replanning | operations | | - **Cost**: <工作量估计> +- **Labels**: <自由标签,逗号分隔> (v1, 可选) - **Notes**: <自由格式上下文> - **Promoted to**: ``` `FU-NNN` 在注册表整个生命周期内单调递增;条目关闭时不重新编号。 +**v1 维度**,每个都将一个经验观察到的需求规范化(issue #214): + +- **`Origin-class`** —— 条目的诞生地:规划工件（ex-ante,事前）vs 执行现实（testing、telemetry、staging、真实环境 bug）。使 ex-post 规划闭环可被查询。 +- **`Severity`** —— `blocking` 标记必须在生产切换之前落地的可靠性类问题。将参考 adopter 在 `Notes` 字段中浮现的 `PROD-BLOCKER` 散文约定规范化（信号 3）。与 bucket 正交:一个 `charter-triggered` 条目也可以是 `blocking`。 +- **`Labels`** —— 用于在 triage 期间将条目分组到已规划的 Charter / 迷你 Charter / 杂务中的自由标签。可通过 `straymark followups list --label ` 查询。 +- **`Destination` 词汇表** —— 形式化触发后工作落地的去向:`chore`、`mini-charter`、`charter-replanning`（该条目重塑一个已规划的 Charter,而不是向其添加一个任务）、`operations`、某个具体的 Charter id,或某个 TDE id。仍接受自由格式的值（宽松解析）。 + ### Status 词汇表 - `open` — 待处理,尚未采取行动。 - `in-progress` — 已声明或正在执行的 Charter 处理此条目。 +- `suspected-closed` *(v1 新增)* —— 由 `drift --apply` 从其文本携带显式关闭标记（`closed in-Charter`、`fixed in batch N`、某个 commit 哈希）的 AILOG 中自动提取。操作员在下一次 triage 时确认（→ `closed`）或重新打开（→ `open`）。见下方"漂移检测"。 - `closed` — 条目已解决(Charter 已合并、操作任务已完成、时间已过且已审查)。 - `superseded` — 由其他工作处理,该工作未直接引用此条目。 - `promoted` — 条目因满足横向债务标准而被提升为 TDE 文档(见下方"提升为 TDE")。`Promoted to:` 字段携带 TDE id。 @@ -117,9 +147,15 @@ closed、superseded 和 promoted 条目保留在文件中(可审计的历史)。 当上述任一条件成立时,将该 FU 条目提升为 `.straymark/06-evolution/technical-debt/` 下的 TDE 文档: -1. 通过 `/straymark-new tde`(或 `straymark new --type tde`)创建 TDE。从 FU 条目的上下文填入 `impact`、`effort`、`type` 与正文各节。 +```bash +straymark followups promote FU-NNN +``` + +该命令将 v0 中需手动执行的三步流程自动化: + +1. 创建 TDE 文档(与 `straymark new --type tde` 相同的机制),从 FU 条目预填 `impact`、`effort`、`type` 与正文上下文。 2. 在 TDE 的 frontmatter 中添加 `promoted_from_followup: FU-NNN` 以便溯源。 -3. 在 FU 条目中,设置 `Status: promoted`、`Destination: TDE-YYYY-MM-DD-NNN`,并添加 `Promoted to: TDE-YYYY-MM-DD-NNN`。如果你维护 `## Bucket: closed` 节,则将条目移过去;否则保持原位并更新状态。 +3. 在 FU 条目中,设置 `Status: promoted`、`Destination: TDE-YYYY-MM-DD-NNN`,以及 `Promoted to: TDE-YYYY-MM-DD-NNN`;并重新计算 frontmatter 计数器。 FU 条目在提升后**不会被删除** —— 它在注册表中的存在就是显示 TDE 来源的审计轨迹。 @@ -127,10 +163,10 @@ FU 条目在提升后**不会被删除** —— 它在注册表中的存在就 上述工作流涵盖**标准情况**:`open` 状态的 FU 条目已存在于注册表中,并在周期性审查期间被提升为 TDE。还有一种同样有效的情况,源自 Sentinel CHARTER-13 回顾的经验: -- **提升已存在条目** —— FU 数周或数个 Charter 之前已被(通常通过 `--apply`)登记为 `open`,经历过 ≥1 次 Charter 关闭仍未解决,并满足上述四项标准。标准流程。 +- **提升已存在条目** —— FU 数周或数个 Charter 之前已被(通常通过 `drift --apply`)登记为 `open`,经历过 ≥1 次 Charter 关闭仍未解决,并满足上述四项标准。标准流程。 - **创建时即追溯提升** —— 在回顾(Charter 关闭仪式、审计周期、RFC 撰写)*期间* 该债务被识别为值得作为 TDE,且从未作为 `open` FU 存在。先创建 TDE;在注册表中以 *`Status: promoted`* 状态新增一个 FU 条目,提供从 TDE 回溯到原始上下文(AILOG 中的某个 `R`、calibrator 的 finding、被延期的分类)的审计轨迹。 -两种形态在注册表中产生相同的终态:一个 `Status: promoted` 且具有 `Promoted to: TDE-YYYY-MM-DD-NNN` 指针的条目。区别在于条目是预先以 `open` 存在,还是天生即为 `promoted`。drift 脚本一视同仁(不按出生状态区分);统计 `total_promoted` 的 adopter 分析在两种情况下得到相同数字。 +两种形态在注册表中产生相同的终态:一个 `Status: promoted` 且具有 `Promoted to: TDE-YYYY-MM-DD-NNN` 指针的条目。区别在于条目是预先以 `open` 存在,还是天生即为 `promoted`。漂移检测一视同仁;统计 `total_promoted` 的分析在两种情况下得到相同数字。 存疑时,优先创建 FU 条目 —— 即便是追溯创建 —— 因为它会把 TDE 交叉引用回触发该识别的 AILOG / R-号 / 源上下文。一个 `promoted_from_followup: FU-NNN` 指向 backlog 中实际存在的条目的 TDE,比指向一个虚构的 FU 更易导航。 @@ -140,52 +176,62 @@ FU 条目在提升后**不会被删除** —— 它在注册表中的存在就 - **Charter 关闭** —— 在审查刚关闭的 Charter 所解决的条目时,如果发现*未*被解决且符合上述标准的条目,则提升它们,而不是保留为 `open`。 - **Charter 声明前** —— 如果你即将声明一个 Charter,并注意到注册表中包含此 Charter 仅会*部分*处理的条目,那么未处理的部分可能应作为 TDE,而不是作为另一个被延期的 FU。 -Drift 脚本(`scripts/check-followups-drift.sh`)在 v0 **不扩展**支持提升候选 —— 提升由操作员驱动。未来 v1 增强可标记符合"经历 ≥2 个 Charter"启发式的条目,但这等到第二个 adopter 验证模式后才会固化(与 v0 → v1 其余部分相同的门槛)。 - --- -## Drift 检测 +## 漂移检测 —— 自 cli-3.19.0 起原生 + +漂移检测使注册表与新 AILOG 保持同步。自 cli-3.19.0 起,它是一个**原生 CLI 命令** —— 无需外部脚本: -一个小的 bash 脚本是验证层,使注册表与新 AILOG 保持同步。该脚本位于 adopter 的 repo 中(建议路径:`scripts/check-followups-drift.sh`),有三种模式。 +```bash +straymark followups drift # 扫描 git diff origin/main..HEAD（回退 HEAD~1..HEAD）中修改的 AILOG;drift 时退出 1 +straymark followups drift --apply # 相同扫描 + 将新条目提取到注册表 +straymark followups drift --scan-all # 对每个 AILOG 的周期性完整扫描 +``` -### 模式 +### `--apply` 做什么 -- **默认** — 扫描 `git diff origin/main..HEAD`(回退到 `HEAD~1..HEAD`)中修改的 AILOG。对任何具有 `§Follow-ups` / `R (new)` 内容但不在 `fully_extracted_ailogs` 中的 AILOG 发出警告。drift 时退出 1。 -- **`--apply`** — 相同的扫描,但自动在 `## Bucket: ready` 下追加新条目,使用自动生成的 `FU-NNN` id,并将 AILOG id 追加到 `fully_extracted_ailogs`。操作员稍后将其重新分类到正确的 bucket。 -- **`--scan-all`** — 扫描项目中的每个 AILOG(周期性完整扫描)。 +1. 从尚未在 `fully_extracted_ailogs` 中的 AILOG 提取每个 `§Follow-ups` bullet 和 `R (new, not in Charter)` 风险,在 `## Bucket: ready` 下以自动生成的 `FU-NNN` id 追加。操作员在下一次 triage 时重新分类 bucket/trigger/destination。 +2. **反噪声精化** *(v1 —— 解决 issue #214 信号 1)*:其 AILOG 文本携带显式关闭标记（`closed in-Charter`、`fixed in batch N`、某个 commit 哈希引用）的 bullet 会以 `Status: suspected-closed` 而非 `open` 提取,而不是作为 TBD 噪声污染 `ready` bucket。在参考 adopter 的两次有记录的发生中,每批自动追加的条目中有 20–75% 已在 Charter 内解决 —— 此精化消除了 v0 工作流唯一反复出现的成本。 +3. 将 AILOG id 追加到 `fully_extracted_ailogs`。 +4. **根据实际条目状态重新计算所有 `total_*` 计数器**(信号 2)。 +5. 如果注册表为 `schema_version: v0`,则就地将其升级到 `v1` —— 非破坏性且幂等地(所有 v1 字段都是可选的;除版本标记和计数器外什么都不重写)。 ### Per-AILOG 与 per-bullet 粒度 -跟踪是 **per-AILOG**,而非 per-bullet。AILOG 要么被完全提取(其 id 在 `fully_extracted_ailogs` 中 — 信任注册表),要么未被提取(提取所有内容)。Per-bullet 匹配将需要指纹识别(文本哈希或模糊比较),每当注册表条目对 AILOG 的 bullet 进行改写时,这都会产生误报 — 而经过整理的条目总是会改写。 +跟踪是 **per-AILOG**,而非 per-bullet。AILOG 要么被完全提取(其 id 在 `fully_extracted_ailogs` 中 — 信任注册表),要么未被提取(提取所有内容)。Per-bullet 匹配将需要指纹识别(文本哈希或模糊比较),每当注册表条目对 AILOG 的 bullet 进行改写时,这都会产生误报 — 而经过整理的条目总是会改写。这个设计选择经过经验验证:在参考 adopter 中,**跨 76 个 AILOG 和约 10 次 apply 运行,0 个误报**。 -Per-AILOG 粒度的成本:当在 Charter 关闭后向已提取的 AILOG 添加 follow-up 时,drift 检测无法发现。修复由操作员驱动 — 手动从 `fully_extracted_ailogs` 中移除该 AILOG 并使用 `--apply` 重新运行。这种权衡对 v0 是有意为之,因为大多数 AILOG 在 Charter 关闭后是 write-once。 +Per-AILOG 粒度的成本:当在 Charter 关闭后向已提取的 AILOG 添加 follow-up 时,漂移检测无法发现。修复由操作员驱动 — 手动从 `fully_extracted_ailogs` 中移除该 AILOG 并使用 `--apply` 重新运行。这种权衡是有意为之,因为大多数 AILOG 在 Charter 关闭后是 write-once。 -### 脚本模板 +### 旧版 bash 脚本（已弃用） + +v0 参考实现（`scripts/check-followups-drift.sh`,Sentinel adopter repo 中约 296 行 POSIX bash）**自 cli-3.19.0 起已弃用**。它对 v0 注册表仍可工作,但不再维护,且缺少反噪声精化和计数器重新计算。迁移路径:删除该脚本,运行一次 `straymark followups drift --apply`(这同时将注册表升级到 v1),并更新任何 pre-commit hook 改为调用 CLI。 + +--- -参考实现(约 290 行 POSIX bash)位于 `StrangeDaysTech/sentinel` 的 `scripts/check-followups-drift.sh`。将其复制到你的 repo 并调整顶部常量: +## CLI 接口 ```bash -BACKLOG_FILE=".straymark/follow-ups-backlog.md" -AILOG_DIR=".straymark/07-ai-audit/agent-logs" +straymark followups list # 枚举条目:FU id、status、severity、bucket、destination +straymark followups list --bucket ready --status open --severity blocking --label +straymark followups status # 注册表脉搏:计数器(即时重新计算)、按 bucket/severity 细分 +straymark followups status FU-NNN # 单个条目的详情视图 +straymark followups drift [--apply|--scan-all] # 漂移检测(见上文) +straymark followups promote FU-NNN # 自动化 FU → TDE 提升(见上文) ``` -脚本仅使用 `awk` 和 `grep` — 没有 jq、yq 或重型依赖。在 Linux 和 macOS 之间可移植。 +注册表也在 `straymark explore` TUI 中作为一个合成的 **Follow-ups** 分组出现(每个 bucket 一个子节点),并在 `straymark status` 中作为一个计数块出现。 --- ## 代理集成 -代理(Claude / Gemini 等)成为注册表的主要维护者。添加到你的 `CLAUDE.md` / `AGENT.md`: +自 fw-4.21.0 起,代理指令**随 framework 一起发布**,位于 [`AGENT-RULES.md §13`](AGENT-RULES.md) —— adopter 不再将一个块复制到自己的 `CLAUDE.md` / `AGENT.md`。摘要如下: -```markdown -## Follow-ups backlog - -- **会话开始**: 浏览 `.straymark/follow-ups-backlog.md` 以了解项目中所有待处理事项。 -- **Pre-commit 检查**: 创建或修改了任何带有 `## Follow-ups` 或 `R (new, not in Charter)` 条目的 AILOG 吗? → 在同一个 commit 中运行 `scripts/check-followups-drift.sh --apply` 以扩展 backlog。 -- **Charter 关闭后**: 审查 Charter 解决的条目;将其标记为 `closed`(在 `Notes` 中带有关闭 Charter id)或 `superseded`。对于未解决但符合 TDE 标准的条目(先前 Charter 的遗留、横向、需要专用 Charter、需要人工优先级),将其提升为 TDE 文档(见本模式的"提升为 TDE"以及 `AGENT-RULES.md §3`)。 -``` +- **会话开始**:扫视 `.straymark/follow-ups-backlog.md`(或运行 `straymark followups status`)以了解项目中所有待处理事项。 +- **Pre-commit**:创建或修改了任何带有 `## Follow-ups` 或 `R (new, not in Charter)` 条目的 AILOG 吗? → 在同一个 commit 中运行 `straymark followups drift --apply`。 +- **Charter 关闭后**:审查 Charter 解决的条目;将其标记为 `closed`(在 `Notes` 中带有关闭 Charter id)或 `superseded`;确认或重新打开任何 `suspected-closed` 条目;通过 `straymark followups promote` 提升符合 TDE 标准的未解决条目。 -这使代理成为维护者,脚本成为验证层,操作员成为周期性审查者(重新分类、标记 closed、修剪 superseded、在符合标准时提升为 TDE)。 +这使代理成为注册表的主要维护者,CLI 成为验证层,操作员成为周期性审查者(重新分类、确认 suspected-closed、修剪 superseded、在符合标准时提升为 TDE)。 --- @@ -193,54 +239,56 @@ AILOG_DIR=".straymark/07-ai-audit/agent-logs" 对于从零开始的 adopter: -1. 创建 `.straymark/follow-ups-backlog.md`,使用上述 frontmatter(初始 `fully_extracted_ailogs:` 列表为空)和五个 `## Bucket: ` 标题。 -2. 将参考脚本从 `StrangeDaysTech/sentinel` 复制到 `scripts/check-followups-drift.sh`。如果你的 AILOG 位于其他位置,调整 `AILOG_DIR`。 -3. 运行 `scripts/check-followups-drift.sh --scan-all --apply` 从现有 AILOG 播种注册表。 -4. 手动将自动生成的 `## Bucket: ready` 条目重新分类到正确的 bucket。这是一次性 triage,对于约 50 个条目的 backlog 通常需要 30-60 分钟。 -5. 将代理集成块添加到 `CLAUDE.md` / `AGENT.md`。 -6. 可选地将 `scripts/check-followups-drift.sh` 接入 pre-commit hook 以进行硬性 enforcement。 +1. 将 `.straymark/templates/follow-ups-backlog.md` 复制到 `.straymark/follow-ups-backlog.md`(空的 `fully_extracted_ailogs:` 列表、五个 `## Bucket:` 标题)。 +2. 运行 `straymark followups drift --scan-all --apply` 从现有 AILOG 播种注册表。 +3. 手动将自动生成的 `## Bucket: ready` 条目重新分类到正确的 bucket;在能增加信号之处填写 `Origin-class`/`Severity`/`Labels`。这是一次性 triage,对于约 50 个条目的 backlog 通常需要 30-60 分钟。 +4. 完成 —— `AGENT-RULES.md §13` 中的代理指令已经生效;无需编辑 `CLAUDE.md`。 -对于从临时跟踪迁移的 adopter:相同的流程,但步骤 4 可能需要决定哪些条目已经是 `closed` 或 `superseded` — 该分类是使注册表有用的关键。 +对于从 v0 约定迁移的 adopter:运行一次 `straymark followups drift --apply`(自动将注册表升级到 v1),删除本地 bash 脚本,并更新任何 pre-commit hook 改为调用 CLI。 --- ## 参考实现 -`StrangeDaysTech/sentinel` CHARTER-12,于 2026-05-06 合并: +`StrangeDaysTech/sentinel` —— 起源 adopter: -- 实现 PR: [sentinel#53](https://github.com/StrangeDaysTech/sentinel/pull/53)(注册表 + 脚本 + CLAUDE.md 添加)。 -- 关闭 PR: [sentinel#54](https://github.com/StrangeDaysTech/sentinel/pull/54)(合并后验证 + Charter 关闭)。 - -经验上下文: 47 个条目从 CHARTER-08 → CHARTER-11 回顾中播种(约 30 分钟的多代理 triage)。该链条展示了激发该模式的差距 — 没有注册表,操作员无法在不孤立地重新分类每个 Charter 的 follow-ups 的情况下查看"项目中所有待处理事项"。有了注册表,会话开始时的浏览就是一次文件读取。 +- v0 模式:CHARTER-12,于 2026-05-06 合并（[sentinel#53](https://github.com/StrangeDaysTech/sentinel/pull/53)、[sentinel#54](https://github.com/StrangeDaysTech/sentinel/pull/54)）。从 CHARTER-08 → CHARTER-11 回顾播种了 47 个条目。 +- 规模验证:Etapa-3 后 triage 处于 **N=91 个 FU / 提取了 76 个 AILOG / 65 个 open**（[issue #214](https://github.com/StrangeDaysTech/straymark/issues/214)）—— 驱动 v1 schema 和原生 CLI 的经验输入（ADR-2026-06-03-001）。 --- ## 未决问题 -这些在 v0 中尚未解决。该模式的未来修订版本或 CLI helper 可能会处理它们: +在 v1 中已解决: + +- ~~**Schema 验证。**~~ → `.straymark/schemas/follow-ups-backlog.schema.v1.json`（frontmatter）、CLI 解析器中的条目形式验证。 +- ~~**作为 `straymark followups` CLI 的结晶化。**~~ → 自 cli-3.19.0 起原生 `list / status / drift / promote`。 +- ~~**Bucket 分类启发式**（部分）。~~ → `suspected-closed` 移除了主导的噪声类;完整的 bucket 建议（使用 AILOG `tags` / Charter `effort_estimate`）仍未解决。 + +仍为未来修订保留: -- **Bucket 分类启发式**。今天 `--apply` 将每个新条目转储到 `## Bucket: ready`;操作员手动重新分类。使用 AILOG `tags` 和 Charter `effort_estimate` 的启发式可以自动建议 bucket。 -- **Schema 验证**。注册表遵循一个隐式 schema;尚不存在 `.straymark/schemas/follow-ups-backlog.schema.v0.json`。今天的验证是人工审查。 - **与审计周期的集成**。当 `straymark charter audit --merge-reports` 产生未在关闭前原子修复的真实 debt findings 时,这些 findings 仅存在于 `.straymark/audits//review.md` 中。它们不会自动流入中央注册表。自动浮现它们将关闭一个已知差距。 - **`closed` 与 `superseded` 语义**。今天的差异在于解决工作是否显式引用了该条目。可能会出现更严格的约定。 -- **作为 `straymark followups` CLI 的结晶化**。一旦第二个 adopter 验证了该模式,framework 可以发布一个子命令,镜像现有的 `straymark charter` 三件套:`list` / `close` / `drift`。处于 v0 的 adopter(此模式)通过删除其本地脚本并切换代理指令进行迁移。 +- **与 `charter close` 的软集成**（issue #135 Tier 3）:在 Charter 关闭后自动调用 `followups drift --apply`,并带有交互式提升提示。以来自第二个 adopter 的摩擦信号为门槛。 +- **硬 schema 稳定化 (v1.0)**。以另一个领域的第二个 adopter 的验证为门槛,依据设计原则 #12。 --- ## 致谢 -通过 [issue #111](https://github.com/StrangeDaysTech/straymark/issues/111) 由 Sentinel adopter 贡献。经验基础:`StrangeDaysTech/sentinel` 中的 CHARTER-08 → CHARTER-11 链。作者：José Villaseñor Montfort。 +通过 [issue #111](https://github.com/StrangeDaysTech/straymark/issues/111) 由 Sentinel adopter 贡献;通过 [issue #214](https://github.com/StrangeDaysTech/straymark/issues/214) 和 ADR-2026-06-03-001 成熟为一等公民。经验基础:`StrangeDaysTech/sentinel` 中的 CHARTER-08 → CHARTER-11 链以及 Etapa-3 后 N=91 的 triage。作者:José Villaseñor Montfort。 -*本文档在生成式 AI 工具（Claude 4.7）的协助下撰写；内容的全部责任由人类作者承担。* +*本文档在生成式 AI 工具（Claude 4.7 / Opus 4.8）的协助下撰写；内容的全部责任由人类作者承担。* --- ## 相关 -- [EMERGENT-OBSERVATION-DESIGN.md](EMERGENT-OBSERVATION-DESIGN.md) —— 元模式，此漂移检测约定在每 AILOG ↔ 注册表表面实例化了它。 +- [EMERGENT-OBSERVATION-DESIGN.md](EMERGENT-OBSERVATION-DESIGN.md) —— 此漂移检测约定在每 AILOG ↔ 注册表表面实例化的元模式。 - [CHARTER-CHAIN-EVOLUTION.md](CHARTER-CHAIN-EVOLUTION.md) —— 在链级别（Pattern 1）和周期级别（Pattern 2）运作的姐妹模式。 -- [AGENT-RULES.md §3](AGENT-RULES.md) —— 可将 follow-ups 升级为专用债务条目的 TDE-vs-`R` 升级标准。 +- [AGENT-RULES.md §3](AGENT-RULES.md) —— 可将 follow-ups 提升为专用债务条目的 TDE-vs-`R` 升级标准;§13 —— 随框架发布的注册表维护代理指令。 +- `STRAYMARK.md §16` —— 注册表作为一等公民工件的入门级摘要。 --- -*StrayMark fw-4.19.0 | [Strange Days Tech](https://strangedays.tech)* +*StrayMark fw-4.22.0 | [Strange Days Tech](https://strangedays.tech)* diff --git a/.straymark/00-governance/i18n/zh-CN/QUICK-REFERENCE.md b/.straymark/00-governance/i18n/zh-CN/QUICK-REFERENCE.md index a3c10d1..2eb87da 100644 --- a/.straymark/00-governance/i18n/zh-CN/QUICK-REFERENCE.md +++ b/.straymark/00-governance/i18n/zh-CN/QUICK-REFERENCE.md @@ -67,6 +67,20 @@ Charter **不是**文档类型——它包裹一个跨多个会话的实施块 > 参见 `STRAYMARK.md` 第 15 节及 `.straymark/00-governance/SPECKIT-CHARTER-BRIDGE.md`，了解粒度启发式、生命周期与 SpecKit ↔ Charter 桥接。 +### 一等公民注册表 — Follow-ups Backlog *(fw-4.21.0+)* + +follow-ups backlog 同样**不是**文档类型 —— 它是一个单文件注册表,聚合跨 AILOG 的 `§Follow-ups` / `R (new)` 条目。条目 id 为 `FU-NNN`;按触发类型分为五个 bucket;状态为 `open | in-progress | suspected-closed | closed | superseded | promoted`。计数器为 CLI-owned。 + +| 概念 | 文件 | 代理自主权 | +|------|------|-----------| +| `Follow-ups registry` | `.straymark/follow-ups-backlog.md`（schema: `follow-ups-backlog.schema.v1.json`,实验性） | 代理通过 `followups drift --apply` 提取（pre-commit）;操作者拥有 triage 与提升批准 | + +```bash +straymark followups list / status / drift [--apply] / promote FU-NNN +``` + +> 参见 `STRAYMARK.md` 第 16 节、`FOLLOW-UPS-BACKLOG-PATTERN.md` 及 AGENT-RULES.md §13,了解随框架发布的代理指令。 + --- ## 何时编写文档 @@ -82,6 +96,7 @@ Charter **不是**文档类型——它包裹一个跨多个会话的实施块 | OTel 埋点变更 | AILOG + 标签 `observabilidad` | | 跨多个会话的实施块（>1 天，跨多个阶段 >5 个任务） | 声明一个 **Charter**（`straymark charter new`） | | 横向技术债务（先前 Charter 的遗留、横跨多个模块、需要专用 Charter、需要人工优先级） | **TDE** —— 与单 Charter 的 `R` 不同；参见 AGENT-RULES.md §3 | +| 创建或修改了带有 `## Follow-ups` 或 `R (new, not in Charter)` 条目的 AILOG | 在同一个 commit 中运行 `straymark followups drift --apply` —— 参见 AGENT-RULES.md §13 | **不要记录**：凭据、令牌、PII、机密信息。 @@ -141,7 +156,8 @@ risk_level: low | medium | high | critical ├── 08-security/ ← SEC ├── 09-ai-models/ ← MCARD ├── charters/ ← Charter（NN-slug.md + NN-slug.telemetry.yaml） -└── templates/ ← 模板（包括 charter/ 子目录） +├── follow-ups-backlog.md ← Follow-ups 注册表（FU-NNN 条目,自 fw-4.21.0 起为一等公民） +└── templates/ ← 模板（包括 charter/ 子目录 + follow-ups-backlog.md） ``` --- @@ -202,6 +218,7 @@ risk_level: low | medium | high | critical | `/straymark-ailog` / `/straymark-aidec` / `/straymark-adr` | AILOG / AIDEC / ADR 的快速快捷方式 | | `/straymark-mcard` / `/straymark-sec` | Model Card / SEC 评估的交互流程 | | `/straymark-charter-new` | 搭建一个 Charter（声明式事前工作单元） | +| `/straymark-followups` *(fw-4.22.0+)* | 维护 follow-ups backlog 注册表 —— “有什么待办？”、提交前 drift、关闭后分诊/promote | | `/straymark-audit-prompt CHARTER-XX` *(fw-4.9.0+，在 fw-4.9.0 中重构)* | 外部多模型审计 — 在规范路径写入统一 prompt | | `/straymark-audit-execute [CHARTER-XX]` *(fw-4.9.0+)* | 在审计员 CLI 中运行 — 读取 prompt，使用 tool use 审计，写入 report | | `/straymark-audit-review CHARTER-XX` *(fw-4.9.0+，在 fw-4.9.0 中扩展)* | 合并 N 个 reports 为 review.md（6 节）+ YAML 合并入遥测 | @@ -212,9 +229,9 @@ risk_level: low | medium | high | critical | 模式 | 文档 | |------|------| -| Follow-ups backlog(中央注册表 + drift 检测) *(fw-4.10.0+)* | [FOLLOW-UPS-BACKLOG-PATTERN.md](FOLLOW-UPS-BACKLOG-PATTERN.md) | +| Follow-ups backlog（一等公民注册表 + 原生 `followups` CLI） *(fw-4.10.0+,自 fw-4.21.0+ 起为一等公民)* | [FOLLOW-UPS-BACKLOG-PATTERN.md](FOLLOW-UPS-BACKLOG-PATTERN.md) | | Polish Charter 作为债务检测("声明了表层但未接线"反模式) *(fw-4.18.0+)* | [POLISH-CHARTER-PATTERN.md](POLISH-CHARTER-PATTERN.md) | --- -*StrayMark fw-4.20.0 | [Strange Days Tech](https://strangedays.tech)* +*StrayMark fw-4.22.0 | [Strange Days Tech](https://strangedays.tech)* diff --git a/.straymark/dist-manifest.yml b/.straymark/dist-manifest.yml index 5a7cec2..e4b445e 100644 --- a/.straymark/dist-manifest.yml +++ b/.straymark/dist-manifest.yml @@ -1,4 +1,4 @@ -version: 4.20.0 +version: 4.22.0 description: StrayMark distribution manifest files: - .straymark/ diff --git a/.straymark/schemas/follow-ups-backlog.schema.v1.json b/.straymark/schemas/follow-ups-backlog.schema.v1.json new file mode 100644 index 0000000..eaf71fb --- /dev/null +++ b/.straymark/schemas/follow-ups-backlog.schema.v1.json @@ -0,0 +1,129 @@ +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "$id": "https://straymark.dev/schemas/follow-ups-backlog.schema.v1.json", + "title": "StrayMark Follow-ups Backlog registry (experimental v1)", + "description": "Frontmatter schema for the central follow-ups registry (.straymark/follow-ups-backlog.md) — the single-file, first-class artifact that aggregates §Follow-ups and R (new, not in Charter) entries across AILOGs. The entry body (### FU-NNN blocks under ## Bucket: headers) is semi-structured markdown validated by shape in the CLI, not by this schema; the canonical entry field vocabulary is documented under $defs/entry for tooling and reference. See FOLLOW-UPS-BACKLOG-PATTERN.md for the full convention.", + "$comment": "EXPERIMENTAL v1. Crystallized from Sentinel CHARTER-12 → post-Etapa-3 triage (N=91 FUs, 76 AILOGs, 0 extraction false positives) plus issues #111/#135/#214 and ADR-2026-06-03-001. Hard stabilization (v1.0, breaking-change freeze) is gated on validation by a second adopter in another domain, per design principle #12. Adopters: avoid persisting tooling that depends on this exact shape; expect breaking changes between v1.x revisions. v0 registries remain readable forever (lenient parsing); the CLI upgrades them in place on the first write command.", + "type": "object", + "required": ["schema_version", "last_scan", "buckets", "fully_extracted_ailogs"], + "additionalProperties": true, + "properties": { + "schema_version": { + "type": "string", + "enum": ["v0", "v1"], + "description": "Registry schema version. v0 registries are read leniently and auto-upgraded to v1 (non-destructively, idempotently) by the first CLI write command (`followups drift --apply` or `followups promote`)." + }, + "last_scan": { + "type": "string", + "pattern": "^[0-9]{4}-[0-9]{2}-[0-9]{2}$", + "description": "Date (YYYY-MM-DD) of the last drift scan that touched this registry. Maintained by `straymark followups drift`." + }, + "last_scan_range": { + "type": "string", + "description": "Optional — first..last AILOG id covered by extraction, e.g. 'AILOG-2026-04-11-001..AILOG-2026-06-03-006'." + }, + "total_open": { + "type": "integer", + "minimum": 0, + "description": "Count of entries with Status: open. CLI-OWNED since v1: recomputed by every write command (`drift --apply`, `promote`). Do not maintain by hand — stale values are corrected on the next write (issue #214 Signal 2)." + }, + "total_promoted": { + "type": "integer", + "minimum": 0, + "description": "Count of entries with Status: promoted. CLI-owned since v1 (canonicalized in schema v0.1, fw-4.13.1)." + }, + "total_closed_in_session": { + "type": "integer", + "minimum": 0, + "description": "Count of entries closed since the last triage session. CLI-owned since v1." + }, + "total_phase_blocked": { + "type": "integer", + "minimum": 0, + "description": "Count of entries currently in the phase-blocked bucket. CLI-owned since v1." + }, + "total_suspected_closed": { + "type": "integer", + "minimum": 0, + "description": "Count of entries with Status: suspected-closed (new in v1 — auto-extracted entries whose source AILOG carries an in-Charter closure marker). CLI-owned." + }, + "buckets": { + "type": "array", + "items": { + "type": "string", + "enum": ["ready", "time-triggered", "charter-triggered", "phase-blocked", "operational"] + }, + "minItems": 1, + "uniqueItems": true, + "description": "Bucket vocabulary in use. The five canonical buckets organize entries by trigger type (when actionable). Stable at N=91 entries in the reference adopter — no sixth bucket has been needed." + }, + "fully_extracted_ailogs": { + "type": "array", + "items": { + "type": "string", + "pattern": "^AILOG-[0-9]{4}-[0-9]{2}-[0-9]{2}-[0-9]{3}[a-z]?(-[a-z0-9-]+)?$" + }, + "uniqueItems": true, + "description": "Load-bearing metadata for drift detection. Every AILOG whose §Follow-ups and R entries have been transferred into the registry (or explicitly classified as superseded) belongs in this list. Per-AILOG granularity — not per-bullet — is the empirically validated design choice (0 false positives across 76 AILOGs in the reference adopter)." + } + }, + "$defs": { + "entry": { + "$comment": "Documentation of the markdown entry shape (### FU-NNN blocks). NOT validated by this JSON schema — the CLI parses these fields leniently from the registry body. Listed here as the canonical vocabulary for tooling (Loom node model, future validators).", + "type": "object", + "properties": { + "fu_id": { + "type": "string", + "pattern": "^FU-[0-9]{3,}$", + "description": "Monotonically increasing across the registry's lifetime; never renumbered when entries close." + }, + "origin": { + "type": "string", + "description": "Pointer to the source AILOG section, e.g. 'AILOG-2026-06-03-003 §R3 (new, not in Charter)'." + }, + "origin_class": { + "type": "string", + "enum": ["ex-ante-planning", "testing", "telemetry", "staging", "real-env-bug"], + "description": "NEW in v1 (optional). Where the follow-up was born: ex-ante planning artifacts vs ex-post execution reality (test runs, telemetry readings, staging incidents, bugs observed in real — non-simulated — environments). This dimension makes the registry queryable as the ex-post counterpart of SpecKit for Charter planning." + }, + "status": { + "type": "string", + "enum": ["open", "in-progress", "suspected-closed", "closed", "superseded", "promoted"], + "description": "Entry lifecycle. NEW in v1: suspected-closed — assigned by `drift --apply` instead of open when the source AILOG text carries an explicit closure marker ('closed in-Charter', 'fixed in batch N', a commit hash); the operator confirms (→ closed) or reopens (→ open) at the next triage. Resolves the recurring extractor-noise pattern (issue #214 Signal 1)." + }, + "severity": { + "type": "string", + "enum": ["normal", "blocking"], + "description": "NEW in v1 (optional, default normal). How much it hurts to skip — orthogonal to the bucket (when actionable). 'blocking' canonicalizes the PROD-BLOCKER prose convention that emerged in the reference adopter (issue #214 Signal 3): reliability-class issues that must land before a production cutover." + }, + "trigger": { + "type": "string", + "description": "ready | | when | . Free-text observable condition that makes the entry actionable." + }, + "destination": { + "type": "string", + "description": "NEW vocabulary in v1: chore | mini-charter | charter-replanning | operations | | . Formalizes where the work lands when triggered — including 'charter-replanning' for entries that reshape an already-planned Charter rather than adding a task to it. Free-form values remain accepted (lenient)." + }, + "cost": { + "type": "string", + "description": "Effort estimate, free-form (e.g. 'M (~2-3h: 2 integ tests following the existing pattern)')." + }, + "labels": { + "type": "array", + "items": {"type": "string"}, + "description": "NEW in v1 (optional). Free tags for grouping entries into planned Charters / mini-charters / chores during triage (e.g. 'staging-hardening, auth'). Queryable via `straymark followups list --label `." + }, + "notes": { + "type": "string", + "description": "Free-form context, including reclassification provenance ('Reclassified from ready (auto-appended TBD) by ')." + }, + "promoted_to": { + "type": "string", + "pattern": "^TDE-[0-9]{4}-[0-9]{2}-[0-9]{2}-[0-9]{3}.*$", + "description": "TDE id, present when Status: promoted. The TDE's frontmatter carries the reverse pointer (promoted_from_followup: FU-NNN)." + } + }, + "required": ["fu_id", "origin", "status"] + } + } +} diff --git a/.straymark/templates/follow-ups-backlog.md b/.straymark/templates/follow-ups-backlog.md new file mode 100644 index 0000000..227c982 --- /dev/null +++ b/.straymark/templates/follow-ups-backlog.md @@ -0,0 +1,48 @@ +--- +last_scan: YYYY-MM-DD +schema_version: v1 +total_open: 0 +total_promoted: 0 +total_closed_in_session: 0 +total_phase_blocked: 0 +total_suspected_closed: 0 +buckets: + - ready + - time-triggered + - charter-triggered + - phase-blocked + - operational +fully_extracted_ailogs: [] +--- + +# Follow-ups Backlog + +> Central registry of `§Follow-ups` and `R (new, not in Charter)` entries across AILOGs. +> Maintained by `straymark followups drift --apply`; counters are CLI-owned. +> Convention: `.straymark/00-governance/FOLLOW-UPS-BACKLOG-PATTERN.md` · +> Schema: `.straymark/schemas/follow-ups-backlog.schema.v1.json` + + + +## Bucket: ready + +## Bucket: time-triggered + +## Bucket: charter-triggered + +## Bucket: phase-blocked + +## Bucket: operational diff --git a/STRAYMARK.md b/STRAYMARK.md index 0dbeebd..b9a6da9 100644 --- a/STRAYMARK.md +++ b/STRAYMARK.md @@ -454,6 +454,49 @@ The command does not touch git — the operator decides when to commit. The `str --- +## 16. Follow-ups backlog — the pending-work registry *(fw-4.21.0+)* + +The **follow-ups backlog** is StrayMark's first-class artifact for *deferred work that outlives the AILOG that recorded it*. Every AILOG documents what is deferred in its `§Follow-ups` section and its `R (new, not in Charter)` risks; past ~20 AILOGs that dispersed knowledge stops being scannable from memory. The registry aggregates it into a single queryable file. + +Like Charters (section 15), the registry is **conceptually distinct** from the 12+4 document types of section 13: + +- It lives at `.straymark/follow-ups-backlog.md` — one file per project, never one file per entry. +- Entries (`FU-NNN`) are organized in five buckets by trigger type (*when actionable*): `ready`, `time-triggered`, `charter-triggered`, `phase-blocked`, `operational`. +- Entry statuses: `open` → `in-progress` → `closed` / `superseded` / `promoted`, plus `suspected-closed` for auto-extracted entries whose source AILOG carries a closure marker. +- Frontmatter counters (`total_open`, …) are **CLI-owned** — recomputed on every write command; never maintain them by hand. + +### Why it matters beyond tracking + +Follow-ups originate not only from planning (ex-ante) but from **execution reality** — test runs, telemetry, staging incidents, real-environment bugs — and they feed planning back: entries become chores, mini-charters, or reshape already-planned Charters (`Destination: charter-replanning`). The registry is the ex-post counterpart of SpecKit. The v1 entry dimensions (`Origin-class`, `Severity: blocking`, `Labels`) exist to make that planning loop queryable. + +### Lifecycle + +| Stage | What happens | CLI | +|-------|--------------|-----| +| **Extraction** | New AILOG with `§Follow-ups` / `R (new)` content → entries auto-extracted into `## Bucket: ready` (or `suspected-closed` when the AILOG text marks them resolved in-Charter). | `straymark followups drift --apply` | +| **Triage** | Operator reclassifies bucket/trigger/destination, fills `Severity`/`Labels`, confirms or reopens `suspected-closed` entries. Typically once per stage close (~1h per 4-8 Charters at reference-adopter scale). | (manual edit + `followups list`) | +| **Consumption** | Entries feed Charter planning; when a Charter addresses an entry, mark `in-progress` → `closed` with provenance in `Notes`. | (manual edit) | +| **Promotion** | Entries meeting the transversal-debt criteria (AGENT-RULES.md §3) are elevated to a TDE document with full traceability. | `straymark followups promote FU-NNN` | + +### How it relates to existing artifacts + +- It **does not replace** per-AILOG `§Follow-ups` — that convention stays; the registry aggregates it. Per-AILOG extraction granularity (the `fully_extracted_ailogs` frontmatter list) is the load-bearing design choice. +- It **feeds** Charters and TDEs: `Destination:` points at where the work lands; `straymark followups promote` creates the TDE with `promoted_from_followup: FU-NNN` traceability. +- Agent directives (session-start glance, pre-commit drift, post-close review) ship in `AGENT-RULES.md §13`. + +### Quick CLI surface + +```bash +straymark followups list # enumerate entries (filters: --bucket, --status, --severity, --label) +straymark followups status [FU-NNN] # registry pulse (counters recomputed on the fly) / entry detail +straymark followups drift [--apply|--scan-all] # detect/extract AILOGs not yet in the registry +straymark followups promote FU-NNN # automate FU → TDE promotion +``` + +> **Schema**: `.straymark/schemas/follow-ups-backlog.schema.v1.json` — experimental v1; hard stabilization gated on a second adopter (Principle #12, ADR-2026-06-03-001). Full convention: `.straymark/00-governance/FOLLOW-UPS-BACKLOG-PATTERN.md`. Template: `.straymark/templates/follow-ups-backlog.md`. + +--- + ## Directive Injection Markers StrayMark uses HTML comment markers to manage injected content in agent configuration files (`AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, `.github/copilot-instructions.md`, `.cursorrules`, `.cursor/rules/straymark.md`):