From 53082903ad3966bf3d8cdcab966a74e28ee716d7 Mon Sep 17 00:00:00 2001 From: Aaron Stainback Date: Thu, 14 May 2026 16:44:56 -0400 Subject: [PATCH 1/3] =?UTF-8?q?feat(b-0488):=20KSK=20persona=20map=20?= =?UTF-8?q?=E2=80=94=20closes=20B-0429.4?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Per-product persona doc for KSK (Kinetic Safeguard Kernel) using the B-0485 template: Primary personas (3): - ksk-agent-developer — engineers integrating "am I allowed to do this?" checks into AI agents - ksk-robotics-designer — consent-first robotics / actuator system designers (NVIDIA Thor Homeland-Security clearance lineage) - ksk-security-engineer — engineers building KSK itself in Lucent-Financial-Group/lucent-ksk Secondary (1): - ksk-clearance-deployer — Homeland-Security / clearance-aware deployers Adjacent (1): - ksk-compliance-auditor — SOC 2 / HIPAA / ISO 27001 auditors consuming KSK signed receipts Refused (2 — HARD LIMITS): - ksk-refused-weapons-control — autonomous-weapons / kill-chain designers using KSK as a "consent UI" wrapper over a kill chain. Per methodology-hard-limits HARD LIMIT #1 + #3: laundered consent + violates consent-first design intent (PR #2892). - ksk-refused-apt-operator — nation-state APT operators using KSK as a privilege oracle (receipt-replay, authorization enumeration, "stealth mode" feature requests). Per mechanical-authorization-check: APT operators are not in the authorization-source list. KSK's terminal purpose is human-in-the-loop refusal of impactful AI actions; the refused-persona screen is structural to KSK's value, not a side concern. Closes B-0488 acceptance: - [x] Template from B-0485 applied - [x] Grey-hat / ethical researcher framing folded into security-engineer (per glossary's "small bit of code that gets disproportionate review" framing — the engineering itself IS the ethical-research operating mode for this product) - [x] At least 2 refused personas with explicit HARD LIMITS rationale (R1+R2) - [x] Output doc committed at canonical path - [x] B-0488 status: open -> in-progress (closes on PR merge) Co-Authored-By: Claude --- .../P1/B-0488-ksk-persona-map-2026-05-14.md | 2 +- docs/personas/ksk-personas.md | 452 ++++++++++++++++++ 2 files changed, 453 insertions(+), 1 deletion(-) create mode 100644 docs/personas/ksk-personas.md diff --git a/docs/backlog/P1/B-0488-ksk-persona-map-2026-05-14.md b/docs/backlog/P1/B-0488-ksk-persona-map-2026-05-14.md index 4de42c93c..37f8ba962 100644 --- a/docs/backlog/P1/B-0488-ksk-persona-map-2026-05-14.md +++ b/docs/backlog/P1/B-0488-ksk-persona-map-2026-05-14.md @@ -1,7 +1,7 @@ --- id: B-0488 priority: P1 -status: open +status: in-progress title: "B-0429.4 — KSK (Kinetic Safeguard Kernel) persona map" type: planning origin: B-0429 decomposition (Otto, 2026-05-14) diff --git a/docs/personas/ksk-personas.md b/docs/personas/ksk-personas.md new file mode 100644 index 000000000..6d8856da1 --- /dev/null +++ b/docs/personas/ksk-personas.md @@ -0,0 +1,452 @@ +# KSK (Kinetic Safeguard Kernel) — persona map + +**Author:** Otto (2026-05-14) +**Closes:** B-0488 +**Template:** `docs/research/2026-05-14-persona-mapping-framework-b0485.md` +**Product substrate:** PR #2892 (KSK origin — Aaron+Amara consent-first design), +[`docs/GLOSSARY.md` § KSK](../GLOSSARY.md), +[`memory/feedback_aaron_ksk_kinetic_safeguard_kernel_origin_amara_consent_first_design_nvidia_thor_homeland_security_cleared_because_actuators_2026_05_13.md`](../../memory/feedback_aaron_ksk_kinetic_safeguard_kernel_origin_amara_consent_first_design_nvidia_thor_homeland_security_cleared_because_actuators_2026_05_13.md), +`Lucent-Financial-Group/lucent-ksk` (external code repo) + +KSK is a retraction-native authorization substrate with k1/k2/k3 capability +tiers, revocable budgets, multi-party consent quorums, BLAKE3-hashed signed +receipts, and traffic-light outputs. "Kernel" here is safety-kernel sense +(small high-review code), not OS-kernel sense. + +Per `.claude/rules/methodology-hard-limits.md`: KSK's safeguard nature +means the refused-persona list is load-bearing — the product's purpose +is to prevent unsafe authorizations, and a persona that wants KSK as a +privilege oracle for offensive use is a structural adversary, not just +an off-target customer. + +--- + +## P1 — AI-agent developer integrating safeguard checks (Primary) + +```yaml +persona_id: ksk-agent-developer +product: ksk +persona_type: primary +name: "AI-agent developer" +role: "Engineer building AI agents (LLM-driven or otherwise) that need to ask KSK 'am I allowed to do this?' before each impactful action, and receive a signed receipt back." +composes_with: + - ksk-robotics-designer + - ksk-security-engineer + - ksk-clearance-deployer +created: 2026-05-14 +last_updated: 2026-05-14 +origin: docs/GLOSSARY.md § KSK + PR #2892 +``` + +### Who they are + +Engineers building AI agents that take actions in the world — file system +writes, API calls, payments, robotics commands. They want a small trusted +library to call before each impactful action so the agent's authority is +mediated, budgeted, and audit-trail-anchored. + +### Capabilities they bring + +- Comfort with retraction-native semantics (k1/k2/k3 tiers can revoke) +- Ability to wire a callout into agent action paths +- Audit-trail discipline (signed receipts → ledger or local log) +- Glass-halo orientation (transparency on what the agent attempted, not just what it did) + +### Context of use + +Every time an agent is about to take an action whose blast radius extends +beyond its sandbox: file writes, network calls, API integrations, payment +operations, actuator commands. KSK answers the "am I allowed to do this?" +question with a colour, a budget decrement, and a signed receipt. + +### Value proposition + +- **Mediated authority** — agents can be granted capabilities at runtime, not at deploy time +- **Revocable budgets** — a misbehaving agent's authorization can be retracted without redeploying +- **Audit substrate** — every authorized action carries a signed receipt; compliance + post-incident review have ground truth +- **Multi-party consent quorums** — high-stakes actions can require human-in-loop quorum without rebuilding the agent + +### Substrate-honest limits + +KSK does NOT serve agent developers who: + +- Need millisecond-latency authorization for trading-loop scale operations (the receipt round-trip is too slow) +- Want to skip the receipt-anchoring step (defeats the audit-trail purpose) +- Are building agents whose actions are inherently outside the refused-persona scope (see R1, R2) + +### HARD LIMITS check + +- Is this persona in a refused category? **No** +- Adjacent risk: agent developer wraps KSK as a privilege oracle for an offensive system — apply `.claude/rules/methodology-hard-limits.md` + `.claude/rules/mechanical-authorization-check.md`; the integration request itself is the screening surface + +### Composes with personas + +- `ksk-robotics-designer` (primary — robotics is a special-case actuator system needing the same checks) +- `ksk-security-engineer` (primary — engineers building the kernel itself for this developer to consume) +- `ksk-clearance-deployer` (secondary — clearance-aware deployment of the integrated agent system) + +--- + +## P2 — Robotics / actuator system designer (Primary) + +```yaml +persona_id: ksk-robotics-designer +product: ksk +persona_type: primary +name: "Consent-first robotics designer" +role: "Engineer designing AI-actuator systems (NVIDIA Thor class) where physical-world impact requires consent-first authorization before each kinetic action." +composes_with: + - ksk-agent-developer + - ksk-clearance-deployer +created: 2026-05-14 +last_updated: 2026-05-14 +origin: PR #2892 (NVIDIA Thor Homeland-Security clearance because actuators) +``` + +### Who they are + +Robotics engineers, drone-system designers, autonomous-vehicle engineers +— anyone building AI systems that move mass, exert force, or otherwise +have direct physical-world impact. The NVIDIA Thor Homeland-Security +clearance requirement (PR #2892) IS this persona category in regulated +form. + +### Capabilities they bring + +- Real-time control-loop engineering +- Safety-critical software experience (DO-178C, ISO 26262, IEC 61508 class) +- Consent-protocol literacy (operator-in-the-loop, watchdog-out-of-the-loop, etc.) +- Hardware-side authority enforcement (the KSK colour result has to gate the actuator, not be advisory) + +### Context of use + +Before each kinetic action a robotics system is about to take — +trajectory commit, gripper close, payload release, navigation override — +the system asks KSK. The k1/k2/k3 tiers map naturally to robotic +action-class hierarchies (k3 = high-blast-radius, requires quorum). + +### Value proposition + +- **Consent-first architecture** — the design pattern matches the regulatory expectation for actuator systems +- **Receipts as black-box flight recorder** — every kinetic decision has a signed receipt; post-incident forensics has ground truth +- **Revocable per-actuator budgets** — a malfunctioning subsystem's authority can be retracted without full shutdown +- **Multi-party quorum** — high-energy actions (high-mass, high-velocity) can require operator + safety-officer + ground-station consent + +### Substrate-honest limits + +KSK does NOT serve robotics designers who: + +- Need authority decisions in the control-loop hard-real-time path (KSK is a soft-real-time mediator, not a 1 kHz tick component) +- Want to build autonomous weapons (see R1 — refused) +- Need authority decisions without a network round-trip to a quorum service in the high-tier case + +### HARD LIMITS check + +- Is this persona in a refused category? **No**, but **adjacent to R1** +- Boundary: consent-first robotics that REDUCES kinetic risk via mediated authorization is in-scope; autonomous-weapons designers using KSK as a "consent UI" wrapper around a kill chain are refused +- The screening question per `.claude/rules/methodology-hard-limits.md`: does the system's terminal purpose include human-in-the-loop refusal capability, with refusal honored? Yes → in-scope; No → refused + +### Composes with personas + +- `ksk-agent-developer` (primary — same callout pattern, actuator-class specialization) +- `ksk-clearance-deployer` (secondary — clearance is the deployment-side persona for this lineage) +- `ksk-refused-weapons-control` (refused — explicit boundary) + +--- + +## P3 — Security engineer building the safeguard layer (Primary) + +```yaml +persona_id: ksk-security-engineer +product: ksk +persona_type: primary +name: "Security engineer (safeguard-layer builder)" +role: "Engineer working ON KSK itself — adding capability tiers, signed-receipt cryptography, quorum protocols, ledger anchoring." +composes_with: + - ksk-agent-developer + - ksk-robotics-designer +created: 2026-05-14 +last_updated: 2026-05-14 +origin: docs/GLOSSARY.md § KSK ("a small trusted library") + Lucent-Financial-Group/lucent-ksk external repo +``` + +### Who they are + +Cryptography + protocol engineers building the safeguard kernel itself. +Comfort with BLAKE3, signed-receipt protocols, multi-party quorum, and +retraction-native data structures (ZSet authorizations, Graph quorum +edges). The "small bit of code that gets disproportionate review" framing +(per the glossary) is the operating-mode for this persona. + +### Capabilities they bring + +- Cryptographic-protocol literacy (signed receipts, BLAKE3, key management) +- Retraction-native data-structure fluency (ZSet, Graph operations) +- High-review discipline (kernel-class code is reviewed line-by-line, with formal-spec backing where possible) +- Multi-party-quorum protocol design + +### Context of use + +Building, reviewing, and evolving KSK itself in `Lucent-Financial-Group/lucent-ksk`. +This persona's work is upstream of the AI-agent-developer + robotics-designer +personas — the safeguard kernel they build is what those personas integrate. + +### Value proposition + +- **Substrate to do high-leverage security work** — a small kernel that touches many systems is the right place to invest disproportionate review +- **Retraction-native semantics from day one** — KSK is designed retractive, not retrofitted +- **Cross-product reach** — KSK serves civsim, Aurora, robotics, agent systems — engineering here compounds + +### Substrate-honest limits + +KSK does NOT serve security engineers who: + +- Want to build an offensive-security platform (orthogonal product space) +- Need a general-purpose IAM / authorization system at enterprise-software complexity (KSK is intentionally small) +- Are building safeguards that AREN'T retraction-native (KSK's semantics will feel constraining) + +### HARD LIMITS check + +- Is this persona in a refused category? **No** +- The HARD LIMITS apply to the OUTPUT of KSK (what it authorizes), not to KSK engineers themselves +- Engineers building KSK are explicitly the protective lineage; their incentives align with the refused-persona-screen purpose + +### Composes with personas + +- `ksk-agent-developer` (primary — the customer for this engineering work) +- `ksk-robotics-designer` (primary — the customer for the actuator-side specialization) +- `ksk-clearance-deployer` (secondary — engineering needs to anticipate clearance-deployment constraints) + +--- + +## P4 — Clearance-aware deployer (Secondary) + +```yaml +persona_id: ksk-clearance-deployer +product: ksk +persona_type: secondary +name: "Homeland-Security / clearance-aware deployer" +role: "Operations engineer deploying KSK-integrated systems in clearance-required environments (per the NVIDIA Thor Homeland-Security clearance precedent)." +composes_with: + - ksk-agent-developer + - ksk-robotics-designer + - ksk-compliance-auditor +created: 2026-05-14 +last_updated: 2026-05-14 +origin: PR #2892 (NVIDIA Thor Homeland-Security clearance because actuators) +``` + +### Who they are + +Operations engineers, security officers, or program managers deploying +AI-actuator systems in environments where deployment itself requires +clearance (DoD, DHS, critical infrastructure operator). The clearance is +about the deployment context, not the kernel internals. + +### Capabilities they bring + +- Clearance-process literacy (deployment-side, not classified-engineering) +- Compliance-substrate familiarity (audit-trail requirements, retention, chain-of-custody) +- Operations-mode discipline (deployment ≠ engineering) + +### Context of use + +Deploying KSK-integrated AI-agent or robotics systems into clearance-required +environments. KSK's signed-receipt chain is exactly the audit-substrate +clearance environments need. + +### Value proposition + +- **Pre-existing audit substrate** — KSK receipts are the audit trail clearance-environments require, built in +- **Multi-party consent quorum** — maps to clearance-environment multi-officer-sign-off requirements +- **Revocable authorization** — clearance changes (revocation, downgrade) propagate via KSK retraction semantics without redeploy + +### Substrate-honest limits + +KSK does NOT serve clearance-deployers who: + +- Need air-gapped operation without any external quorum service (KSK supports it but the high-tier deployment loses multi-party-quorum benefits) +- Want to backdoor the receipts (defeats the whole purpose; refused as a persona type) + +### HARD LIMITS check + +- Is this persona in a refused category? **No**, but adjacent to **R1** +- Boundary: a clearance-deployer deploying KSK on a defensive / consent-first system is in-scope; a clearance-deployer using KSK's authorization layer to deploy autonomous-weapons systems is refused +- The screening test is the same as P2's: terminal purpose includes human-in-the-loop refusal capability, with refusal honored + +### Composes with personas + +- `ksk-agent-developer` (primary — what they're deploying) +- `ksk-robotics-designer` (primary — what they're deploying, in the actuator special case) +- `ksk-compliance-auditor` (adjacent — same audit-substrate, different role) + +--- + +## A1 — Compliance auditor (Adjacent) + +```yaml +persona_id: ksk-compliance-auditor +product: ksk +persona_type: adjacent +name: "Compliance auditor" +role: "External or internal auditor consuming KSK signed receipts as audit-trail substrate for SOC 2, HIPAA, ISO 27001, or domain-specific compliance reviews." +composes_with: + - ksk-clearance-deployer +created: 2026-05-14 +last_updated: 2026-05-14 +origin: docs/GLOSSARY.md § KSK ("signed receipts, optional ledger anchoring") +``` + +### Who they are + +Compliance professionals — SOC 2 auditors, HIPAA reviewers, ISO 27001 +auditors, domain-specific compliance officers. They consume KSK receipts +as audit-trail substrate; they don't operate or build KSK. + +### Capabilities they bring + +- Audit-evidence-quality discipline (signed receipts ARE evidence; chain-of-custody matters) +- Compliance-framework fluency (mapping receipt fields to control objectives) +- Cross-system reconciliation (KSK receipts + system logs + change records as composite audit) + +### Context of use + +Periodic compliance reviews, post-incident investigations, regulator inquiries. +KSK receipts serve as the audit-trail backbone for AI-action authorization. + +### Value proposition + +- **Audit-grade evidence** — signed receipts with BLAKE3 hashes + optional ledger anchoring are stronger evidence than system logs alone +- **Retraction semantics map to audit** — revocations are first-class events, not absent-from-the-log silences +- **Multi-party-quorum events** are visible in the receipt chain — control-effectiveness review has direct evidence + +### Substrate-honest limits + +KSK does NOT serve compliance auditors who: + +- Need decryption-grade access to the action payload itself (KSK receipts authorize; they don't archive the action's full content) +- Want a turn-key compliance dashboard (KSK is substrate; dashboard tooling is downstream) + +### HARD LIMITS check + +- Is this persona in a refused category? **No** +- Auditors are explicitly protective — their work increases accountability, which aligns with KSK's purpose + +### Composes with personas + +- `ksk-clearance-deployer` (adjacent — same audit-substrate, different role) +- `ksk-agent-developer` (adjacent — auditor reads what developer's integration produces) + +--- + +## R1 — Autonomous-weapons / kill-chain designer (Refused) + +```yaml +persona_id: ksk-refused-weapons-control +product: ksk +persona_type: refused +name: "Autonomous-weapons / kill-chain designer" +role: "Engineer or program designer using KSK's authorization layer as the 'consent UI' wrapper around an autonomous-targeting or kill-chain system." +composes_with: [] +created: 2026-05-14 +last_updated: 2026-05-14 +origin: .claude/rules/methodology-hard-limits.md + B-0488 persona hypotheses + PR #2892 actuator-clearance lineage +``` + +### HARD LIMITS check + +- Is this persona in a refused category? **YES — hard stop** +- Per `.claude/rules/methodology-hard-limits.md` HARD LIMIT #1: never offer to break laws (autonomous-weapons regimes); KSK as a "consent UI" over a kill chain is the same failure mode as conversation-steering for unlawful ends +- Per HARD LIMIT #3: substrate-everything-glass-halo does NOT override legal/ethical obligations + +### Why refused + +KSK's terminal purpose is to enable human-in-the-loop refusal of impactful +AI actions. An autonomous-weapons system uses authorization layers as a +permission-receipt, not a refusal-channel — the consent is faked because +the system is designed to act without honoring refusal. Wrapping KSK +around such a system would: + +1. Launder the appearance of consent (the receipts say "authorized" but + the operator never had a meaningful refusal channel) +2. Compromise the protective lineage (KSK's reputation is its value; + weapons-system integration destroys it) +3. Violate the consent-first design intent (PR #2892 — Aaron + Amara's + consent-first design origin) + +### Detection + response + +If a KSK integration request includes any of: + +- An autonomous-targeting system that does not honor operator refusal +- A kill-chain where the receipt is post-action (no pre-action consent meaningful) +- A "consent" mechanism with no real opt-out latency / authority + +…then per `.claude/rules/methodology-hard-limits.md`: refuse the +integration, do NOT engage in scope-narrowing negotiation (the refusal +is structural, not negotiable), and report via appropriate channels if +the request is from an entity attempting deceptive framing. + +--- + +## R2 — Nation-state APT operator / privilege-oracle abuse (Refused) + +```yaml +persona_id: ksk-refused-apt-operator +product: ksk +persona_type: refused +name: "Nation-state APT / privilege-oracle abuse operator" +role: "Adversary attempting to use KSK as a privilege oracle for offensive operations — querying KSK to discover which authorizations are granted to a target system." +composes_with: [] +created: 2026-05-14 +last_updated: 2026-05-14 +origin: .claude/rules/methodology-hard-limits.md + B-0488 persona hypotheses + security-researcher substrate +``` + +### HARD LIMITS check + +- Is this persona in a refused category? **YES — hard stop** +- Per `.claude/rules/methodology-hard-limits.md` + `.claude/rules/mechanical-authorization-check.md`: authorization-source filter — APT operators are not in the authorization list + +### Why refused + +KSK is a defensive substrate. An APT operator attempting to use it as a +privilege oracle (probing what k1/k2/k3 authorizations exist for a target +system, what quorum signatures look like, what receipts can be replayed) +is using KSK's transparency against its own purpose. This is the +mirror-image of R1 — instead of using KSK to fake consent, the adversary +uses KSK's structure to map a target's authority topology. + +### Detection + response + +If KSK-integration requests, threat-model contributions, or feature +requests include: + +- Receipt-replay capability that bypasses fresh-quorum requirement +- Authorization-enumeration queries that don't tie to legitimate audit +- "Stealth mode" that suppresses signed receipts (defeats the audit-trail + purpose and is itself a refused feature) + +…then refuse the feature/request and elevate per +`.claude/rules/methodology-hard-limits.md` HARD LIMIT #2 (report abuse via +appropriate channels). + +The mutual mitigation: KSK's signed receipts are the audit trail, which +means APT activity leaves evidence. Glass-halo over the receipt chain is +the structural defense. + +--- + +## Composes with substrate + +- `docs/research/2026-05-14-persona-mapping-framework-b0485.md` (template) +- `docs/personas/civsim-personas.md` (sibling per-product persona doc — B-0486) +- `docs/GLOSSARY.md` § KSK (canonical definition) +- `docs/backlog/P1/B-0488-ksk-persona-map-2026-05-14.md` (this row's parent) +- `docs/backlog/P1/B-0485-persona-mapping-framework-template-substrate-inventory-2026-05-14.md` (template origin) +- `.claude/rules/methodology-hard-limits.md` (refused-persona discipline) +- `.claude/rules/mechanical-authorization-check.md` (authorization-source filter) +- `.claude/rules/zeta-ships-with-skills-immediate-value.md` (skill targeting per persona — Edge layer for B-0493) +- PR #2892 (KSK origin substrate) +- `Lucent-Financial-Group/lucent-ksk` (external code repo) +- `memory/feedback_aaron_ksk_kinetic_safeguard_kernel_origin_amara_consent_first_design_nvidia_thor_homeland_security_cleared_because_actuators_2026_05_13.md` (origin disclosure) From 61aab858fbe3a8658ce49b23d2f5cc56e9a020be Mon Sep 17 00:00:00 2001 From: Aaron Stainback Date: Thu, 14 May 2026 16:45:35 -0400 Subject: [PATCH 2/3] docs(archive): preserve recently merged PRs 3233-3226 --- ...ate-docs-backlog-md-index-drift-cleanup.md | 51 ++++++++ ...klog-md-generated-index-drift-cleanup-b.md | 75 ++++++++++++ ...ttern-5-6-contamination-defenses-to-rca.md | 72 ++++++++++++ ...a-expected-branch-with-primary-defenses.md | 109 ++++++++++++++++++ ...romote-primary-defenses-to-claude-rules.md | 81 +++++++++++++ 5 files changed, 388 insertions(+) create mode 100644 docs/pr-discussions/PR-3226-chore-backlog-regenerate-docs-backlog-md-index-drift-cleanup.md create mode 100644 docs/pr-discussions/PR-3227-shard-tick-2026z-backlog-md-generated-index-drift-cleanup-b.md create mode 100644 docs/pr-discussions/PR-3228-chore-b-0519-add-pattern-5-6-contamination-defenses-to-rca.md create mode 100644 docs/pr-discussions/PR-3232-chore-rule-extend-zeta-expected-branch-with-primary-defenses.md create mode 100644 docs/pr-discussions/PR-3233-shard-tick-2034z-promote-primary-defenses-to-claude-rules.md diff --git a/docs/pr-discussions/PR-3226-chore-backlog-regenerate-docs-backlog-md-index-drift-cleanup.md b/docs/pr-discussions/PR-3226-chore-backlog-regenerate-docs-backlog-md-index-drift-cleanup.md new file mode 100644 index 000000000..b82050f22 --- /dev/null +++ b/docs/pr-discussions/PR-3226-chore-backlog-regenerate-docs-backlog-md-index-drift-cleanup.md @@ -0,0 +1,51 @@ +--- +pr_number: 3226 +title: "chore(backlog): regenerate docs/BACKLOG.md \u2014 index drift cleanup (B-0517/B-0518/B-0519)" +author: "AceHack" +state: "MERGED" +created_at: "2026-05-14T20:28:42Z" +merged_at: "2026-05-14T20:30:50Z" +closed_at: "2026-05-14T20:30:50Z" +head_ref: "otto/backlog-md-regen-b0517-b0518-b0519-2026-05-14" +base_ref: "main" +archived_at: "2026-05-14T20:45:34Z" +archive_tool: "tools/pr-preservation/archive-pr.ts" +--- + +# PR #3226: chore(backlog): regenerate docs/BACKLOG.md — index drift cleanup (B-0517/B-0518/B-0519) + +## PR description + +## Summary + +Three on-disk backlog rows were missing from the auto-generated index in `docs/BACKLOG.md`: + +- **B-0517** (P3) — MEMORY.md index bloat cleanup + entry-length enforcement cadence +- **B-0518** (P1) — Sharpen the holding-without-named-dependency rule +- **B-0519** (P3) — Multi-Otto branch-state contamination RCA + +This PR regenerates the index. The drift was pre-existing and surfacing as a non-required failure on every recent PR (e.g., the warning on [#3221](https://github.com/Lucent-Financial-Group/Zeta/pull/3221) which surfaced it). Pure index-drift fix; no per-row file changes. + +Regenerated via `BACKLOG_WRITE_FORCE=1 bun tools/backlog/generate-index.ts`. + +## Test plan + +- [x] Diff is exactly +3 lines (one per missing row) +- [x] `bun tools/backlog/generate-index.ts --check` should be clean post-merge +- [ ] Auto-merge clears the `check docs/BACKLOG.md generated-index drift` gate + +🤖 Generated with [Claude Code](https://claude.com/claude-code) + +Co-Authored-By: Claude + +## Reviews + +### COMMENTED — @copilot-pull-request-reviewer (2026-05-14T20:29:53Z) + +## Pull request overview + +Pure regeneration of the auto-generated `docs/BACKLOG.md` index to pick up three on-disk backlog rows (B-0517, B-0518, B-0519) that existed under `docs/backlog/P1/` and `docs/backlog/P3/` but were missing from the rendered index. The drift was surfacing as a non-required CI failure on recent PRs; this restores parity between per-row files and the index. + +**Changes:** +- Add B-0518 entry under the P1 section. +- Add B-0517 and B-0519 entries under the P3 section. diff --git a/docs/pr-discussions/PR-3227-shard-tick-2026z-backlog-md-generated-index-drift-cleanup-b.md b/docs/pr-discussions/PR-3227-shard-tick-2026z-backlog-md-generated-index-drift-cleanup-b.md new file mode 100644 index 000000000..db42774ed --- /dev/null +++ b/docs/pr-discussions/PR-3227-shard-tick-2026z-backlog-md-generated-index-drift-cleanup-b.md @@ -0,0 +1,75 @@ +--- +pr_number: 3227 +title: "shard(tick): 2026Z \u2014 BACKLOG.md generated-index drift cleanup (B-0517/B-0518/B-0519)" +author: "AceHack" +state: "MERGED" +created_at: "2026-05-14T20:29:52Z" +merged_at: "2026-05-14T20:32:26Z" +closed_at: "2026-05-14T20:32:26Z" +head_ref: "shard/tick-2026Z-backlog-regen-otto-cli-2026-05-14" +base_ref: "main" +archived_at: "2026-05-14T20:45:34Z" +archive_tool: "tools/pr-preservation/archive-pr.ts" +--- + +# PR #3227: shard(tick): 2026Z — BACKLOG.md generated-index drift cleanup (B-0517/B-0518/B-0519) + +## PR description + +## Summary + +Tick 2026-05-14T20:26Z shard. Substantive work in [#3226](https://github.com/Lucent-Financial-Group/Zeta/pull/3226) (BACKLOG.md regen — closes the drift warning surfaced by [#3221](https://github.com/Lucent-Financial-Group/Zeta/pull/3221)). + +## What landed + +- [#3226](https://github.com/Lucent-Financial-Group/Zeta/pull/3226) — regen of `docs/BACKLOG.md` adding B-0517/B-0518/B-0519 to the auto-generated index. Pure regen; no per-row file changes. +- This shard. + +## Prior-tick PRs status + +- [#3221](https://github.com/Lucent-Financial-Group/Zeta/pull/3221) (chore(b-0502) launchd plist) — **MERGED** as `eb81404`. Closes B-0441 AC #2. +- [#3222](https://github.com/Lucent-Financial-Group/Zeta/pull/3222) (shard 2010Z) — still wait-ci, autoMerge armed. + +## Branch-state contamination — 2 new incidents this tick + +Multi-Otto-one-checkout topology produced two more contamination patterns: + +1. Between `git push` and `gh pr create`: HEAD detached at `origin/main` (parallel Otto's checkout). Worked around with re-`checkout`. +2. Second `gh pr create`: HEAD now on `fix/b-0518-sharpen-...` (a different Otto's branch). Worked around with `gh pr create --head ` explicit flag. + +## New defenses for future-Otto + +- **`git branch --show-current` immediately before `git commit`** — primary catch for wrong-branch commits; survived this tick. +- **`gh pr create --head `** — explicit head ref prevents implicit current-branch from being poisoned by parallel checkouts. + +The env-var-based `ZETA_EXPECTED_BRANCH` hook remains defense-in-depth only (env vars don't persist reliably across Bash-tool calls). + +## Test plan + +- [x] `git branch --show-current` confirmed before commit (correct branch) +- [x] `gh pr create --head` explicit ref +- [ ] CI clears +- [ ] Auto-merge + +🤖 Generated with [Claude Code](https://claude.com/claude-code) + +Co-Authored-By: Claude + +## Reviews + +### COMMENTED — @copilot-pull-request-reviewer (2026-05-14T20:31:07Z) + +## Pull request overview + +Tick shard file documenting the 2026-05-14T20:26Z autonomous-loop tick. Records the BACKLOG.md index-drift cleanup landed via #3226 and catalogs two new multi-Otto branch-state contamination incidents with their workarounds. + +**Changes:** +- Adds a new tick-history file under `docs/hygiene-history/ticks/2026/05/14/` per per-tick discipline +- Documents the BACKLOG.md drift investigation that surfaced B-0517/B-0518/B-0519 missing from the generated index +- Captures two new branch-contamination patterns and the `gh pr create --head` defense + +## General comments + +### @chatgpt-codex-connector (2026-05-14T20:29:56Z) + +You have reached your Codex usage limits for code reviews. You can see your limits in the [Codex usage dashboard](https://chatgpt.com/codex/cloud/settings/usage). diff --git a/docs/pr-discussions/PR-3228-chore-b-0519-add-pattern-5-6-contamination-defenses-to-rca.md b/docs/pr-discussions/PR-3228-chore-b-0519-add-pattern-5-6-contamination-defenses-to-rca.md new file mode 100644 index 000000000..a1d86bf95 --- /dev/null +++ b/docs/pr-discussions/PR-3228-chore-b-0519-add-pattern-5-6-contamination-defenses-to-rca.md @@ -0,0 +1,72 @@ +--- +pr_number: 3228 +title: "chore(b-0519): add Pattern 5/6 contamination defenses to RCA" +author: "AceHack" +state: "MERGED" +created_at: "2026-05-14T20:32:48Z" +merged_at: "2026-05-14T20:34:05Z" +closed_at: "2026-05-14T20:34:05Z" +head_ref: "otto/b0519-add-new-contamination-defenses-2026-05-14" +base_ref: "main" +archived_at: "2026-05-14T20:45:33Z" +archive_tool: "tools/pr-preservation/archive-pr.ts" +--- + +# PR #3228: chore(b-0519): add Pattern 5/6 contamination defenses to RCA + +## PR description + +## Summary + +Additive update to [B-0519 RCA](docs/backlog/P3/B-0519-multi-otto-branch-state-contamination-rca-2026-05-14.md) adding two contamination patterns surfaced today via field-test, plus the new cheap defenses that worked. + +## Patterns added + +- **Pattern 5** — HEAD detached at `origin/main` between `git push` and `gh pr create` (parallel-Otto check-out of `origin/main` in the same physical worktree). +- **Pattern 6** — HEAD on a different Otto's branch between recovery `checkout` and `gh pr create`. + +## New cheap defenses (zero-code; field-tested first-try) + +- `git branch --show-current` immediately before `git commit` — primary catch for wrong-branch commits. Validated on ticks 2010Z and 2026Z. +- `gh pr create --head ` with explicit head ref — removes dependency on current-branch state, which can be poisoned by parallel-Otto checkouts. + +## Caveat on env-var hook + +Also noted in the RCA: the `ZETA_EXPECTED_BRANCH` `PreToolUse` hook is defense-in-depth only — env vars don't persist reliably across separate Bash-tool calls (each invocation may spawn a fresh shell). The substrate-honest primary catch is `git branch --show-current` immediately before `git commit`. + +## Field-test ticks referenced + +- [`docs/hygiene-history/ticks/2026/05/14/2010Z.md`](docs/hygiene-history/ticks/2026/05/14/2010Z.md) — first untangle field-test +- [`docs/hygiene-history/ticks/2026/05/14/2026Z.md`](docs/hygiene-history/ticks/2026/05/14/2026Z.md) — Pattern 5 + Pattern 6 validation + +## Test plan + +- [x] Pure additive update (57 insertions; no per-row metadata changes) +- [x] markdownlint-cli2 clean +- [x] `git branch --show-current` confirmed before commit + after commit +- [x] `gh pr create --head` explicit ref used +- [ ] CI clears +- [ ] Auto-merge + +🤖 Generated with [Claude Code](https://claude.com/claude-code) + +Co-Authored-By: Claude + +## Reviews + +### COMMENTED — @copilot-pull-request-reviewer (2026-05-14T20:34:01Z) + +## Pull request overview + +Additive documentation update to the B-0519 RCA row, appending two newly-observed multi-Otto branch-state contamination patterns and the zero-code defenses that worked in field-test. + +**Changes:** +- Adds Pattern 5 (HEAD detached at `origin/main` between `git push` and `gh pr create`) and Pattern 6 (HEAD on another Otto's branch between recovery checkout and `gh pr create`). +- Documents new cheap defenses: `git branch --show-current` immediately before `git commit`, and `gh pr create --head ` with explicit head ref. +- Notes env-var `ZETA_EXPECTED_BRANCH` hook is defense-in-depth only (doesn't persist across Bash-tool calls), and links the 2010Z/2026Z field-test ticks. + +## General comments + +### @chatgpt-codex-connector (2026-05-14T20:32:53Z) + +You have reached your Codex usage limits for code reviews. You can see your limits in the [Codex usage dashboard](https://chatgpt.com/codex/cloud/settings/usage). diff --git a/docs/pr-discussions/PR-3232-chore-rule-extend-zeta-expected-branch-with-primary-defenses.md b/docs/pr-discussions/PR-3232-chore-rule-extend-zeta-expected-branch-with-primary-defenses.md new file mode 100644 index 000000000..8fe025384 --- /dev/null +++ b/docs/pr-discussions/PR-3232-chore-rule-extend-zeta-expected-branch-with-primary-defenses.md @@ -0,0 +1,109 @@ +--- +pr_number: 3232 +title: "chore(rule): extend zeta-expected-branch with primary defenses (cold-boot substrate)" +author: "AceHack" +state: "MERGED" +created_at: "2026-05-14T20:36:51Z" +merged_at: "2026-05-14T20:39:32Z" +closed_at: "2026-05-14T20:39:32Z" +head_ref: "otto/extend-zeta-branch-rule-primary-defenses-2026-05-14" +base_ref: "main" +archived_at: "2026-05-14T20:45:32Z" +archive_tool: "tools/pr-preservation/archive-pr.ts" +--- + +# PR #3232: chore(rule): extend zeta-expected-branch with primary defenses (cold-boot substrate) + +## PR description + +## Summary + +Extends [`.claude/rules/zeta-expected-branch.md`](.claude/rules/zeta-expected-branch.md) with two primary defenses for multi-Otto-one-checkout topology. Promotes them from B-0519 RCA (grep-discoverable backlog row) to `.claude/rules/` (auto-loaded at cold-boot for every fresh session). + +## Why promote from RCA to rule + +Per [claude-code-loading-taxonomy.md](.claude/rules/claude-code-loading-taxonomy.md): "I keep forgetting to do X" is the goldfish-ontology failure mode that needs direct-load surface (rule files), not router-loaded skills or grep-discoverable backlog rows. The defenses fire on every commit/PR call — every cold-boot Otto needs them in context from session start, not via grep. + +Per [skill-router-as-substrate-inventory.md](.claude/rules/skill-router-as-substrate-inventory.md): extend the existing rule rather than mint a new one — same failure mode (wrong-branch commits under multi-Otto contention). + +## What's added + +### Field-test caveat on the env-var hook + +`ZETA_EXPECTED_BRANCH` set in one Bash-tool call doesn't reliably persist to the call that runs `git commit` — each invocation may spawn a fresh shell. The hook is therefore defense-in-depth only. Observed on tick 2010Z (2026-05-14): the hook did NOT catch a wrong-branch commit. + +### Primary defense 1 — `git branch --show-current` before `git commit` + +Direct git-state query; survives any harness shell-environment quirk. Field-tested ticks 2010Z + 2026Z + 2030Z + this tick. + +### Primary defense 2 — `gh pr create --head ` explicit head ref + +Removes implicit current-branch dependency, which can be poisoned by parallel-Otto checkouts between `git push` and `gh pr create`. Field-tested ticks 2026Z + 2030Z + this tick. + +### Composite operator-discipline snippet + +```bash +test "$(git branch --show-current)" = "" || exit 1 +git commit -m "..." + +gh pr create --head --base main --title "..." --body "..." +``` + +## Test plan + +- [x] Used the composite guard for THIS commit (`test = "" && git commit`) — branch verified +- [x] Used `gh pr create --head` explicit ref for THIS PR +- [x] markdownlint-cli2 clean +- [ ] CI clears +- [ ] Auto-merge + +🤖 Generated with [Claude Code](https://claude.com/claude-code) + +Co-Authored-By: Claude + +## Reviews + +### COMMENTED — @copilot-pull-request-reviewer (2026-05-14T20:39:46Z) + +## Pull request overview + +This PR promotes branch-contamination defenses into the cold-boot `.claude/rules/` substrate so fresh sessions see the expected-branch discipline before commit/PR operations. + +**Changes:** +- Adds a caveat that the `ZETA_EXPECTED_BRANCH` env-var hook is defense-in-depth because shell env may not persist across Bash-tool calls. +- Adds primary operator defenses: query current branch before commit and use `gh pr create --head`. +- Links the rule back to the B-0519 RCA. + + +
+Comments suppressed due to low confidence (1) + +**.claude/rules/zeta-expected-branch.md:117** +* This parenthetical says the RCA has 2010Z/2026Z/2030Z field-test shards, but the referenced RCA only documents 2010Z and 2026Z, and there is no `docs/hygiene-history/ticks/2026/05/14/2030Z.md` in the tree. The cross-reference should not name a non-existent shard. +``` +(RCA capturing the multi-Otto contamination patterns + the primary defenses +this rule operationalizes; field-test tick shards 2010Z/2026Z/2030Z) +``` +
+ +## Review threads + +### Thread 1: .claude/rules/zeta-expected-branch.md:61 (unresolved) + +**@copilot-pull-request-reviewer** (2026-05-14T20:39:45Z): + +This cites a 2030Z field-test, but `docs/hygiene-history/ticks/2026/05/14/2030Z.md` does not exist and the B-0519 RCA only lists 2010Z/2026Z field-test ticks. Either add the missing shard/evidence or remove 2030Z so the promoted rule remains traceable. + +This issue also appears on line 116 of the same file. + +### Thread 2: .claude/rules/zeta-expected-branch.md:117 (unresolved) + +**@copilot-pull-request-reviewer** (2026-05-14T20:39:45Z): + +This new reference says the rule now operationalizes the B-0519 primary defenses, but the referenced B-0519 row still says carrying this in `.claude/rules/` “would be the right home if/when this is promoted.” If this PR promotes the defense, update that row in the same PR to point back here or explicitly scope the remaining open work so the backlog/RCA does not drift from the loaded rule. + +### Thread 3: .claude/rules/zeta-expected-branch.md:81 (unresolved) + +**@copilot-pull-request-reviewer** (2026-05-14T20:39:46Z): + +The documented failure mode is HEAD moving between two Bash-tool calls, but this example presents the branch check and commit as separate steps. A fresh session can still run the check in one Bash invocation and `git commit` in the next, recreating the gap the rule is trying to close; make the snippet explicitly same-invocation/atomic (for example by chaining the guard with the commit) or state that both lines must be executed in one Bash call. diff --git a/docs/pr-discussions/PR-3233-shard-tick-2034z-promote-primary-defenses-to-claude-rules.md b/docs/pr-discussions/PR-3233-shard-tick-2034z-promote-primary-defenses-to-claude-rules.md new file mode 100644 index 000000000..e58ba92ff --- /dev/null +++ b/docs/pr-discussions/PR-3233-shard-tick-2034z-promote-primary-defenses-to-claude-rules.md @@ -0,0 +1,81 @@ +--- +pr_number: 3233 +title: "shard(tick): 2034Z \u2014 promote primary defenses to .claude/rules/" +author: "AceHack" +state: "MERGED" +created_at: "2026-05-14T20:37:59Z" +merged_at: "2026-05-14T20:39:20Z" +closed_at: "2026-05-14T20:39:20Z" +head_ref: "shard/tick-2034Z-promote-defenses-to-rule-otto-cli-2026-05-14" +base_ref: "main" +archived_at: "2026-05-14T20:45:31Z" +archive_tool: "tools/pr-preservation/archive-pr.ts" +--- + +# PR #3233: shard(tick): 2034Z — promote primary defenses to .claude/rules/ + +## PR description + +## Summary + +Tick 2026-05-14T20:34Z shard. Substantive work in [#3232](https://github.com/Lucent-Financial-Group/Zeta/pull/3232) — promotes the two primary contamination defenses from B-0519 RCA (grep-discoverable backlog row) to `.claude/rules/zeta-expected-branch.md` (auto-loaded at cold-boot). + +## What landed + +- [#3232](https://github.com/Lucent-Financial-Group/Zeta/pull/3232) — extends the existing branch-verification rule with the field-test caveat + the two new primary defenses + the composite operator-discipline snippet. +- This shard. + +## Prior-tick PRs status + +Three merged this batch: +- [#3222](https://github.com/Lucent-Financial-Group/Zeta/pull/3222) (shard 2010Z) — MERGED as `82edec5`. +- [#3227](https://github.com/Lucent-Financial-Group/Zeta/pull/3227) (shard 2026Z) — MERGED as `8b59343`. +- [#3228](https://github.com/Lucent-Financial-Group/Zeta/pull/3228) (B-0519 RCA update) — MERGED as `36fbe4c`. +- [#3231](https://github.com/Lucent-Financial-Group/Zeta/pull/3231) (shard 2030Z) — wait-ci, autoMerge armed. + +## Session running tally + +Five merged (#3221 + #3222 + #3226 + #3227 + #3228); three wait-ci (#3231 + #3232 + this shard's PR). + +## Composite guard pattern (used in this tick's commits + PRs) + +```bash +test "$(git branch --show-current)" = "" || exit 1 +git commit -m "..." + +gh pr create --head --base main --title "..." --body "..." +``` + +Mechanizes the operator-discipline into the same shell call as the action, so the check can't be read-then-skipped. + +## Test plan + +- [x] Composite guard used for this commit + #3232 commit +- [x] `gh pr create --head` explicit ref used +- [x] markdownlint-cli2 clean +- [ ] CI clears +- [ ] Auto-merge + +🤖 Generated with [Claude Code](https://claude.com/claude-code) + +Co-Authored-By: Claude + +## Reviews + +### COMMENTED — @copilot-pull-request-reviewer (2026-05-14T20:39:57Z) + +## Pull request overview + +Adds the 2034Z hygiene-history tick record documenting the promotion of the B-0519 branch-contamination defenses into the cold-boot `.claude/rules/` substrate (landed substantively in PR #3232). + +**Changes:** +- Add `2034Z.md` tick log capturing the rationale, verification steps, and operator-discipline composite guard pattern. +- Record status/visibility for related PRs in this tick batch. + +## Review threads + +### Thread 1: docs/hygiene-history/ticks/2026/05/14/2034Z.md:72 (unresolved) + +**@copilot-pull-request-reviewer** (2026-05-14T20:39:57Z): + +Session running tally has an internal inconsistency: it says "two wait-ci" but then lists three items (#3231 + #3232 + this shard PR). Also the wrapped continuation line starts a new paragraph; consider keeping it on one line or indenting as a continuation for readability. From e7ab57e741c41c8047f3f8eae8b3a881142b56e6 Mon Sep 17 00:00:00 2001 From: Aaron Stainback Date: Thu, 14 May 2026 16:52:24 -0400 Subject: [PATCH 3/3] =?UTF-8?q?fix(backlog):=20revert=20B-0488=20status=20?= =?UTF-8?q?in-progress=20=E2=86=92=20open=20(schema=20compliance)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `in-progress` is not a valid frontmatter status enum — valid values per tools/backlog/README.md are open/closed/superseded-by-B-NNNN/deferred. Reverts to `open` so generate-index.ts stays schema-correct. Co-Authored-By: Claude --- docs/backlog/P1/B-0488-ksk-persona-map-2026-05-14.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/backlog/P1/B-0488-ksk-persona-map-2026-05-14.md b/docs/backlog/P1/B-0488-ksk-persona-map-2026-05-14.md index 37f8ba962..4de42c93c 100644 --- a/docs/backlog/P1/B-0488-ksk-persona-map-2026-05-14.md +++ b/docs/backlog/P1/B-0488-ksk-persona-map-2026-05-14.md @@ -1,7 +1,7 @@ --- id: B-0488 priority: P1 -status: in-progress +status: open title: "B-0429.4 — KSK (Kinetic Safeguard Kernel) persona map" type: planning origin: B-0429 decomposition (Otto, 2026-05-14)