yasdef-worker 0.2.1__py3-none-any.whl

yasdef_worker/__init__.py

@@ -0,0 +1,3 @@
+"""YASDEF worker package."""
+
+__version__ = "0.1.0"

yasdef_worker/_data/commands/yasdef/audit.md

@@ -0,0 +1,16 @@
+---
+description: Run the YASDEF ASDLC worker ai_audit phase via the yasdef-worker-ai-audit skill.
+---
+
+Use the `yasdef-worker-ai-audit` skill to run the ASDLC worker ai_audit phase.
+
+Inputs:
+- Step: $1
+- Feature id: $2
+- Branch: $3
+- Step plan: $4
+- Design artifact: $5
+- Runtime implementation plan: $6
+- Worker id: $7
+
+If any of the seven inputs above is missing, empty, or points to a missing required file, stop and ask the user for the missing input. Do not read `.asdlc_worker/feature_meta_sync.yaml` and do not infer any of the seven inputs from runtime context.

yasdef_worker/_data/commands/yasdef/design.md

@@ -0,0 +1,15 @@
+---
+description: Run the YASDEF ASDLC worker design phase via the yasdef-worker-design skill.
+---
+
+Use the `yasdef-worker-design` skill to run the ASDLC worker design phase.
+
+Inputs:
+- Step: $1
+- Feature id: $2
+- Branch: $3
+- Design output: $4
+- Runtime implementation plan: $5
+- Runtime requirements EARS: $6
+
+If any of the six inputs above is missing, empty, or points to a missing required file, stop and ask the user for the missing input. Do not read `.asdlc_worker/feature_meta_sync.yaml` and do not infer any of the six inputs from runtime context.

yasdef_worker/_data/commands/yasdef/implementation.md

@@ -0,0 +1,15 @@
+---
+description: Run the YASDEF ASDLC worker implementation phase via the yasdef-worker-implementation skill.
+---
+
+Use the `yasdef-worker-implementation` skill to run the ASDLC worker implementation phase.
+
+Inputs:
+- Step: $1
+- Feature id: $2
+- Branch: $3
+- Step plan: $4
+- Design artifact: $5
+- Runtime implementation plan: $6
+
+If any of the six inputs above is missing, empty, or points to a missing required file, stop and ask the user for the missing input. Do not read `.asdlc_worker/feature_meta_sync.yaml` and do not infer any of the six inputs from runtime context.

yasdef_worker/_data/commands/yasdef/plan.md

@@ -0,0 +1,17 @@
+---
+description: Run the YASDEF ASDLC worker planning phase via the yasdef-worker-plan skill.
+---
+
+Use the `yasdef-worker-plan` skill to run one ASDLC worker planning iteration.
+
+Inputs:
+- Step: $1
+- Feature id: $2
+- Branch: $3
+- Design artifact: $4
+- Step plan output: $5
+- Runtime implementation plan: $6
+- Open questions ledger: $7
+- Blockers ledger: $8
+
+If any of the eight inputs above is missing, empty, or points to a missing required file, stop and ask the user for the missing input. Do not read `.asdlc_worker/feature_meta_sync.yaml` and do not infer any of the eight inputs from runtime context.

yasdef_worker/_data/commands/yasdef/user-review.md

@@ -0,0 +1,15 @@
+---
+description: Run the YASDEF ASDLC worker user review phase via the yasdef-worker-user-review skill.
+---
+
+Use the `yasdef-worker-user-review` skill to run the ASDLC worker user review phase.
+
+Inputs:
+- Step: $1
+- Feature id: $2
+- Branch: $3
+- Step plan: $4
+- Design artifact: $5
+- Runtime implementation plan: $6
+
+If any of the six inputs above is missing, empty, or points to a missing required file, stop and ask the user for the missing input. Do not read `.asdlc_worker/feature_meta_sync.yaml` and do not infer any of the six inputs from runtime context.

yasdef_worker/_data/golden_examples/blocker_log_GOLDEN_EXAMPLE.md

