Protocol 456

The 456 Protocol Skill (v2.0)

Purpose

A lightweight sibling of Protocol 123 with a streamlined 6-phase lifecycle (Phases 0-5) designed for 80% of everyday engineering tasks (bugfixes, targeted features, AST adjustments, or pre-scoped tracks). Slashes token consumption and latency by 80-85% compared to Protocol 123 by eliminating multi-agent debate, removing review-arbiter bureaucracy, bounding web searches to high-quality official sources, and relying on a single specialized domain reviewer. Backed by deterministic runner scripts/protocol-456.mjs.

Precondition & Fast-Track Intake (Phase 0)

Protocol 456 handles both general fast-track tasks and pre-scoped plan tracks:

1. Pre-Scoped Track (Fast-Track Branch): If input already names exact target files, step-by-step edits, and a runnable test verification command (e.g. from an SDD remediation spec), Phase 0 verifies the baseline and fast-tracks directly to Phase 3 (In-Session TDD), skipping planning Phases 1 and 2 while strictly retaining Phase 4 (Single-Reviewer Risk Audit).
2. Standard Fast-Track Task: If input is an arbitrary request (e.g. "исправь баг в CLI по 456"), Phase 0 verifies working tree cleanliness, Phase 1 formulates a compact SDD plan with on-demand web research, and Phase 2 secures fast human approval before TDD.

Activation Rules & Trigger Phrases

• Strict Trigger Rule (Explicit Activation Only): Activated STRICTLY AND ONLY when the user explicitly invokes it via 456, по 456, таска по 456, or исправь по 456 (e.g. "давай по 456", "пофикси баг по 456", "трек 7 по 456"). Never self-triggered on the assistant's own judgment.
• Requests without a 456 trigger phrase are executed as ordinary direct work per Section 13.
• Proactive Suggestion (User Decision Gateway): For targeted, low-to-medium complexity tasks or ready plan tracks, the assistant may propose Protocol 456 (e.g. "Хотите выполнить эту задачу по протоколу 456?"). Launched only upon explicit user consent.

6-Phase Lifecycle (Phases 0-5)

Phase 0: Intake & Quick Baseline Check

• Verify target files fresh with Read (Context Freshness - never from memory).
• Ensure git working tree is clean via git status --porcelain.
• Verify build baseline: run node scripts/protocol-456.mjs verify-phase 0 (or npm run build).
• If input satisfies the Pre-Scoped Track condition, fast-track directly to Phase 3.

Phase 1: Focused Plan & On-Demand Web Research

• Author a compact SDD plan (1-2 pages) containing an Executive Summary, concise ACs in EARS format, exact file paths, and test verification commands.
• On-Demand Web Research: When researching third-party library behaviors, breaking changes, or modern best practices, perform targeted searches via WebSearch against official documentation (e.g. playwright.dev, nodejs.org, github.com, vitest.dev). Focus on high-quality findings, pitfalls, and concrete code patterns.
• Do not spawn multi-agent research swarms, and do not perform heavy ISTQB syllabus taxonomies.

Phase 2: Human Sign-Off Gate

• Present the compact plan artifact to the user with RequestFeedback: true.
• Zero code modifications are permitted until the user explicitly confirms approval (e.g. "approve", "делай", "да").

Phase 3: In-Session TDD (Red -> Green -> Refactor)

• Phase 3a (RED): Write or extend a targeted failing test proving the defect or new capability. Verify failure.
• Phase 3b (GREEN): Implement the minimal code edit using Edit. Run target test until 100% green.
• Phase 3c (REFACTOR): Clean up temporary code, run linter/formatter.
• Two-Strike Rule: If test verification fails twice consecutively on the same issue, revert modified tracked files (git checkout -- <file>) and delete declared new files, then escalate to the user with root-cause analysis. Never use git clean -fdx or git reset --hard.

Phase 4: Single-Reviewer Risk Audit

• Spawn exactly ONE specialized domain reviewer matching the task risk shape:
  • framework-auditor: For cross-language generator templates or multi-stack parity.
  • code-reviewer: For everything else - general correctness, architecture, schema alignment, security/privacy (injection, secrets, path traversal, CVEs), and flake/determinism (timing races, async promises, flaky assertions) are all covered by its own unified review protocol.
• Zero review-arbiters: A single reviewer produces no multi-agent conflict to adjudicate.
• The reviewer tags all findings as [CONFIRMED_IN_SCOPE] (must fix now), [DISMISSED_OUT_OF_SCOPE] (non-blocking observation), or [DEFERRED_TO_TODO] (log to TODO.md). Mandatory in both full and fast-track modes.

Phase 5: Fast Quality Gate, Doc Sync & Micro-Telemetry

• Verify build gate via node scripts/protocol-456.mjs verify-phase 5 and re-run the targeted test.
• Update CHANGELOG.md with exactly one concise, keyword-first line under the active version header.
• Execute git commit strictly via npm run commit -- "<message>" to enforce mandatory evening 23:00 OpSec timestamps per CLAUDE.md Section 5.
• Emit the 4-line micro-telemetry summary table via node scripts/protocol-456.mjs telemetry.

Batch Completion Gate (once per batch, before reporting the branch ready)

When Protocol 456 is executed across multiple consecutive tracks on the same branch:

• After the LAST track in the batch completes Phase 5, run the full CI test suite command specified in .github/workflows/ci.yml (e.g. npx vitest run packages/engine/test packages/cli/test) to catch cross-cutting regressions.
• If failures occur, fix them under the Two-Strike Rule before declaring the branch ready.