dot-ai

Export `transcript.md` + `brief.md` from the current chat as an evidence package for framework improvement, preserving user-authored request text verbatim and capturing the artifacts, decisions, friction, and execution evidence needed for postmortems.

Pre-flight git hygiene before commits and before reporting completion: resolve untracked task-created files (especially `*/src/**`), stage renames/moves, and verify that the staged set matches the intended commit scope.

Improve an AI agent framework from implementation evidence: analyze the model-produced result commit, human fix-up commits, and optional implementation chat evidence; then patch the correct framework artifacts and/or <project-local>/ so a rerun with the same prompt/model no longer needs the same manual fixes.

Improve the AI framework from design-stage evidence: analyze exported chat artifacts plus design documents such as the formal task statement, HLD, and execution spec; then patch the correct framework artifacts and/or <project-local>/ so similar future design chats require fewer clarifications, less rewriting, and produce more executable specs.

Synthesis of an operational description of a new or modified framework concept based on sources (books/articles/methodologies/industry): extract invariants, variants, and anti-patterns, then produce a Concept spec plus a separate 'Sources and Attributions' section to add or revise materials in `concepts/`.

Refactor Spring/JUnit HTTP tests to typed `*HttpApi` clients (controller-typed signatures, `*ForResponse`, optional `*ForError`/`*ForOutcome`, and JSON schema verification inside the client) when migrating away from direct WebTestClient/RestTestClient usage.

Initialization of an engineering-log task directory based on a template, including file creation, copying 04-execution-spec.md, and writing the original problem statement to 01-problem-statement.md.

Turn an informal development task statement into a formal task statement from the user’s point of view, including goal/outcome, context, assumptions, glossary, scenarios, constraints, in/out scope, and acceptance criteria as black-box test cases. Use when requirements are unclear (notes, chat, ticket text) and need to be made testable before solution design or implementation, and when preparing an artifact to hand off to the designer/developer roles.

Conceptual solution design for a task in engineering-log: read TASK_DIR/01-problem-statement-formal.md when it exists and is non-empty, otherwise fall back to TASK_DIR/01-problem-statement.md, choose a mode (explore solution space or use a single obvious option), run the corresponding guided dialogue, and write results to 02-solution-options.md / 03-solution-hld.md and chats/*.

Fill the Execution-Spec template for a engineering-log task: read TASK_DIR/03-solution-hld.md (must contain === RESULT FOR EXECUTION-SPEC ===) and TASK_DIR/04-execution-spec.md (template), ask only factual clarifying questions if needed, then overwrite 04-execution-spec.md with a complete unambiguous spec and (optionally) save chat transcript to TASK_DIR/chats/03-execution-spec-chat-1.md.

Choose HTTP response status codes for an HTTP/JSON endpoint using Ergonomic Approach conventions and output a contract-ready status-code matrix.

Evidence-based workflow for migrating a codebase from Spring Boot 3.5 to Spring Boot 4 using the inlined knowledge base snapshot under `assets/migration-kb/spring-boot-4/`. Use when upgrading Spring Boot to 4 and fixing resulting dependency, compilation, test, runtime, or tooling failures by mapping symptoms to KB issues and applying the documented fixes.

Building an effects diagram from requirements (user stories, scenarios, list of integrations, external operation contracts): extracts events/operations/resources, records reads/writes as effects, identifies requirement gaps through questions, and saves the diagram in textual format (YAML/JSON). Use when formalizing requirements, estimating scope, planning implementation, and validating target behavior before changes.

Reverse engineering an effects diagram from existing code (when requirements are missing or insufficient): extracts events/operations/resources/effects from entry points and external resource accesses (input/output), records uncertainties, and saves the result in the textual effects diagram format (YAML/JSON). Use when analyzing an unknown system, planning refactoring, assessing regression risk, and reconstructing current (“as-is”) behavior.

Migrate Spring/JUnit HTTP tests to a MockMvc-backed `WebTestClient` (`MockMvcWebTestClient`) without breaking routing, security, serialization, or test-fixture architecture, while keeping the suite green incrementally.

Design and refactor an API to follow Command–Query Separation (CQS): pick a profile, classify operations, split mixed routines, and add enforcement to prevent hidden effects in query paths.

Refactor Kotlin/JUnit scenario tests to use `*Fixture` + `*FixturePresets` + `*TestApi` (and `Mock*Server`) for complex setup, so test cases stay thin and use `*TestApi` only for fixture setup and observation/asserts.