@@ -0,0 +1,26 @@
+# Blocker Log - Golden Example
+
+This file demonstrates the preferred structure for entries in `.asdlc_worker/blocker_log.md`.
+
+Rules:
+- Only record true blockers for in-progress steps.
+- Keep entries concise and actionable.
+
+Template:
+## Step <step> <step title>
+- No blockers identified.
+- Blocker: <short description>
+  - Impact: <why it blocks progress>
+  - Needed: <decision, info, or action required>
+  - Status: Open | Resolved
+
+---
+
+## Step 1.6b CPMM AMM trading (public buy/sell)
+- Blocker: Fee rounding policy not defined.
+  - Impact: Trade math depends on deterministic rounding rules; cannot finalize formulas.
+  - Needed: Decision on rounding direction and acceptable precision.
+  - Status: Open
+
+## Step 1.6c Redemption after resolution (public redeem)
+- No blockers identified.

yasdef_worker/_data/golden_examples/decisions_GOLDEN_EXAMPLE.md

@@ -0,0 +1,30 @@
+# Decisions (ADR-lite) - Golden Example
+
+This file demonstrates the preferred structure for entries in `.asdlc_worker/decisions.md`.
+
+Rules:
+- Keep the decision concise and focused on the "why".
+- Link to requirements, plan steps, or code when applicable.
+
+Template:
+- **ID**: ADR-XXXX
+- **Status**: Proposed | Accepted | Superseded
+- **Superseded by**: ADR-XXXX (optional)
+- **Date**: YYYY-MM-DD
+- **Context**
+- **Decision**
+- **Consequences**
+- **Related**: requirements / plan steps / code
+
+---
+
+## ADR-9999 — Example decision title
+- **Status**: Accepted
+- **Date**: 2026-02-11
+- **Context**: Briefly describe the problem and why a decision is needed.
+- **Decision**:
+  - State the chosen approach.
+  - Include key rules or constraints.
+- **Consequences**:
+  - Note the impact on behavior, risk, or maintenance.
+- **Related**: `../my-asdlc-project/feature-name/requirements_ears.md` (REQ-XX), `../my-asdlc-project/feature-name/implementation_plan.md` (Step X.Y), `src/main/java/...`

yasdef_worker/_data/golden_examples/history_GOLDEN_EXAMPLE.md

@@ -0,0 +1,17 @@
+# AI Run History - Golden Example
+
+This file demonstrates the preferred entry format for `.asdlc_worker/history.md`.
+
+## 2026-02-11T18:05:42Z
+- Step: 1.6e - Example step title
+- Token usage: total=765,432 input=612,345 (+ 4,500,000 cached) output=153,087 (reasoning 91,234), including:
+  - Phase: design - total=80,000 input=62,000 (+ 800,000 cached) output=18,000 (reasoning 9,000)
+  - Phase: planning - total=123,456 input=100,000 (+ 1,000,000 cached) output=23,456 (reasoning 12,345)
+  - Phase: implementation - total=345,678 input=287,654 (+ 2,500,000 cached) output=58,024 (reasoning 34,567)
+  - Phase: user_review - total=96,298 input=80,000 (+ 600,000 cached) output=16,298 (reasoning 9,876)
+  - Phase: ai_audit - total=120,000 input=82,691 (+ 600,000 cached) output=37,309 (reasoning 25,446)
+- Workflow phases for the step: design -> planning -> implementation -> user_review -> ai_audit -> post_review
+- post_review note: non-model consolidation phase (no model token usage line expected).
+- New lines of code added: 312
+- New classes added: 4
+- Step plan: .asdlc_worker/step_plans/step-1.6e.md

yasdef_worker/_data/golden_examples/open_questions_GOLDEN_EXAMPLE.md

@@ -0,0 +1,11 @@
+# Open Questions - Golden Example
+
+This file demonstrates the preferred structure for entries in `.asdlc_worker/open_questions.md`.
+
+## Step 1.11 Security
+- Which JWT verification method should be used (HS256 shared secret vs RS256/JWKS), and what issuer/audience values should be enforced?
+- Which JWT claims carry user identity and banned status (claim names + expected types)?
+- What 401 response shape/title should be used for auth failures (default Quarkus vs `UNAUTHORIZED` in `ErrorCode`)?
+
+## Step 1.6d Market-stream locking for state-gated commands (stream-lock-first)
+- No open questions.

yasdef_worker/_data/golden_examples/user_review_GOLDEN_EXAMPLE.md

