feat(cmd/gf): add gendao fileNameCase and ai coding stuffs (#4764)

This pull request introduces new and updated prompt and instruction
documents for the experimental OPSX workflow system, providing detailed,
step-by-step guidance for proposing, applying, archiving, and exploring
changes using OpenSpec. The changes standardize workflow guardrails,
clarify user interactions, and ensure consistent artifact handling
across all major workflow operations.

**OPSX Workflow Prompt Additions and Enhancements:**

* **Propose Workflow**
- Adds `.agents/prompts/opsx/propose.md` outlining how to propose a new
change, including artifact creation order, dependency handling, and user
input requirements. Emphasizes using schema-defined instructions and
templates, and clarifies that context/rules are for internal guidance
only.

* **Apply Workflow**
- Introduces `.agents/prompts/opsx/apply.md` detailing the process for
implementing tasks from an OpenSpec change. Covers change selection,
context reading, task loop execution, state handling, and output
formatting. Includes guardrails for ambiguity, blockers, and minimal
change scope.

* **Archive Workflow**
- Adds `.agents/prompts/opsx/archive.md` specifying the process for
archiving completed changes, including artifact/task completion checks,
delta spec sync assessment, user prompts for incomplete work, and
summary output. Ensures robust handling of archive naming conflicts and
user confirmations.

* **Explore Mode**
- Adds `.agents/prompts/opsx/explore.md` describing "explore mode" for
non-implementation discovery, problem investigation, and requirements
clarification. Outlines stance, behaviors, and guardrails for thinking
and artifact capture without code changes.

**Documentation Standardization:**

* **Markdown Formatting Standards**
- Adds `.agents/instructions/markdown-format.instructions.md` to
standardize markdown document formatting, including heading levels, code
block usage, list formatting, and language-specific punctuation rules
for improved clarity and consistency.

openspec/changes/archive/2026-04-24-add-unit-test-coverage-requirements/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-24

openspec/changes/archive/2026-04-24-add-unit-test-coverage-requirements/README.md

@@ -0,0 +1,3 @@
+# add-unit-test-coverage-requirements
+
+Require unit tests for submitted code changes and enforce minimum coverage targets for new code.

openspec/changes/archive/2026-04-24-add-unit-test-coverage-requirements/design.md

@@ -0,0 +1,28 @@
+## Context
+
+`CLAUDE.md` and `AGENTS.md` currently act as the canonical project rule documents used during implementation and review. The requested change is documentation-only, but the wording must clearly separate the hard minimum quality bar from the preferred target so contributors and reviewers apply the same standard.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Add an explicit rule that submitted code changes must include unit tests.
+- Add an explicit rule that newly added code must reach at least 80% coverage.
+- Preserve a stronger preferred target of 90% or above when feasible.
+- Keep the change limited to the canonical rule documents and OpenSpec artifacts.
+
+**Non-Goals:**
+- Adding CI automation or coverage tooling in this change.
+- Defining repository-wide historical coverage requirements.
+- Changing unrelated contribution or coding rules.
+
+## Decisions
+
+- Update both `CLAUDE.md` and `AGENTS.md` so the duplicated project rule documents remain aligned.
+- Place the new requirement under `Code Development Rules`, where existing mandatory engineering requirements already live.
+- Use 80% as the hard minimum for newly added code and describe 90% or above as the preferred target when feasible.
+- Keep the wording focused on unit tests and coverage expectations rather than implementation details about how coverage is measured.
+
+## Risks / Trade-offs
+
+- [Documentation-only enforcement] -> The rule depends on reviewer and contributor discipline until tooling is added; placing it in the canonical rule documents keeps the expectation visible during development and review.
+- [Coverage interpretation] -> Different packages may measure coverage differently; using a clear minimum plus a preferred target reduces ambiguity without over-specifying tooling.

openspec/changes/archive/2026-04-24-add-unit-test-coverage-requirements/proposal.md

@@ -0,0 +1,23 @@
+## Why
+
+The project rules currently encourage tests, but they do not define a clear mandatory standard for submitted code changes or a minimum coverage threshold for newly added code. Adding an explicit rule makes review expectations consistent and gives contributors a concrete quality bar.
+
+## What Changes
+
+- Add a project rule requiring submitted code changes to include focused unit tests for the introduced or modified behavior.
+- Add a project rule requiring newly added code to maintain at least 80% test coverage, with 90% or above treated as the preferred target when feasible.
+- Record the requirement in the active OpenSpec change so the new quality gate is traceable.
+
+## Capabilities
+
+### New Capabilities
+- `code-quality-gates`: Defines mandatory unit-test and coverage expectations for submitted code changes.
+
+### Modified Capabilities
+- None.
+
+## Impact
+
+- `CLAUDE.md`
+- `AGENTS.md`
+- Review expectations for future code submissions

openspec/changes/archive/2026-04-24-add-unit-test-coverage-requirements/specs/code-quality-gates/spec.md

@@ -0,0 +1,23 @@
+## ADDED Requirements
+
+### Requirement: Submitted code changes include unit tests
+The project SHALL require every submitted code change to include unit tests that directly cover the affected logic and expected behavior of the changed code path in the affected package.
+
+#### Scenario: Behavior-changing code is submitted
+- **WHEN** a contribution adds or changes code in the repository
+- **THEN** the submission SHALL include unit tests that exercise the affected logic or preserve the expected behavior of the changed code path before the change is considered complete
+
+### Requirement: Newly added code meets the coverage baseline
+The project SHALL require the newly added code in a submission to maintain unit-test coverage of at least 80%, and reviews SHALL treat 90% or above as the preferred target when that level is feasible without artificial or low-value tests.
+
+#### Scenario: Coverage falls below the minimum
+- **WHEN** the newly added code in a submission is covered below 80%
+- **THEN** the change SHALL not satisfy the project quality requirement
+
+#### Scenario: Coverage meets the minimum baseline
+- **WHEN** the newly added code in a submission reaches 80% or higher coverage
+- **THEN** the change SHALL satisfy the minimum coverage requirement
+
+#### Scenario: Coverage reaches the preferred target
+- **WHEN** the newly added code in a submission reaches 90% or higher coverage
+- **THEN** the change SHALL satisfy the preferred coverage target for the project

openspec/changes/archive/2026-04-24-add-unit-test-coverage-requirements/tasks.md

@@ -0,0 +1,8 @@
+## 1. Document the quality gate
+
+- [x] 1.1 Create the OpenSpec proposal, design, and spec artifacts for the unit-test and coverage requirement
+- [x] 1.2 Update the canonical project rule documents with the new unit-test and coverage requirement
+
+## 2. Verify the documentation change
+
+- [x] 2.1 Verify the updated rule documents mention mandatory unit tests and the 80% minimum / 90% preferred coverage targets

openspec/config.yaml

@@ -0,0 +1,8 @@
+schema: spec-driven
+
+# Project context (optional)
+# This is shown to AI when creating artifacts.
+# Add your tech stack, conventions, style guides, domain knowledge, etc.
+# Example:
+context: |
+  Generate all OpenSpec artifacts in English.

openspec/specs/code-quality-gates/spec.md

@@ -0,0 +1,27 @@
+# code-quality-gates Specification
+
+## Purpose
+TBD - created by archiving change add-unit-test-coverage-requirements. Update Purpose after archive.
+## Requirements
+### Requirement: Submitted code changes include unit tests
+The project SHALL require every submitted code change to include unit tests that directly cover the affected logic and expected behavior of the changed code path in the affected package.
+
+#### Scenario: Behavior-changing code is submitted
+- **WHEN** a contribution adds or changes code in the repository
+- **THEN** the submission SHALL include unit tests that exercise the affected logic or preserve the expected behavior of the changed code path before the change is considered complete
+
+### Requirement: Newly added code meets the coverage baseline
+The project SHALL require the newly added code in a submission to maintain unit-test coverage of at least 80%, and reviews SHALL treat 90% or above as the preferred target when that level is feasible without artificial or low-value tests.
+
+#### Scenario: Coverage falls below the minimum
+- **WHEN** the newly added code in a submission is covered below 80%
+- **THEN** the change SHALL not satisfy the project quality requirement
+
+#### Scenario: Coverage meets the minimum baseline
+- **WHEN** the newly added code in a submission reaches 80% or higher coverage
+- **THEN** the change SHALL satisfy the minimum coverage requirement
+
+#### Scenario: Coverage reaches the preferred target
+- **WHEN** the newly added code in a submission reaches 90% or higher coverage
+- **THEN** the change SHALL satisfy the preferred coverage target for the project
+