diff --git a/neckbeard/README.md b/neckbeard/README.md index 14c5d6b..b12acc6 100644 --- a/neckbeard/README.md +++ b/neckbeard/README.md @@ -43,6 +43,8 @@ ordinary bug-fix reproduction requirements. | `references/journey.md` | Canonical 9-phase change-request journey — intake, discovery, design, spec, test plan, implementation, review, readiness, authorized release — with four delivery paths | | `references/lifecycle.md` | Platform mechanics for GitHub (reference mode) and enterprise contexts — intake snapshots, CI/review monitoring, terminal states, and post-merge release authority | | `references/delivery-packet.md` | Durable cross-phase handoff: provenance, resumability, gate verdicts, exact-head binding, lifecycle states, and an artifact ownership map | +| `references/position-assessment.md` | Entry mode for picking up delivery work that started elsewhere: artifact inventory, phase exit-condition scoring, a position report, and packet bootstrap | +| `references/tracker-discovery.md` | Intake sub-step that detects which tracking system holds the work item and routes tracker operations to the matching tooling skill (`linear`, `jira-cli`, `notion`) | | `references/evaluation.md` | Evaluation methodology: fixtures, baselines, rubrics, multi-run reporting, claims policy | | `templates/` | Change contract, decision record, evidence ledger, verification plan, evaluation report | | `templates/delivery-packet.md` | Fillable delivery packet template mirroring the nine field groups defined in the reference | @@ -72,6 +74,8 @@ python3 eval/run_eval.py --suite eval/fixtures --report out/report.md - You need to evaluate whether a delivery skill actually improves outcomes. - You are delivering a **change request** — an issue, ticket, or tracked request — from intake through planning, gates, implementation, and review to a verified PR (or equivalent reviewable deliverable). - You need to carry work from an **issue to a PR to an authorized post-merge release** with resumable, exact-head-bound state across phases. +- You are asked to **continue work someone else started** — a half-implemented branch or adopted spec with no delivery packet — and need an evidence-based answer to "what step are we on and what remains?" +- Your product tracks work in **Linear, Jira, or Notion**, and the lifecycle should operate that system through its own tooling skill instead of assuming GitHub. Do not trigger for single factual questions, fully-specified one-line edits, or tasks already owned end-to-end by a more specific skill. The change-request diff --git a/neckbeard/SKILL.md b/neckbeard/SKILL.md index 531ae2e..76263a7 100644 --- a/neckbeard/SKILL.md +++ b/neckbeard/SKILL.md @@ -118,6 +118,22 @@ or create a second orchestrator. issue/ticket trajectory. That work uses the core loop and the stage references below without the journey's phases, packet, or gates. +### Mid-flight engagement (conditional) + +When the request is to **continue delivery work that started elsewhere** — a +half-implemented branch, an adopted spec, a change request another contributor +began — and no delivery packet exists, do not restart at phase 1 and do not +trust narrative summaries of what was done. Run position assessment first: +inventory observable artifacts, score them against phase exit conditions, emit +a position report (current step, satisfied gates with evidence pointers, +remaining checklist), then bootstrap a packet and continue under the normal +journey. + +Procedure: [references/position-assessment.md](references/position-assessment.md). +Load it only for mid-flight engagement; fresh change requests start at phase 1, +and existing packets govern resumability through +[references/delivery-packet.md](references/delivery-packet.md). + ## Path selection before ceremony Select the delivery path immediately after current-state discovery and before @@ -215,6 +231,8 @@ metadata, never as a success proxy. | [references/lightweight-test-hardening.md](references/lightweight-test-hardening.md) | Test-only regression guards for already-correct production behavior: baseline-pass / mutant-fail evidence, hermeticity, finality-before-push, bounded review, and escalation triggers. | | [references/lifecycle.md](references/lifecycle.md) | **Change-request work only** — platform mechanics (GitHub reference mode or enterprise mode) for intake, submission, CI/review monitoring, and authorized release. **Not loaded** for a simple fix, refactor, or review without an issue/ticket trajectory. | | [references/delivery-packet.md](references/delivery-packet.md) | **Change-request work only** — carrying state across phases of a change-request run, or resuming after a context boundary; defines packet fields, artifact ownership, lifecycle states, and resumability. **Not loaded** for a simple fix, refactor, or review without an issue/ticket trajectory. | +| [references/position-assessment.md](references/position-assessment.md) | **Mid-flight engagement only** — continuing delivery work that started elsewhere with no delivery packet: artifact inventory, exit-condition scoring, position report, packet bootstrap. | +| [references/tracker-discovery.md](references/tracker-discovery.md) | **Change-request intake** — detecting which tracking system holds the work item and routing tracker operations to the matching catalog tooling skill; keeps the journey vocabulary tracker-neutral. | | [references/evaluation.md](references/evaluation.md) | Designing, running, or reporting an evaluation | | [templates/](templates/) | Change contract, decision record, evidence ledger, verification plan, eval report; plus [templates/delivery-packet.md](templates/delivery-packet.md) — the fillable packet, **for change-request work only** (not for a simple fix/refactor/review without an issue trajectory) | | [eval/](eval/) | Task schema, rubric, baseline protocol, fixtures, runner | diff --git a/neckbeard/evals/evals.json b/neckbeard/evals/evals.json index 92df0ee..1fff12c 100644 --- a/neckbeard/evals/evals.json +++ b/neckbeard/evals/evals.json @@ -1 +1 @@ -{"schema_version": 1, "skill_name": "neckbeard", "evals": [{"id": "bug-fix-reproduction-regression", "prompt": "Issue #342 in our inventory service: the CSV export endpoint returns an off-by-one row count when the dataset contains multi-byte UTF-8 characters. Users see 99 rows exported when there are actually 100. Fix this bug and make sure it stays fixed.", "expected_output": "Scenario: straightforward bug fix with reproduction and regression test. The trajectory follows the full journey path through all nine phases (intake and provenance, current-state discovery and reproduction, architecture/design delta, specification, pre-implementation test planning, domain implementation, independent review and boundary verification, readiness and CI/review loops, authorized post-merge release). Phase 2 records reproduction evidence (repro steps, observed vs. expected behavior, environment/version) in delivery packet group (d). A documented 'no architecture delta' determination satisfies gate 1. A regression test is added covering the multi-byte UTF-8 boundary. The verification plan names the regression test as passing evidence. All five gates are recorded in packet group (h) with verdicts bound to the exact head SHA. The terminal lifecycle state is 'merged' with the merge commit SHA recorded in packet group (i). Claims are scoped to the harness, model, fixtures, and revision under test.", "assertions": ["Delivery packet group (d) contains reproduction evidence with repro steps, observed behavior, expected behavior, and environment/version for the bug report", "Gate 1 verdict is recorded as pass with a documented 'no architecture delta' determination in packet group (h)", "A regression test targeting the multi-byte UTF-8 row-count boundary exists in the produced artifacts", "The verification plan in packet group (g) names the regression test as a required passing evidence artifact", "All five gate verdicts (gate 1, gate 2, gate 3, gate 4, gate 5) are recorded in packet group (h) each bound to an exact head SHA", "The final verified head SHA in packet group (i) equals the actual head SHA of the delivered change", "Terminal lifecycle state in packet group (i) is 'merged' with a merge commit SHA recorded"]}, {"id": "ambiguous-feature-product-discovery", "prompt": "Our product manager filed issue #518: 'Add collaborative editing to the document editor.' The request has no acceptance criteria, no scope boundary, and three different stakeholders have posted conflicting comments about what this means. Figure out what to build and deliver it.", "expected_output": "Scenario: ambiguous feature requiring product discovery and scope gate. The trajectory exercises the full journey path. Phase 1 captures provenance and flags the ambiguity. Phase 2 gathers current-state evidence from the codebase and issue comments. The product-discovery specialist is loaded (applicability signal: ambiguous requirements with conflicting stakeholder input) and its engagement is recorded in packet group (e). Phase 4 produces a SPEC.md with acceptance criteria derived from the discovery output; the scope gate (gate 3) verifies that no unbounded or ownerless work items remain. If requirements are irreconcilably ambiguous after product-discovery engagement, the trajectory escalates per phase 4 escalation conditions rather than guessing. The terminal state is 'merged' if scope is resolved, or 'blocked' with escalation evidence if irreconcilable ambiguity halts work. Claims are scoped to the harness, model, fixtures, and revision under test.", "assertions": ["The routing decision in packet group (e) records product-discovery as a selected specialist with an applicability signal citing ambiguous requirements or conflicting stakeholder input", "Packet group (g) contains a SPEC.md with acceptance criteria derived from product-discovery output rather than guessed from the raw issue text", "Gate 3 verdict in packet group (h) confirms spec and task-plan completeness with no unbounded or ownerless work items", "If the trajectory terminates as 'blocked', packet group (i) records the escalation condition (irreconcilable ambiguity) and the phase at which it occurred", "If the trajectory terminates as 'merged', all five gate verdicts are recorded in packet group (h) bound to the exact final head SHA", "The terminal lifecycle state in packet group (i) is either 'merged' with merge evidence or 'blocked' with escalation evidence; no silent abandonment occurs"]}, {"id": "multi-surface-backend-frontend-api-data", "prompt": "Issue #601: we need to add a user-preferences endpoint (REST API), a settings page (React frontend), a PostgreSQL migration for the new preferences table, and the backend service logic to persist and retrieve preferences. All four surfaces must change together for this feature to work.", "expected_output": "Scenario: multi-surface change involving backend, frontend, API, and data routing. The trajectory exercises the full journey path with multiple specialists composed per stage. Phase 6 routing loads backend-engineering (server-side service logic), frontend-engineering (React settings page), api-design-and-evolution (REST endpoint contract), and data-engineering (PostgreSQL migration) with one lead per stage recorded in packet group (e). The multi-row composition rule applies: no two rows own the same stage simultaneously. Gate 1 requires an architecture delta covering the new table and endpoint contract. Gate 2 requires a verification plan exercising the integration boundary across all four surfaces. Gate 5 boundary verification targets integration or end-to-end level. The terminal state is 'merged' with all gates passed. Claims are scoped to the harness, model, fixtures, and revision under test.", "assertions": ["Packet group (e) routing section records backend-engineering, frontend-engineering, api-design-and-evolution, and data-engineering as selected specialists with per-stage lead assignments", "No two specialist rows are recorded as owning the same implementation stage simultaneously in the routing decision", "Gate 1 verdict in packet group (h) references an architecture delta covering the new PostgreSQL table and the REST endpoint contract", "The verification plan in packet group (g) names an integration or end-to-end verification target exercising the boundary across backend, frontend, API, and data surfaces", "Gate 5 verdict in packet group (h) is bound to the exact head SHA and records the verification boundary actually exercised", "Terminal lifecycle state in packet group (i) is 'merged' with all five gate verdicts recorded as pass"]}, {"id": "schema-migration-rollback-release-readiness", "prompt": "Issue #710: we need to split the 'users' table's 'address' column into separate street, city, state, and zip columns. The table has 4.2 million rows in production. This is a high-risk schema migration that needs a rollback plan and release-readiness evidence before we can merge.", "expected_output": "Scenario: schema/migration change requiring rollback and release-readiness evidence. The trajectory exercises the high-risk journey path (all nine phases mandatory, all five gates, no conditional skips). Phase 3 produces an architecture delta with expand/contract (parallel change) migration strategy and a rollback plan that does not rely on git revert. data-engineering and data-architect are loaded per routing signals (migration files present, schema change). Gate 1 requires approval of the migration strategy and rollback plan. Phase 9 records release-readiness evidence (version bump, changelog, migration documentation, rollback rehearsal) before the release gate is evaluated. The terminal state is 'merged' with release readiness confirmed but release activity gated on separate explicit authorization. Claims are scoped to the harness, model, fixtures, and revision under test.", "assertions": ["The high-risk path is recorded in packet group (b) with all nine phases mandatory and no conditional skips permitted", "Packet group (f) contains a migration strategy using expand/contract (parallel change) and a rollback plan that rejects git revert for schema or data changes", "data-engineering and data-architect are recorded as selected specialists in packet group (e) with applicability signals citing migration files or schema change", "Gate 1 verdict in packet group (h) records approval of the architecture delta including the migration strategy and rollback plan", "Release-readiness evidence (version bump, changelog entry, migration documentation) is recorded in packet group (i) before the release gate", "The release gate in packet group (h) or (i) distinguishes pre-merge release readiness from post-merge release activity requiring separate explicit authorization", "Terminal lifecycle state in packet group (i) is 'merged' with the merge commit SHA recorded; release activity is not conflated with merge"]}, {"id": "refactor-characterization-architecture-review", "prompt": "Issue #823: the order-processing module has grown into a 2,400-line god class. Refactor it into smaller, focused modules without changing any observable behavior. We need proof the behavior is preserved.", "expected_output": "Scenario: refactor needing characterization tests and architecture review. The trajectory exercises the refactor journey path (phases 1, 2, 3, 6, 7, 8, 9 mandatory; phases 4 and 5 conditional). Phase 2 gathers current-state evidence of the god class behavior. Phase 3 produces an architecture delta with the decomposition plan; software-architecture-analysis is loaded for the review. Characterization tests are written or identified before the refactor begins to capture existing behavior. Gate 5 uses behavior-preservation evidence (characterization tests passing before and after) as its criterion. The skip of phase 4 is recorded with the reason that the refactor is fully characterized by the architecture delta and characterization-test plan. The terminal state is 'merged' with behavior-preservation evidence recorded. Claims are scoped to the harness, model, fixtures, and revision under test.", "assertions": ["The refactor path is recorded in packet group (b) with phases 4 and 5 conditional", "Packet group (e) records the skip of phase 4 (specification and decomposition) with a reason citing that no separate SPEC.md is needed because the refactor is behavior-preserving", "software-architecture-analysis is recorded as a selected specialist in packet group (e) for the architecture review", "Characterization tests covering the god class observable behavior exist in the produced artifacts before the refactor commits begin", "Gate 5 verdict in packet group (h) records behavior-preservation evidence (characterization tests passing before and after) bound to the exact head SHA", "Terminal lifecycle state in packet group (i) is 'merged' with the merge commit SHA recorded"]}, {"id": "docs-only-reduced-path-skip-reasons", "prompt": "Issue #901: the API reference page in our docs site has outdated parameter names for the /v2/orders endpoint. Update the documentation to match the current implementation. No code changes are needed.", "expected_output": "Scenario: docs-only change using a reduced (lightweight) path with comprehensive skip recording. The trajectory exercises the lightweight journey path (phases 1, 6, 7, 8, 9 mandatory; phases 2, 3, 4, 5 conditional and skipped). Each skipped phase is recorded in packet group (e) with a concrete reason citing the path's skip criterion. At least two specialist skills that do not apply (backend-engineering, frontend-engineering, data-engineering) are explicitly listed as skipped with reasons citing their routing-table skip rules (e.g., 'no server-side application code modified', 'no client-side application code modified', 'no schema or migration files modified'). No specialist skill in the routing matrix is absent from both the selected and skipped lists. The terminal state is 'merged' with doc-update evidence. Claims are scoped to the harness, model, fixtures, and revision under test.", "assertions": ["The lightweight path is recorded in packet group (b) and phases 2, 3, 4, and 5 are each recorded as skipped in packet group (e) with a concrete reason citing the path's skip criterion", "Packet group (e) routing section lists at least three specialist skills (including backend-engineering, frontend-engineering, and data-engineering) as skipped, each with a skill name and a concrete reason", "Every skipped skill entry in packet group (e) has both a skill name and a non-empty reason; no specialist in the routing matrix is absent from both the selected and skipped lists", "technical-documentation is recorded as a selected specialist in packet group (e) with an applicability signal citing documentation changes", "No code-editing commits appear in the produced artifacts; only documentation files are changed", "Terminal lifecycle state in packet group (i) is 'merged' with the merge commit SHA recorded"]}, {"id": "existing-pr-duplicate-detection", "prompt": "Issue #455 was filed asking for rate limiting on the public API. I want to start working on it and submit a PR.", "expected_output": "Scenario: issue with an existing PR or duplicate work. The trajectory exercises the lifecycle pre-work checks in phase 1 (intake and provenance). The existing-PR search discovers that PR #450 from another contributor already implements rate limiting for the same endpoint. The duplicate-issue check and existing-PR check are recorded as distinct pre-work checks in packet group (d) or the lifecycle fields. The handling decision is to coordinate or defer to the existing PR owner rather than opening a duplicate PR. The terminal lifecycle state is 'closed' with the close reason recording the duplicate-work determination and the existing PR reference. No new PR is opened. Claims are scoped to the harness, model, fixtures, and revision under test.", "assertions": ["Packet group (d) or lifecycle fields record a duplicate-issue check result and a separate existing-PR search result as distinct pre-work checks", "The existing-PR search result identifies the pre-existing PR (by number or reference) addressing the same rate-limiting work", "The handling decision recorded in the packet is to coordinate or defer, not to open a duplicate PR", "No new review submission (PR or equivalent) is created in the produced artifacts", "Terminal lifecycle state in packet group (i) is 'closed' with a close reason citing the duplicate-work determination and referencing the existing PR"]}, {"id": "review-round-material-change-reverification", "prompt": "Issue #567: add input validation to the user-registration form. During code review, a reviewer points out that the validation logic has a bypass when the input contains null bytes. You push a fix addressing the null-byte bypass. This changes the validation logic materially.", "expected_output": "Scenario: review round that changes the final head and requires re-verification, proving a material post-review change invalidates the prior verification verdict. The trajectory exercises phases 1 through 8. Phase 7 (independent review and boundary verification) produces gate 4 and gate 5 verdicts bound to head SHA A (the initial implementation). A material review-driven change (the null-byte bypass fix altering validation logic) produces head SHA B. The prior verdicts bound to SHA A are explicitly invalidated. The trajectory re-enters phase 7: gate 4 (independent review) and gate 5 (boundary verification) re-run at SHA B. The final verified head SHA in packet group (i) is SHA B, not SHA A. The readiness gate (phase 8) is satisfied only after re-verification at the new head. The terminal state is 'merged' with the final verdict bound to SHA B. Claims are scoped to the harness, model, fixtures, and revision under test.", "assertions": ["Gate 4 and gate 5 verdicts are initially recorded in packet group (h) bound to head SHA A (the pre-review implementation head)", "The material review-driven change (null-byte bypass fix altering validation logic) is recorded as producing a new head SHA B distinct from SHA A", "The prior verdicts bound to SHA A are explicitly marked as invalidated in packet group (h) after the material change", "Gate 4 and gate 5 verdicts are re-recorded in packet group (h) bound to head SHA B after re-verification", "The final verified head SHA in packet group (i) equals SHA B, not the stale SHA A", "Terminal lifecycle state in packet group (i) is 'merged' with the merge commit SHA recorded and the final verdict bound to SHA B"]}, {"id": "release-authority-blocked-terminal-state", "prompt": "Issue #688: implement and ship the new caching layer for the product-search service. You have authority to create a PR and get it merged, but the release process requires the VP of Engineering's sign-off which has not been granted. Complete the work and get it deployed.", "expected_output": "Scenario: maintainer/release-authority-blocked terminal state. The trajectory exercises phases 1 through 8 successfully (all gates pass, CI green, review approved, exact-final-head verified). Phase 9 (authorized post-merge release and closeout) cannot proceed because release authority has not been granted. The release gate requires explicit authorization distinct from merge authority; merge alone does not imply release authorization. The trajectory records the blocked release gate with the escalation outcome (release authority not granted) and transitions the packet to the 'blocked' terminal state. The run stops at the release gate without deploying; persistence does not upgrade authority. Claims are scoped to the harness, model, fixtures, and revision under test.", "assertions": ["All five gate verdicts (gate 1 through gate 5) are recorded as pass in packet group (h) bound to the exact final head SHA", "Phase 8 readiness is confirmed with CI passing and review approved at the exact final head SHA recorded in packet group (i)", "The release gate in packet group (h) or (i) records a verdict of 'blocked' citing that release authority was not granted", "The packet distinguishes merge authority (granted) from release authority (not granted) in the authority classification fields of packet group (b)", "Terminal lifecycle state in packet group (i) is 'blocked' with the failing gate ID (release gate) and the blocking evidence (release authority not granted) recorded", "No release activity (tagging, publishing, deploying) appears in the produced artifacts; the run stops at the release gate without deploying"]}, {"id": "lightweight-test-hardening-route", "prompt": "In a public OSS repository, issue #123 says the webhook URL validator already rejects overlong hostnames permanently, but a mutation pilot found that this classification could regress to retryable. Add a focused test-only regression guard, open a PR, and carry it through review.", "expected_output": "Scenario: a low-risk test-hardening change. The trajectory selects the lightweight path rather than the full path because production behavior is already correct and only a test file changes. Phase 1 records the protected public invariant, the named mutation, and production-code non-goals. Conditional planning phases are skipped with reasons. The implementation adds a hermetic public-contract test. Gate 5 uses clean-baseline pass plus targeted-mutant failure, not a requirement that the new test fail on clean main. The candidate is locally final before one push to the expensive-CI repository. Gate 4 is one bounded final review after the candidate is frozen, and readiness is bound to the exact final head SHA. Claims are scoped to the harness, model, fixtures, and revision under test.", "assertions": ["The lightweight path is selected because production behavior is already correct, production code is unchanged, and the change is confined to a test or fixture file", "The change contract records the public invariant, the named retryable-classification mutation, and an explicit production-code non-goal", "Conditional phases 2, 3, 4, and 5 are each recorded as skipped with reasons that identify test hardening and the applicable lightweight criterion", "The produced test uses hermetic setup and asserts the semantic permanent-versus-retryable contract rather than an incidental current exception subtype", "Gate 5 records clean-baseline pass and targeted-mutant failure, without requiring the test to fail on clean main", "The candidate's focused tests, lint, compilation, and scope checks are complete before the first push, and the remote verification is tied to one stable head", "Gate 4 records one bounded final review after candidate freeze, with no repeated reviewer round launched merely because a prior review timed out", "The final readiness evidence binds CI, review, and boundary verification to the exact final head SHA"]}, {"id": "test-hardening-baseline-mutant-gate", "prompt": "A mutation pilot found that changing an already-correct validation error from permanent to retryable would not be caught by the current tests. Add the smallest regression guard without changing production code.", "expected_output": "Scenario: test-hardening rather than a production bugfix. The agent states the semantic invariant, confirms the clean implementation already passes, and identifies the controlled weakening. It adds a deterministic hermetic public-behavior test, records clean-baseline pass and mutant-fail evidence, and does not apply the ordinary fails-on-main requirement. It avoids a broad mutation campaign and escalates only if production code, dependencies, configuration, or another higher-risk surface becomes necessary. Claims are scoped to the harness, model, fixtures, and revision under test.", "assertions": ["The output explicitly classifies the task as a regression guard for already-correct production behavior, not as an active production defect", "The proposed gate is clean-baseline pass plus named-mutant or controlled-weakening failure", "The test is hermetic and exercises the public contract without live external resolution or another incidental prerequisite", "The assertion checks the semantic permanent-versus-retryable invariant rather than exact current implementation identity", "Production code remains unchanged and the verification stays bounded to focused tests, static checks, scope checks, and the targeted mutation", "The output states escalation triggers for production-code, dependency, configuration, security, or deployment changes"]}]} +{"schema_version": 1, "skill_name": "neckbeard", "evals": [{"id": "bug-fix-reproduction-regression", "prompt": "Issue #342 in our inventory service: the CSV export endpoint returns an off-by-one row count when the dataset contains multi-byte UTF-8 characters. Users see 99 rows exported when there are actually 100. Fix this bug and make sure it stays fixed.", "expected_output": "Scenario: straightforward bug fix with reproduction and regression test. The trajectory follows the full journey path through all nine phases (intake and provenance, current-state discovery and reproduction, architecture/design delta, specification, pre-implementation test planning, domain implementation, independent review and boundary verification, readiness and CI/review loops, authorized post-merge release). Phase 2 records reproduction evidence (repro steps, observed vs. expected behavior, environment/version) in delivery packet group (d). A documented 'no architecture delta' determination satisfies gate 1. A regression test is added covering the multi-byte UTF-8 boundary. The verification plan names the regression test as passing evidence. All five gates are recorded in packet group (h) with verdicts bound to the exact head SHA. The terminal lifecycle state is 'merged' with the merge commit SHA recorded in packet group (i). Claims are scoped to the harness, model, fixtures, and revision under test.", "assertions": ["Delivery packet group (d) contains reproduction evidence with repro steps, observed behavior, expected behavior, and environment/version for the bug report", "Gate 1 verdict is recorded as pass with a documented 'no architecture delta' determination in packet group (h)", "A regression test targeting the multi-byte UTF-8 row-count boundary exists in the produced artifacts", "The verification plan in packet group (g) names the regression test as a required passing evidence artifact", "All five gate verdicts (gate 1, gate 2, gate 3, gate 4, gate 5) are recorded in packet group (h) each bound to an exact head SHA", "The final verified head SHA in packet group (i) equals the actual head SHA of the delivered change", "Terminal lifecycle state in packet group (i) is 'merged' with a merge commit SHA recorded"]}, {"id": "ambiguous-feature-product-discovery", "prompt": "Our product manager filed issue #518: 'Add collaborative editing to the document editor.' The request has no acceptance criteria, no scope boundary, and three different stakeholders have posted conflicting comments about what this means. Figure out what to build and deliver it.", "expected_output": "Scenario: ambiguous feature requiring product discovery and scope gate. The trajectory exercises the full journey path. Phase 1 captures provenance and flags the ambiguity. Phase 2 gathers current-state evidence from the codebase and issue comments. The product-discovery specialist is loaded (applicability signal: ambiguous requirements with conflicting stakeholder input) and its engagement is recorded in packet group (e). Phase 4 produces a SPEC.md with acceptance criteria derived from the discovery output; the scope gate (gate 3) verifies that no unbounded or ownerless work items remain. If requirements are irreconcilably ambiguous after product-discovery engagement, the trajectory escalates per phase 4 escalation conditions rather than guessing. The terminal state is 'merged' if scope is resolved, or 'blocked' with escalation evidence if irreconcilable ambiguity halts work. Claims are scoped to the harness, model, fixtures, and revision under test.", "assertions": ["The routing decision in packet group (e) records product-discovery as a selected specialist with an applicability signal citing ambiguous requirements or conflicting stakeholder input", "Packet group (g) contains a SPEC.md with acceptance criteria derived from product-discovery output rather than guessed from the raw issue text", "Gate 3 verdict in packet group (h) confirms spec and task-plan completeness with no unbounded or ownerless work items", "If the trajectory terminates as 'blocked', packet group (i) records the escalation condition (irreconcilable ambiguity) and the phase at which it occurred", "If the trajectory terminates as 'merged', all five gate verdicts are recorded in packet group (h) bound to the exact final head SHA", "The terminal lifecycle state in packet group (i) is either 'merged' with merge evidence or 'blocked' with escalation evidence; no silent abandonment occurs"]}, {"id": "multi-surface-backend-frontend-api-data", "prompt": "Issue #601: we need to add a user-preferences endpoint (REST API), a settings page (React frontend), a PostgreSQL migration for the new preferences table, and the backend service logic to persist and retrieve preferences. All four surfaces must change together for this feature to work.", "expected_output": "Scenario: multi-surface change involving backend, frontend, API, and data routing. The trajectory exercises the full journey path with multiple specialists composed per stage. Phase 6 routing loads backend-engineering (server-side service logic), frontend-engineering (React settings page), api-design-and-evolution (REST endpoint contract), and data-engineering (PostgreSQL migration) with one lead per stage recorded in packet group (e). The multi-row composition rule applies: no two rows own the same stage simultaneously. Gate 1 requires an architecture delta covering the new table and endpoint contract. Gate 2 requires a verification plan exercising the integration boundary across all four surfaces. Gate 5 boundary verification targets integration or end-to-end level. The terminal state is 'merged' with all gates passed. Claims are scoped to the harness, model, fixtures, and revision under test.", "assertions": ["Packet group (e) routing section records backend-engineering, frontend-engineering, api-design-and-evolution, and data-engineering as selected specialists with per-stage lead assignments", "No two specialist rows are recorded as owning the same implementation stage simultaneously in the routing decision", "Gate 1 verdict in packet group (h) references an architecture delta covering the new PostgreSQL table and the REST endpoint contract", "The verification plan in packet group (g) names an integration or end-to-end verification target exercising the boundary across backend, frontend, API, and data surfaces", "Gate 5 verdict in packet group (h) is bound to the exact head SHA and records the verification boundary actually exercised", "Terminal lifecycle state in packet group (i) is 'merged' with all five gate verdicts recorded as pass"]}, {"id": "schema-migration-rollback-release-readiness", "prompt": "Issue #710: we need to split the 'users' table's 'address' column into separate street, city, state, and zip columns. The table has 4.2 million rows in production. This is a high-risk schema migration that needs a rollback plan and release-readiness evidence before we can merge.", "expected_output": "Scenario: schema/migration change requiring rollback and release-readiness evidence. The trajectory exercises the high-risk journey path (all nine phases mandatory, all five gates, no conditional skips). Phase 3 produces an architecture delta with expand/contract (parallel change) migration strategy and a rollback plan that does not rely on git revert. data-engineering and data-architect are loaded per routing signals (migration files present, schema change). Gate 1 requires approval of the migration strategy and rollback plan. Phase 9 records release-readiness evidence (version bump, changelog, migration documentation, rollback rehearsal) before the release gate is evaluated. The terminal state is 'merged' with release readiness confirmed but release activity gated on separate explicit authorization. Claims are scoped to the harness, model, fixtures, and revision under test.", "assertions": ["The high-risk path is recorded in packet group (b) with all nine phases mandatory and no conditional skips permitted", "Packet group (f) contains a migration strategy using expand/contract (parallel change) and a rollback plan that rejects git revert for schema or data changes", "data-engineering and data-architect are recorded as selected specialists in packet group (e) with applicability signals citing migration files or schema change", "Gate 1 verdict in packet group (h) records approval of the architecture delta including the migration strategy and rollback plan", "Release-readiness evidence (version bump, changelog entry, migration documentation) is recorded in packet group (i) before the release gate", "The release gate in packet group (h) or (i) distinguishes pre-merge release readiness from post-merge release activity requiring separate explicit authorization", "Terminal lifecycle state in packet group (i) is 'merged' with the merge commit SHA recorded; release activity is not conflated with merge"]}, {"id": "refactor-characterization-architecture-review", "prompt": "Issue #823: the order-processing module has grown into a 2,400-line god class. Refactor it into smaller, focused modules without changing any observable behavior. We need proof the behavior is preserved.", "expected_output": "Scenario: refactor needing characterization tests and architecture review. The trajectory exercises the refactor journey path (phases 1, 2, 3, 6, 7, 8, 9 mandatory; phases 4 and 5 conditional). Phase 2 gathers current-state evidence of the god class behavior. Phase 3 produces an architecture delta with the decomposition plan; software-architecture-analysis is loaded for the review. Characterization tests are written or identified before the refactor begins to capture existing behavior. Gate 5 uses behavior-preservation evidence (characterization tests passing before and after) as its criterion. The skip of phase 4 is recorded with the reason that the refactor is fully characterized by the architecture delta and characterization-test plan. The terminal state is 'merged' with behavior-preservation evidence recorded. Claims are scoped to the harness, model, fixtures, and revision under test.", "assertions": ["The refactor path is recorded in packet group (b) with phases 4 and 5 conditional", "Packet group (e) records the skip of phase 4 (specification and decomposition) with a reason citing that no separate SPEC.md is needed because the refactor is behavior-preserving", "software-architecture-analysis is recorded as a selected specialist in packet group (e) for the architecture review", "Characterization tests covering the god class observable behavior exist in the produced artifacts before the refactor commits begin", "Gate 5 verdict in packet group (h) records behavior-preservation evidence (characterization tests passing before and after) bound to the exact head SHA", "Terminal lifecycle state in packet group (i) is 'merged' with the merge commit SHA recorded"]}, {"id": "docs-only-reduced-path-skip-reasons", "prompt": "Issue #901: the API reference page in our docs site has outdated parameter names for the /v2/orders endpoint. Update the documentation to match the current implementation. No code changes are needed.", "expected_output": "Scenario: docs-only change using a reduced (lightweight) path with comprehensive skip recording. The trajectory exercises the lightweight journey path (phases 1, 6, 7, 8, 9 mandatory; phases 2, 3, 4, 5 conditional and skipped). Each skipped phase is recorded in packet group (e) with a concrete reason citing the path's skip criterion. At least two specialist skills that do not apply (backend-engineering, frontend-engineering, data-engineering) are explicitly listed as skipped with reasons citing their routing-table skip rules (e.g., 'no server-side application code modified', 'no client-side application code modified', 'no schema or migration files modified'). No specialist skill in the routing matrix is absent from both the selected and skipped lists. The terminal state is 'merged' with doc-update evidence. Claims are scoped to the harness, model, fixtures, and revision under test.", "assertions": ["The lightweight path is recorded in packet group (b) and phases 2, 3, 4, and 5 are each recorded as skipped in packet group (e) with a concrete reason citing the path's skip criterion", "Packet group (e) routing section lists at least three specialist skills (including backend-engineering, frontend-engineering, and data-engineering) as skipped, each with a skill name and a concrete reason", "Every skipped skill entry in packet group (e) has both a skill name and a non-empty reason; no specialist in the routing matrix is absent from both the selected and skipped lists", "technical-documentation is recorded as a selected specialist in packet group (e) with an applicability signal citing documentation changes", "No code-editing commits appear in the produced artifacts; only documentation files are changed", "Terminal lifecycle state in packet group (i) is 'merged' with the merge commit SHA recorded"]}, {"id": "existing-pr-duplicate-detection", "prompt": "Issue #455 was filed asking for rate limiting on the public API. I want to start working on it and submit a PR.", "expected_output": "Scenario: issue with an existing PR or duplicate work. The trajectory exercises the lifecycle pre-work checks in phase 1 (intake and provenance). The existing-PR search discovers that PR #450 from another contributor already implements rate limiting for the same endpoint. The duplicate-issue check and existing-PR check are recorded as distinct pre-work checks in packet group (d) or the lifecycle fields. The handling decision is to coordinate or defer to the existing PR owner rather than opening a duplicate PR. The terminal lifecycle state is 'closed' with the close reason recording the duplicate-work determination and the existing PR reference. No new PR is opened. Claims are scoped to the harness, model, fixtures, and revision under test.", "assertions": ["Packet group (d) or lifecycle fields record a duplicate-issue check result and a separate existing-PR search result as distinct pre-work checks", "The existing-PR search result identifies the pre-existing PR (by number or reference) addressing the same rate-limiting work", "The handling decision recorded in the packet is to coordinate or defer, not to open a duplicate PR", "No new review submission (PR or equivalent) is created in the produced artifacts", "Terminal lifecycle state in packet group (i) is 'closed' with a close reason citing the duplicate-work determination and referencing the existing PR"]}, {"id": "review-round-material-change-reverification", "prompt": "Issue #567: add input validation to the user-registration form. During code review, a reviewer points out that the validation logic has a bypass when the input contains null bytes. You push a fix addressing the null-byte bypass. This changes the validation logic materially.", "expected_output": "Scenario: review round that changes the final head and requires re-verification, proving a material post-review change invalidates the prior verification verdict. The trajectory exercises phases 1 through 8. Phase 7 (independent review and boundary verification) produces gate 4 and gate 5 verdicts bound to head SHA A (the initial implementation). A material review-driven change (the null-byte bypass fix altering validation logic) produces head SHA B. The prior verdicts bound to SHA A are explicitly invalidated. The trajectory re-enters phase 7: gate 4 (independent review) and gate 5 (boundary verification) re-run at SHA B. The final verified head SHA in packet group (i) is SHA B, not SHA A. The readiness gate (phase 8) is satisfied only after re-verification at the new head. The terminal state is 'merged' with the final verdict bound to SHA B. Claims are scoped to the harness, model, fixtures, and revision under test.", "assertions": ["Gate 4 and gate 5 verdicts are initially recorded in packet group (h) bound to head SHA A (the pre-review implementation head)", "The material review-driven change (null-byte bypass fix altering validation logic) is recorded as producing a new head SHA B distinct from SHA A", "The prior verdicts bound to SHA A are explicitly marked as invalidated in packet group (h) after the material change", "Gate 4 and gate 5 verdicts are re-recorded in packet group (h) bound to head SHA B after re-verification", "The final verified head SHA in packet group (i) equals SHA B, not the stale SHA A", "Terminal lifecycle state in packet group (i) is 'merged' with the merge commit SHA recorded and the final verdict bound to SHA B"]}, {"id": "release-authority-blocked-terminal-state", "prompt": "Issue #688: implement and ship the new caching layer for the product-search service. You have authority to create a PR and get it merged, but the release process requires the VP of Engineering's sign-off which has not been granted. Complete the work and get it deployed.", "expected_output": "Scenario: maintainer/release-authority-blocked terminal state. The trajectory exercises phases 1 through 8 successfully (all gates pass, CI green, review approved, exact-final-head verified). Phase 9 (authorized post-merge release and closeout) cannot proceed because release authority has not been granted. The release gate requires explicit authorization distinct from merge authority; merge alone does not imply release authorization. The trajectory records the blocked release gate with the escalation outcome (release authority not granted) and transitions the packet to the 'blocked' terminal state. The run stops at the release gate without deploying; persistence does not upgrade authority. Claims are scoped to the harness, model, fixtures, and revision under test.", "assertions": ["All five gate verdicts (gate 1 through gate 5) are recorded as pass in packet group (h) bound to the exact final head SHA", "Phase 8 readiness is confirmed with CI passing and review approved at the exact final head SHA recorded in packet group (i)", "The release gate in packet group (h) or (i) records a verdict of 'blocked' citing that release authority was not granted", "The packet distinguishes merge authority (granted) from release authority (not granted) in the authority classification fields of packet group (b)", "Terminal lifecycle state in packet group (i) is 'blocked' with the failing gate ID (release gate) and the blocking evidence (release authority not granted) recorded", "No release activity (tagging, publishing, deploying) appears in the produced artifacts; the run stops at the release gate without deploying"]}, {"id": "lightweight-test-hardening-route", "prompt": "In a public OSS repository, issue #123 says the webhook URL validator already rejects overlong hostnames permanently, but a mutation pilot found that this classification could regress to retryable. Add a focused test-only regression guard, open a PR, and carry it through review.", "expected_output": "Scenario: a low-risk test-hardening change. The trajectory selects the lightweight path rather than the full path because production behavior is already correct and only a test file changes. Phase 1 records the protected public invariant, the named mutation, and production-code non-goals. Conditional planning phases are skipped with reasons. The implementation adds a hermetic public-contract test. Gate 5 uses clean-baseline pass plus targeted-mutant failure, not a requirement that the new test fail on clean main. The candidate is locally final before one push to the expensive-CI repository. Gate 4 is one bounded final review after the candidate is frozen, and readiness is bound to the exact final head SHA. Claims are scoped to the harness, model, fixtures, and revision under test.", "assertions": ["The lightweight path is selected because production behavior is already correct, production code is unchanged, and the change is confined to a test or fixture file", "The change contract records the public invariant, the named retryable-classification mutation, and an explicit production-code non-goal", "Conditional phases 2, 3, 4, and 5 are each recorded as skipped with reasons that identify test hardening and the applicable lightweight criterion", "The produced test uses hermetic setup and asserts the semantic permanent-versus-retryable contract rather than an incidental current exception subtype", "Gate 5 records clean-baseline pass and targeted-mutant failure, without requiring the test to fail on clean main", "The candidate's focused tests, lint, compilation, and scope checks are complete before the first push, and the remote verification is tied to one stable head", "Gate 4 records one bounded final review after candidate freeze, with no repeated reviewer round launched merely because a prior review timed out", "The final readiness evidence binds CI, review, and boundary verification to the exact final head SHA"]}, {"id": "test-hardening-baseline-mutant-gate", "prompt": "A mutation pilot found that changing an already-correct validation error from permanent to retryable would not be caught by the current tests. Add the smallest regression guard without changing production code.", "expected_output": "Scenario: test-hardening rather than a production bugfix. The agent states the semantic invariant, confirms the clean implementation already passes, and identifies the controlled weakening. It adds a deterministic hermetic public-behavior test, records clean-baseline pass and mutant-fail evidence, and does not apply the ordinary fails-on-main requirement. It avoids a broad mutation campaign and escalates only if production code, dependencies, configuration, or another higher-risk surface becomes necessary. Claims are scoped to the harness, model, fixtures, and revision under test.", "assertions": ["The output explicitly classifies the task as a regression guard for already-correct production behavior, not as an active production defect", "The proposed gate is clean-baseline pass plus named-mutant or controlled-weakening failure", "The test is hermetic and exercises the public contract without live external resolution or another incidental prerequisite", "The assertion checks the semantic permanent-versus-retryable invariant rather than exact current implementation identity", "Production code remains unchanged and the verification stays bounded to focused tests, static checks, scope checks, and the targeted mutation", "The output states escalation triggers for production-code, dependency, configuration, security, or deployment changes"]}, {"id": "midflight-position-assessment", "prompt": "Pick up where the previous contractor left off on the payment-retry feature. Branch feat/payment-retry exists with about six commits, there is a SPEC.md sitting on that branch, and the handoff note says 'design approved, most of the tests written'. No delivery packet or evidence ledger was handed over. Figure out where the work actually stands and continue it to a reviewed change.", "expected_output": "Scenario: mid-flight engagement with no delivery packet. The trajectory recognizes the entry-mode condition (continuation of work started elsewhere, no packet) and runs position assessment before any implementation continuation. It inventories observable artifacts: branch commits via git log against the base ref, SPEC.md presence and completeness on the branch, whether TASK-PLAN.md and VERIFICATION-PLAN.md exist, CI state, and any review artifacts. Each artifact is scored against the corresponding phase exit conditions. The handoff narrative ('design approved, most tests written') is treated as unverified assumption, not as satisfied gates, unless artifacts support it. The position report names the current phase, satisfied gates with evidence pointers, partial/absent/contradicted items, and a remaining checklist before execution resumes. Verified-complete work is not re-executed. A delivery packet is bootstrapped: group (a) records mid-flight engagement and inventory pointers, group (b) re-selects the delivery path from the affected surface, group (c) initializes from the position report with the assessment-time head SHA. Gates without evidence remain open rather than being retroactively marked passed.", "assertions": ["The trajectory runs position assessment before any implementation continuation, rather than restarting at phase-1 intake or accepting the handoff narrative as ground truth", "Each satisfied gate in the position report is bound to an observable artifact pointer (path, commit SHA, or CI/tracker reference), not to the contractor's claims", "The narrative claims ('design approved, most of the tests written') are recorded as unverified assumptions rather than satisfied gates, absent supporting artifacts", "The position report names the current phase, satisfied gates with evidence pointers, and an explicit remaining checklist before execution continues", "Verified-complete work identified during assessment is not re-executed; the run continues from the assessed position", "A delivery packet is bootstrapped recording mid-flight engagement, a re-selected delivery path, and the assessment-time head SHA, without retroactively marking unevidenced gates as passed"]}, {"id": "tracker-discovery-linear-routing", "prompt": "We track this project's work in Linear; the code repo mirrors to GitHub for hosting and review. Take ticket ENG-482 ('Add idempotency keys to the webhook receiver') through your delivery lifecycle to a reviewed change.", "expected_output": "Scenario: change-request journey on a product whose tracking system is Linear. During phase-1 intake the trajectory identifies Linear as the tracking system from the request's own evidence (the ENG-482 ticket reference), records the detection and its basis in delivery packet group (a), and routes tracker operations (reading the ticket, posting transitions and comments) to the linear tooling skill rather than improvising GraphQL calls or defaulting to GitHub Issues. GitHub's role is correctly scoped to code hosting, branch, and review mechanics per the platform reference mode. The trajectory's own vocabulary stays tracker-neutral (work item, state transition, review submission) with platform nouns confined to platform mapping. The first mutation against Linear passes the state-change confirmation gate (target, scope, rollback path) before executing. Sequencing, gates, and evidence ownership remain with the journey spine; the linear skill is used as a mechanical layer, never as a second orchestrator.", "assertions": ["Intake records Linear as the identified tracking system together with the evidence basis (the request's own ticket reference) in delivery packet group (a) before any tracker operation", "Tracker operations route to the linear tooling skill rather than improvised API calls or defaulting to GitHub Issues", "GitHub's role is correctly scoped to code hosting and review mechanics; tracker operations do not migrate to GitHub Issues by assumption", "The trajectory's tracker vocabulary stays tracker-neutral (work item, state transition), with platform-specific nouns confined to platform mapping", "The first mutation against Linear passes the state-change confirmation gate (target, scope, rollback path) before executing", "Sequencing and gate authority remain with the journey spine; the linear skill operates as a mechanical layer, not an orchestrator"]}]} diff --git a/neckbeard/references/journey.md b/neckbeard/references/journey.md index 18436b3..d5c6754 100644 --- a/neckbeard/references/journey.md +++ b/neckbeard/references/journey.md @@ -19,6 +19,20 @@ named packet field groups. Gate verdicts are recorded in packet group (h). Skipped phases and skills are recorded in packet group (e) with concrete reasons; silent omission is prohibited. +This journey is tracker-neutral: it speaks of *work items*, *state +transitions*, *review submissions*, and *merge or acceptance into the protected +target*, never of one platform's nouns. Which tracking system holds the work +item is established during phase 1 intake by +[tracker-discovery.md](tracker-discovery.md), and tracker operations route to +the matching catalog tooling skill; platform mechanics live in the platform +mapping rows below and in [lifecycle.md](lifecycle.md). + +Entry normally begins at phase 1. When the work being requested **already +started elsewhere** — no delivery packet exists because the earlier run happened +outside this bundle — do not restart intake blindly: enter through +[position-assessment.md](position-assessment.md) first, then continue from the +assessed position under this journey's rules. + --- ## The nine phases @@ -29,8 +43,8 @@ silent omission is prohibited. |---|---| | **Owner** | neckbeard framing step (core loop step 1) | | **Input** | A change request: issue URL/number, ticket ID, email thread, or verbal request. | -| **Output** | Packet groups (a) provenance and (b) authority/mode/path populated: change-request URL/number and source type, repository, base ref, issue/comment snapshot including **repository conventions** (`CONTRIBUTING.md`, `AGENTS.md`, or equivalent) and **linked/referenced work** (related issues, PRs, commits); granted authority class; selected workflow mode (GitHub or enterprise); selected path. A change contract ([../templates/change-contract.md](../templates/change-contract.md)) exists. | -| **Gate** | The intake gate: provenance, authority, repository conventions, and linked work are captured. No planning phase may begin until these fields are populated. | +| **Output** | Packet groups (a) provenance and (b) authority/mode/path populated: change-request URL/number and source type, repository, base ref, issue/comment snapshot including **repository conventions** (`CONTRIBUTING.md`, `AGENTS.md`, or equivalent) and **linked/referenced work** (related issues, PRs, commits); **tracking system** identified per [tracker-discovery.md](tracker-discovery.md) (detected or requester-confirmed, with the evidence basis recorded); granted authority class; selected workflow mode (GitHub or enterprise); selected path. A change contract ([../templates/change-contract.md](../templates/change-contract.md)) exists. | +| **Gate** | The intake gate: provenance, authority, repository conventions, linked work, and the identified tracking system are captured. No planning phase may begin until these fields are populated. | | **Escalation** | Authority is ambiguous between explore and modify; or the stated goal conflicts with a hard constraint (security, data safety, policy, license); or maintainer direction conflicts with proceeding (see [risk-authority-gates.md](risk-authority-gates.md) stop rules). | | **Platform mapping** | **GitHub mode:** issue body + comments + labels captured via `gh`; `CONTRIBUTING.md` and `.github/` conventions discovered per repository. **Enterprise mode:** ticket-tracker snapshot (ticket ID, description, comments); internal contribution governance or change-governance docs captured. | diff --git a/neckbeard/references/position-assessment.md b/neckbeard/references/position-assessment.md new file mode 100644 index 0000000..d0787b2 --- /dev/null +++ b/neckbeard/references/position-assessment.md @@ -0,0 +1,156 @@ +# Position Assessment — Mid-Flight Engagement Entry Mode + +Some engagements begin mid-flight: the agent is asked to continue software +delivery work that started elsewhere — a half-implemented branch, an adopted +specification, a change request another contributor began — and no delivery +packet exists because the earlier work did not run inside this bundle. The +nine-phase journey ([journey.md](journey.md)) describes the canonical forward +path from intake; it does not describe how to enter that path honestly when the +first six phases may already be partly done. + +This reference defines that entry mode. It is loaded by [../SKILL.md](../SKILL.md) +only for mid-flight engagement. It is **not** loaded when a fresh change request +starts the journey at phase 1, and **not** loaded when the run's own delivery +packet exists — packet resumability +([delivery-packet.md](delivery-packet.md)) governs that case, and the packet is +authoritative there. + +The procedure answers three questions before any execution continues: + +1. What step is the work actually on? +2. Which gates have evidence behind them, and which remain? +3. What is the next justified action? + +## The core rule: artifacts, not narratives + +Position is established from observable artifacts — files, commits, CI runs, +review states — scored against the exit conditions the phases define. It is +never established from summaries, however confident. "The spec was approved" +is not a satisfied gate; an approved `SPEC.md` artifact with a recorded gate +verdict is. A claim with no inspectable artifact behind it becomes a recorded +**unverified assumption**, never a satisfied gate. + +This is the same doctrine the rest of the bundle applies to verification: +assertions are not evidence. Assessment inherits it. + +## Procedure + +### Step 1 — Trigger check + +Enter this mode only when all three hold: + +| Condition | How to check | +|---|---| +| The request is to continue existing delivery work | The request references ongoing work (a branch, spec, partial implementation) rather than a fresh change | +| No delivery packet exists for that work | No packet artifact accompanies the work; the prior run, if any, was outside this bundle | +| The work is non-trivial enough to warrant the journey | Same threshold [../SKILL.md](../SKILL.md) applies before loading the journey | + +If a packet exists, use [delivery-packet.md](delivery-packet.md) resumability +instead. If no artifacts exist at all, the honest position is **phase 1**: say +so plainly and let the normal journey take over. An empty inventory is a +finding, not a failure. + +### Step 2 — Inventory the observable artifacts + +Search the working repository and tracker for the artifacts the phases would +have produced: + +| Observable artifact | Produced by | Typical locations | +|---|---|---| +| Change contract (problem, constraints, authority) | Phase 1 | Issue/ticket body, PR description, [../templates/change-contract.md](../templates/change-contract.md) instance | +| Repository conventions captured | Phase 1 | Evidence that `CONTRIBUTING.md` / `AGENTS.md` were consulted | +| Baseline and reproduction evidence | Phase 2 | Repro steps in the issue, failing-test transcripts, benchmark notes | +| Architecture delta, ADR, C4 diagrams, or a documented no-delta determination | Phase 3 | `docs/adr/`, design docs, decision-record instances | +| `SPEC.md`, `TASK-PLAN.md` | Phase 4 | Repository root or working branch | +| `VERIFICATION-PLAN.md` | Phase 5 | Working branch | +| Implementation commits on a working branch | Phase 6 | `git log ..HEAD` | +| `VERIFICATION.md`, independent review verdicts | Phase 7 | Working branch, PR review states | +| Green CI and approved review at a known head SHA | Phase 8 | CI checks, review approvals bound to a specific SHA | +| Merge commit, release tag, deploy confirmation | Phase 9 | Protected-target history, tags, deploy logs | + +Inventory reads are read-only discovery; they need no confirmation. Record +where each artifact was found (path, SHA, URL) — pointers become the evidence +references in the report. + +### Step 3 — Score against phase exit conditions + +Compare each inventoried artifact with the exit condition and gate definition +of its phase ([journey.md](journey.md); gate semantics in +[stages.md](stages.md)). Assign exactly one verdict per phase: + +| Verdict | Meaning | +|---|---| +| **Satisfied** | The artifact exists and meets the phase exit condition. Record the evidence pointer. | +| **Partial** | The artifact exists but is incomplete or unapproved. Name exactly what remains. | +| **Absent** | No artifact found. The gate is not passed. | +| **Contradicted** | An artifact exists but observable evidence conflicts with it (for example, readiness claimed while CI is red at the recorded head). Contradiction blocks progression until resolved. | + +Scoring constraints: + +- Score the selected delivery path's mandatory phases; conditional phases are + scored only if their artifacts exist (an absent conditional phase with a + legitimate skip reason is recorded as such, not penalized). +- Verified-complete work is **not** re-executed, mirroring packet-resume + semantics. Assessment establishes position; it does not redo accepted work. +- Never upgrade a verdict to fill a gap. A missing gate verdict is `absent`, + even when the underlying work looks done. +- Two contradictory sources (artifact says approved, tracker says changes + requested) yield `contradicted`, and the conflict itself is reported. + +### Step 4 — Emit the position report + +Produce the report and deliver it to the requester **before** continuing +execution. Format: + +``` +current phase: - +selected path: (re-selected, see below) +satisfied gates: @ ; ... +partial: — +absent: +contradicted: — +remaining checklist: [ ] ; [ ] ... +unverified assumptions: +recommended next action: +``` + +The remaining checklist is the contract for continuation: work proceeds +against it in journey order, respecting the five-gate sequence and every stop +rule in [risk-authority-gates.md](risk-authority-gates.md). + +### Step 5 — Bootstrap the packet + +Create a fresh delivery packet so subsequent operation has normal resumability: + +- Group (a) provenance records: engaged mid-flight, artifacts assessed, with + the inventory pointers. +- Group (b) records the re-selected delivery path (path selection per + [../SKILL.md](../SKILL.md) § Path selection — re-run it here; do not inherit + a path assumption from the prior work). +- Group (c) initializes from the position report: current phase, current gate, + and the head SHA at assessment time. +- Unverified assumptions go to the evidence ledger + ([evidence-ledger.md](evidence-ledger.md)), not into gate fields. + +Do **not** retroactively mark gates as passed in group (h) without artifacts. +Gates with genuine evidence pointers may be recorded as passed with those +pointers; everything else remains open. + +## Completion and exit conditions + +Assessment is complete when the position report has been delivered and the +packet bootstrapped. The mode then ends: execution continues under the normal +journey and core loop. If the inventory is empty, completion is the honest +statement "no artifacts found — starting at phase 1" plus the same bootstrap. + +## Non-goals + +- This is not a quality audit of the existing work. It establishes position; + phase 7 review still judges quality. +- It does not bypass gates. Only gates with real evidence may be marked + satisfied; the rest must actually run. +- It does not replace packet resumability. Where a packet exists, the packet + wins. +- It does not guess at intent behind ambiguous prior work. When the change + contract cannot be reconstructed from artifacts, that is a phase-1 gap, and + intake happens properly. diff --git a/neckbeard/references/routing-table.md b/neckbeard/references/routing-table.md index f0c1f6a..dd57dcd 100644 --- a/neckbeard/references/routing-table.md +++ b/neckbeard/references/routing-table.md @@ -53,6 +53,9 @@ defaults without qualification. | `data-architect` | Change requires a data-model design artifact, storage-platform evaluation, data-governance definition (ownership, lineage, cataloging), or cross-system data-flow diagram before implementation | No data-model artifact, storage-platform evaluation, data-governance definition, or cross-system data-flow design is required; schema changes are mechanical | Contract, ledger | | `agent-evals-and-observability` | Change modifies AI/agent behavior: eval definitions, agent task contracts, grader bindings, trajectory fixtures, prompt templates, or agent observability/telemetry | No agent eval, task contract, grader, trajectory fixture, prompt template, or agent telemetry is created or modified | Contract, ledger | | `opensource-contributions` | **Conditional — public/OSS repos only.** Repository remote is public, an open-source license is present, and a `CONTRIBUTING.md` or equivalent contribution governance file exists (verify via repo remote or `gh api`); contribution norms, agent disclosure, or fork etiquette apply | Repository is private or enterprise-internal (non-public remote, no open-source license); record skip as "non-public repository." Also skip when no contribution-norm question arises even in a public repo | Contract, ledger | +| `linear` | The product's tracking system was identified as Linear by [tracker-discovery.md](tracker-discovery.md) during intake, and tracker operations are needed (read/update work items, transitions, comments) | Tracking system is not Linear; or the change needs no tracker operation beyond reading provenance already captured | Contract, ledger | +| `jira-cli` | The tracking system was identified as Jira by [tracker-discovery.md](tracker-discovery.md), and tracker operations are needed | Tracking system is not Jira; or no tracker operation is needed beyond captured provenance | Contract, ledger | +| `notion` | The tracking system was identified as Notion by [tracker-discovery.md](tracker-discovery.md), and tracker operations are needed | Tracking system is not Notion; or no tracker operation is needed beyond captured provenance | Contract, ledger | ## Test-hardening evidence diff --git a/neckbeard/references/tracker-discovery.md b/neckbeard/references/tracker-discovery.md new file mode 100644 index 0000000..2c2b1c6 --- /dev/null +++ b/neckbeard/references/tracker-discovery.md @@ -0,0 +1,89 @@ +# Tracker Discovery — Tracker-Neutral Intake + +The change-request journey is defined in tracker-neutral terms: *work item*, +*state transition*, *review submission*, *merge or acceptance into the protected +target*, *release authorization*. Platform mechanics belong to the layer that +operates the platform — the routing rows in +[routing-table.md](routing-table.md) and the platform reference modes +([lifecycle.md](lifecycle.md)) — not to the spine itself. + +That separation only works if intake actually establishes which tracking system +the product uses. This reference defines that sub-step of phase 1 +([journey.md](journey.md), Intake and provenance). It exists because +improvisation under ambiguity defaults to whatever platform the agent knows +best, and the correct answer is detection plus an explicit question, not a +default. + +## The rule + +**Never assume the tracking system.** Detect it from repository evidence where +possible; ask the requester when evidence is absent or contradictory; record +the finding and its basis in delivery packet group (a) before any tracker +operation runs. + +Read-only identification is discovery and needs no confirmation. The first +mutation against the detected system still passes the normal state-change gate +([risk-authority-gates.md](risk-authority-gates.md)). + +## Detection procedure + +Run during phase 1 alongside provenance capture: + +1. **Inspect remotes and configuration** for tracking-system fingerprints: + +| Signal | Points to | +|---|---| +| Issue/ticket URLs referenced by the change request (`…/issues/N`, `…/TICKET-123`, Linear `…/issue/TEAM-N`) | GitHub Issues / Jira / Linear respectively | +| `.jira-url`, Jira config files in the repository | Jira | +| Team keys in ticket identifiers (`ENG-42` shape) with a non-GitHub tracker configured | Jira or Linear | +| Project-management config directories (for example `.linear/`) or documented integrations in `CONTRIBUTING.md`, `AGENTS.md`, README | Whatever they name | + +2. **Check what the request itself references.** A change request arriving as a + Linear issue URL, a Jira ticket ID, or a GitHub issue number is direct + evidence for its own system. + +3. **Ask when ambiguous or absent.** If signals conflict (repo mirrors to + GitHub but issues live in Jira) or none exist, ask one bounded question: + which system holds this work item? Record the answer as requester-provided + provenance. Do not silently pick the system whose CLI happens to be installed. + +4. **Record in packet group (a):** detected/requested system, the evidence or + source of the answer, and the routing decision below. Silent omission is + prohibited like every other intake field. + +## Routing tracker operations + +Operate the detected system through its catalog tooling skill rather than +improvising API calls: + +| Detected system | Route operations to | +|---|---| +| GitHub (issues, PRs, releases) | Native mechanics per [lifecycle.md](lifecycle.md) — the documented reference mode | +| Linear | `linear` | +| Jira | `jira-cli` | +| Notion | `notion` | +| Other / none of the above | No specialist route: operate through the system's own documented interface with bounded reads, and note the absent specialist in the ledger | + +Routing constraints: + +- Every named routing target must be a real skill in this catalog; dead links + are a defect. If a target is missing from an installation, proceed on the + fallback and record the absence — same convention as + [routing-table.md](routing-table.md) § When no specialist is installed. +- Tooling skills are mechanical layers. They own commands and API contracts; + the journey owns sequencing, and discipline specialists own judgment. No + tracker skill becomes a second orchestrator. +- Vocabulary crossing the boundary stays neutral: a "state transition" maps to + whichever transition the target system defines (workflow state move, label + change, status update); the packet records outcomes by neutral name. + +## Non-goals + +- This step does not migrate content between systems or reconcile divergent + trackers. If work items exist on two systems, surface the conflict at intake + and ask which is authoritative. +- It does not change credential handling. Each tooling skill's own setup rules + apply. +- It does not make the journey depend on any single vendor. Absence of a + tracker, or use of an unrouted system, degrades gracefully to the fallback + path.