@@ -0,0 +1,13 @@
+# User Review Insights - Golden Example
+
+This file demonstrates the preferred structure for entries in `.asdlc_worker/user_review.md`.
+
+## UR-9999 — Example rule title
+- **Status**: Accepted
+- **Date**: 2026-02-11
+- **Context**: Step X.Y Example subsystem
+- **Rule**: State the general rule clearly.
+- **Implemented wrong**: Summarize the general mistake.
+- **User proposed**: Summarize the user’s general fix.
+- **Implementation change**: Summarize how the code was corrected.
+- **References**: `src/main/java/com/example/Foo.java` `src/test/java/com/example/FooIT.java`

yasdef_worker/_data/setup/models.md

@@ -0,0 +1,28 @@
+# Phase | Command | Model | Extra Arg 1 (optional) | Extra Arg 2 (optional) | ...
+# Example: implementation | codex | gpt-5.2-codex | --config | model_reasoning_effort='high'
+#
+# Command column accepts:
+#   codex  - invoked as: codex -m <model> <extras...> "<prompt>"
+#   claude - invoked as: claude --model <model> <extras...> "<prompt>"
+#            Both runners get an interactive TTY via run_with_output_log's
+#            `script -q` wrapper, so claude opens its UI for tool approvals.
+#            Extras pass through verbatim — operator may add e.g. `--allowed-tools`
+#            to skip approval prompts for specific tools.
+#            Example: ai_audit | claude | claude-opus-4-7 | |
+#   echo   - test/local harness runner, invoked as: echo -m <model> <extras...> "<prompt>"
+#
+# Any other Command value is rejected by yasdef.
+
+# design | claude | claude-sonnet-4-6 | | 
+# planning | claude | claude-opus-4-7 | | 
+# implementation | claude | claude-sonnet-4-6 | | 
+# user_review | claude | claude-sonnet-4-6 | | 
+# ai_audit | claude | claude-opus-4-7 | | 
+
+design | codex | gpt-5.4 | --config | model_reasoning_effort='high'
+planning | codex | gpt-5.5 | --config | model_reasoning_effort='high'
+implementation | codex | gpt-5.4 | --config | model_reasoning_effort='high'
+user_review | codex | gpt-5.4 | --config | model_reasoning_effort='high'
+ai_audit |  codex | gpt-5.4 | --config | model_reasoning_effort='high'
+
+

yasdef_worker/_data/skills/yasdef-worker-ai-audit/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: yasdef-worker-ai-audit
+description: Run the YASDEF ASDLC worker ai_audit phase for an assigned step. Use when yasdef or the user asks to perform post-user-review analysis-only audit, produce findings, disposition each finding to a terminal state, and finish audit handoff before post_review.
+metadata:
+  short-description: YASDEF worker ai_audit phase
+---
+
+# YASDEF Worker AI Audit
+
+Use this skill for the ASDLC worker ai_audit phase. This phase is analysis-only: do not modify runtime code and do not run tests.
+
+## Inputs
+
+The yasdef prompt should provide:
+- step id, for example `1.6`
+- feature id
+- branch name
+- step plan path
+- design artifact path
+- runtime implementation plan path
+- worker id
+
+If any input is missing, inconsistent, or points to a missing required file, do not infer it from `.asdlc_worker/feature_meta_sync.yaml` or the runtime environment. Stop and ask the user for explicit instructions.
+
+## Phase Contract
+
+- Analysis-only: do not modify runtime code and do not run tests.
+- Audit question: for this step, are all target bullets proven by the current patch; if not, identify the concrete gaps that remain.
+- Two-phase model: Phase 1 discovery is a single pass; Phase 2 disposition is a mechanical loop over all findings.
+- Terminal states per finding: `follow_up_created`, `raised_to_coordinator`, or `rejected`.
+- Commit boundary: commit worker review-result changes only; leave ASDLC edits uncommitted for `post_review`.
+- Completion protocol: run `check_ai_audit_closure.py` before the completion lines.
+
+## Workflow
+
+1. Run the entry gate as the first action:
+   ```bash
+   uv run python .claude/skills/yasdef-worker-ai-audit/scripts/check_ai_audit_entry.py --step <step> --feature-id <feature-id>
+   ```
+   If it exits non-zero, stop and report the failed preconditions.
+
+2. Build context:
+   ```bash
+   uv run python .claude/skills/yasdef-worker-ai-audit/scripts/build_ai_audit_context.py --step <step> --feature-id <feature-id> --design <design-file> --runtime-plan <runtime-plan> --worker-id <worker-id>
+   ```
+
+3. Read the printed context before reviewing. The step design artifact is the single context source. Use only:
+- `## Target Bullets (excluding planning/review)`
+- `## Selected EARS Requirements (for planning translation)`
+- `## Goal`
+- `## In Scope`
+- `## Out of Scope`
+- `## Linked Artifacts (in scope)`
+
+4. Phase 1 - Discovery (single pass):
+- Review the current patch via `git status` and `git diff`.
+- Write all findings in one pass to `step_review_results/review_result-<step>-<feature>.md`.
+- Each finding must include severity, recommendation (`FollowupStep` or `RiseToCoordinator`), reasoning, references, and a three-state checkbox block:
+  - `follow_up_created`
+  - `raised_to_coordinator`
+  - `rejected`
+- Initialize all three state checkboxes unchecked.
+- Do not start disposition before all findings are written.
+
+5. Phase 2 - Disposition (mechanical loop). For each finding in order:
+
+   5.1. Present the finding (severity, recommendation, reasoning, refs) and end the same message with exactly these three options on their own lines — do **not** print the options anywhere else in the finding presentation:
+
+        ```
+        1. reject
+        2. create follow-up step
+        3. raise to coordinator
+        ```
+
+        Then stop and wait for the user's choice. Do not re-print the options in a follow-up prompt; one listing per finding only.
+
+   5.2. Apply the chosen disposition:
+
+        - reject: mark `[x] rejected` (optional short rationale after `:`).
+        - create follow-up step: do **not** edit `implementation_plan.md` by hand. Run the helper, which writes the canonical block (heading, `#### Assigned:` / `#### Repo:` / `#### Depends on:` headings, `- [ ] Plan and discuss the step.` first bullet, your action bullets, `- [ ] Review step implementation.` last bullet) and prints the new step id on stdout:
+
+          ```bash
+          uv run python .claude/skills/yasdef-worker-ai-audit/scripts/append_follow_up_step.py \
+            --runtime-plan <runtime-plan> \
+            --parent-step <current-step-id> \
+            --worker-id <worker-id> \
+            --title "<follow-up step title>" \
+            --bullet "<first action bullet>" \
+            [--bullet "<additional action bullet>" ...]
+          ```
+
+          The helper auto-picks the next free single-letter suffix (a..z) and copies `#### Repo:` from the parent step. Pass **only the action bullets** as `--bullet` — the helper adds the bookends. Then mark `[x] follow_up_created: <new-step-id>` in the finding's state block using the id printed by the helper.
+
+        - raise to coordinator: create `projects/<project>/<feature>/raised_questions/<step>-<worker-id>-F<NN>.md` and mark `[x] raised_to_coordinator: <relative-path>`.
+
+   5.3. Continue until all findings are dispositioned.
+
+6. Mark all current-step target bullets `[x]` in the ASDLC `implementation_plan.md` in one batch, only after every finding has reached a terminal state. Every target bullet is audit-finalized at this point — directly proven (no finding), proven (finding rejected as false positive), or routed (follow_up_created / raised_to_coordinator). Leave the edit uncommitted; post_review handles the ASDLC repo commit.
+
+7. Run closure gate:
+   ```bash
+   uv run python .claude/skills/yasdef-worker-ai-audit/scripts/check_ai_audit_closure.py --step <step> --feature-id <feature-id> --runtime-plan <runtime-plan> --worker-id <worker-id>
+   ```
+   If it exits non-zero, fix every reported error category (re-run a Phase 2 disposition, create a missing artifact, re-assign a mis-assigned follow-up step, mark a missed target bullet, etc.) and re-run until it exits `0`.
+
+8. Commit boundary:
+- Commit only worker-repo audit artifact changes on `step-<step>-<feature-id>-review`.
+- Do not commit ASDLC repo changes (`implementation_plan.md`, `raised_questions/*`); those are for post_review.
+
+9. Only after the closure gate passes and worker-repo audit changes are committed, end your final response with these exact last two lines:
+`ai_audit phase finished. Nothing else to do now; press Ctrl-C so yasdef can start the next phase.`
+`PHASE_FINISHED_CAN_CLOSE`
+
+## Rules
+
+- Analysis-only: do not touch runtime code and do not run tests.
+- Findings must come from: target-bullet proof gaps, scope drift, `AGENTS.md` invariant violations, and `//TODO` markers in changed files.
+- Every finding must end in exactly one terminal state: `follow_up_created` or `raised_to_coordinator` or `rejected`.
+- Follow-up steps must stay assigned to the current worker.
+- Do not use step plan content, `requirements_ears.md`, `implementation_plan.md`, `.asdlc_worker` ledgers, or design sections outside the required context list as context. `implementation_plan.md` is a write target only (mark current-step target bullets `[x]`, append follow-up step blocks); do not read it for context.

yasdef_worker/_data/skills/yasdef-worker-ai-audit/assets/audit_result_GOLDEN_EXAMPLE.md

@@ -0,0 +1,54 @@
+# AI audit result - golden example
+
+## Summary
+- Step: `1.6`
+- Feature: `trade-concurrency-1777635876`
+- Branch / commit: `step-1.6-trade-concurrency-1777635876-review`, `abc1234`
+- Scope reviewed: market-close/trade concurrency behavior and step target-bullet proof
+
+## Discovery Notes
+- Discovery completed in one pass before disposition.
+- Findings source constraints respected (target bullet proof, scope drift, AGENTS invariant, TODO markers).
+
+## Findings
+
+### F-01
+- Severity: `Critical`
+- Recommendation: `FollowupStep`
+- Category: `TargetBulletNotProven`
+- Target bullet / invariant: `Prevent post-close trade execution under concurrent close.`
+- Reasoning: the close-state check runs before stream lock acquisition, so a concurrent close can interleave between check and append.
+- References:
+  - `src/main/java/com/acme/trade/TradeService.java:71 (executeTrade)`
+  - `src/main/java/com/acme/trade/TradeService.java:93 (appendTradeEvent)`
+  - `src/main/java/com/acme/ledger/LedgerRepository.java:35 (appendEventWithLock)`
+- Disposition state:
+  - [x] follow_up_created: `1.6a`
+  - [ ] raised_to_coordinator:
+  - [ ] rejected:
+
+### F-02
+- Severity: `Medium`
+- Recommendation: `RiseToCoordinator`
+- Category: `ScopeDrift`
+- Target bullet / invariant: `Out-of-scope telemetry aggregation touched in this patch.`
+- Reasoning: patch introduces dashboard materialization logic not listed in Goal/In Scope and contradicts Out of Scope.
+- References:
+  - `src/main/java/com/acme/telemetry/DashboardProjection.java:18 (rebuild)`
+- Disposition state:
+  - [ ] follow_up_created:
+  - [x] raised_to_coordinator: `projects/trading/trade-concurrency-1777635876/raised_questions/1.6-worker-42-F02.md`
+  - [ ] rejected:
+
+### F-03
+- Severity: `Low`
+- Recommendation: `FollowupStep`
+- Category: `TodoMarker`
+- Target bullet / invariant: `//TODO marker remains in changed production path`
+- Reasoning: TODO indicates unresolved behavior in a changed file; must be dispositioned.
+- References:
+  - `src/main/java/com/acme/trade/TradeResource.java:44 (//TODO map domain error code)`
+- Disposition state:
+  - [ ] follow_up_created:
+  - [ ] raised_to_coordinator:
+  - [x] rejected: false positive for this step; marker belongs to unrelated migration tracked separately

yasdef_worker/_data/skills/yasdef-worker-ai-audit/assets/audit_result_TEMPLATE.md

@@ -0,0 +1,43 @@
+# AI audit result template
+
+File: `.asdlc_worker/step_review_results/review_result-<step>-<feature-id>.md`
+
+## Summary
+- Step: `<step>`
+- Feature: `<feature-id>`
+- Branch / commit: `<branch and commit>`
+- Scope reviewed: `<short scope summary>`
+
+## Discovery Notes
+- Findings must be derived only from: target-bullet proof gaps, scope drift, AGENTS.md invariant violations, and `//TODO` markers in changed files.
+- Keep this artifact analysis-only. Do not record runtime code edits here.
+
+## Findings
+
+<!-- Add one `### F-NN` block per finding. The count is variable: zero findings is valid (omit all blocks); otherwise produce as many `### F-01`, `### F-02`, … `### F-NN` blocks as Phase 1 discovery surfaces. Keep IDs zero-padded and sequential. -->
+
+### F-01
+- Severity: `Critical|High|Medium|Low`
+- Recommendation: `FollowupStep|RiseToCoordinator`
+- Category: `TargetBulletNotProven|ScopeDrift|AgentsInvariant|TodoMarker`
+- Target bullet / invariant:
+- Reasoning:
+- References:
+  - `<path>:<line> (<symbol>)`
+- Disposition state:
+  - [ ] follow_up_created: `<step-id, e.g. 1.6a>`
+  - [ ] raised_to_coordinator: `projects/<project>/<feature>/raised_questions/<step>-<worker-id>-F01.md`
+  - [ ] rejected: `<optional rationale>`
+
+### F-02
+- Severity: `Critical|High|Medium|Low`
+- Recommendation: `FollowupStep|RiseToCoordinator`
+- Category: `TargetBulletNotProven|ScopeDrift|AgentsInvariant|TodoMarker`
+- Target bullet / invariant:
+- Reasoning:
+- References:
+  - `<path>:<line> (<symbol>)`
+- Disposition state:
+  - [ ] follow_up_created: `<step-id>`
+  - [ ] raised_to_coordinator: `projects/<project>/<feature>/raised_questions/<step>-<worker-id>-F02.md`
+  - [ ] rejected: `<optional rationale>`

yasdef_worker/_data/skills/yasdef-worker-ai-audit/assets/raised_question_GOLDEN_EXAMPLE.md

@@ -0,0 +1,31 @@
+# Raised Question - Golden Example
+
+## Header
+- Step: `1.6`
+- Feature id: `trade-concurrency-1777635876`
+- Worker id: `worker-42`
+- Finding id: `F-02`
+- Source review artifact: `.asdlc_worker/step_review_results/review_result-1.6-trade-concurrency-1777635876.md`
+- Date: `2026-05-30`
+
+## Why raised to coordinator
+- The finding requires an architectural decision across two services and has more than one viable implementation path.
+
+## Problem statement
+- Current patch introduces telemetry aggregation logic in the trade service boundary, but ownership between trade-service and analytics-service is undefined. Both paths are technically feasible and have different latency/consistency trade-offs.
+
+## Evidence
+- `src/main/java/com/acme/telemetry/DashboardProjection.java:18 (rebuild)`
+- `src/main/java/com/acme/trade/TradeService.java:112 (emitTelemetrySnapshot)`
+
+## Candidate options
+- Option 1: keep aggregation in trade-service and publish normalized snapshots
+  - Trade-offs: fastest delivery; increases coupling and service responsibility.
+- Option 2: move aggregation to analytics-service via event subscription
+  - Trade-offs: cleaner ownership; additional delivery delay and backfill work.
+
+## Requested decision
+- Confirm ownership boundary for telemetry aggregation and approve one option as the standard path for this feature line.
+
+## Impact if delayed
+- Follow-up implementation step cannot be reliably scoped; risk of rework in both services.

yasdef_worker/_data/skills/yasdef-worker-ai-audit/assets/raised_question_TEMPLATE.md

@@ -0,0 +1,33 @@
+# Raised Question Template
+
+File: `<asdlc>/projects/<project>/<feature>/raised_questions/<step>-<worker-id>-F<NN>.md`
+
+## Header
+- Step: `<step>`
+- Feature id: `<feature-id>`
+- Worker id: `<worker-id>`
+- Finding id: `F-<NN>`
+- Source review artifact: `.asdlc_worker/step_review_results/review_result-<step>-<feature-id>.md`
+- Date: `<YYYY-MM-DD>`
+
+## Why raised to coordinator
+- `<broader/deeper concern, multi-solution ambiguity, security implication, or cross-worker prerequisite>`
+
+## Problem statement
+- `<clear problem framing>`
+
+## Evidence
+- `<path>:<line> (<symbol>)`
+- `<test/doc/reference>`
+
+## Candidate options
+- Option 1: `<description>`
+  - Trade-offs:
+- Option 2: `<description>`
+  - Trade-offs:
+
+## Requested decision
+- `<what exact coordinator decision is needed>`
+
+## Impact if delayed
+- `<schedule/risk impact>`