@zeyue0329/xiaoma-cli 1.6.4 → 1.7.0

package/src/xmc/workflows/xiaoma-quick-flow/quick-spec/steps/step-03-generate.md

@@ -1,126 +0,0 @@
----
-name: 'step-03-generate'
-description: 'Build the implementation plan based on the technical mapping of constraints'
-
-wipFile: '{implementation_artifacts}/tech-spec-wip.md'
----
-
-# Step 3: Generate Implementation Plan
-
-**Progress: Step 3 of 4** - Next: Review & Finalize
-
-## RULES:
-
-- MUST NOT skip steps.
-- MUST NOT optimize sequence.
-- MUST follow exact instructions.
-- MUST NOT implement anything - just document.
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## CONTEXT:
-
-- Requires `{wipFile}` with defined "Overview" and "Context for Development" sections.
-- Focus: Create the implementation sequence that addresses the requirement delta using the captured technical context.
-- Output: Implementation-ready tasks with specific files and instructions.
-- Target: Meet the **READY FOR DEVELOPMENT** standard defined in `workflow.md`.
-
-## SEQUENCE OF INSTRUCTIONS
-
-### 1. Load Current State
-
-**Read `{wipFile}` completely and extract:**
-
-- All frontmatter values
-- Overview section (Problem, Solution, Scope)
-- Context for Development section (Patterns, Files, Decisions)
-
-### 2. Generate Implementation Plan
-
-Generate specific implementation tasks:
-
-a) **Task Breakdown**
-
-- Each task should be a discrete, completable unit of work
-- Tasks should be ordered logically (dependencies first)
-- Include the specific files to modify in each task
-- Be explicit about what changes to make
-
-b) **Task Format**
-
-```markdown
-- [ ] Task N: Clear action description
-  - File: `path/to/file.ext`
-  - Action: Specific change to make
-  - Notes: Any implementation details
-```
-
-### 3. Generate Acceptance Criteria
-
-**Create testable acceptance criteria:**
-
-Each AC should follow Given/When/Then format:
-
-```markdown
-- [ ] AC N: Given [precondition], when [action], then [expected result]
-```
-
-**Ensure ACs cover:**
-
-- Happy path functionality
-- Error handling
-- Edge cases (if relevant)
-- Integration points (if relevant)
-
-### 4. Complete Additional Context
-
-**Fill in remaining sections:**
-
-a) **Dependencies**
-
-- External libraries or services needed
-- Other tasks or features this depends on
-- API or data dependencies
-
-b) **Testing Strategy**
-
-- Unit tests needed
-- Integration tests needed
-- Manual testing steps
-
-c) **Notes**
-
-- High-risk items from pre-mortem analysis
-- Known limitations
-- Future considerations (out of scope but worth noting)
-
-### 5. Write Complete Spec
-
-a) **Update `{wipFile}` with all generated content:**
-
-- Ensure all template sections are filled in
-- No placeholder text remaining
-- All frontmatter values current
-- Update status to 'review' (NOT 'ready-for-dev' - that happens after user review in Step 4)
-
-b) **Update frontmatter:**
-
-```yaml
----
-# ... existing values ...
-status: 'review'
-stepsCompleted: [1, 2, 3]
----
-```
-
-c) **Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/xiaoma-quick-flow/quick-spec/steps/step-04-review.md` (Step 4)**
-
-## REQUIRED OUTPUTS:
-
-- Tasks MUST be specific, actionable, ordered logically, with files to modify.
-- ACs MUST be testable, using Given/When/Then format.
-- Status MUST be updated to 'review'.
-
-## VERIFICATION CHECKLIST:
-
-- [ ] `stepsCompleted: [1, 2, 3]` set in frontmatter.
-- [ ] Spec meets the **READY FOR DEVELOPMENT** standard.

package/src/xmc/workflows/xiaoma-quick-flow/quick-spec/steps/step-04-review.md

@@ -1,198 +0,0 @@
----
-name: 'step-04-review'
-description: 'Review and finalize the tech-spec'
-
-wipFile: '{implementation_artifacts}/tech-spec-wip.md'
----
-
-# Step 4: Review & Finalize
-
-**Progress: Step 4 of 4** - Final Step
-
-## RULES:
-
-- MUST NOT skip steps.
-- MUST NOT optimize sequence.
-- MUST follow exact instructions.
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## CONTEXT:
-
-- Requires `{wipFile}` from Step 3. 
-- MUST present COMPLETE spec content. Iterate until user is satisfied.
-- **Criteria**: The spec MUST meet the **READY FOR DEVELOPMENT** standard defined in `workflow.md`.
-
-## SEQUENCE OF INSTRUCTIONS
-
-### 1. Load and Present Complete Spec
-
-**Read `{wipFile}` completely and extract `slug` from frontmatter for later use.**
-
-**Present to user:**
-
-"Here's your complete tech-spec. Please review:"
-
-[Display the complete spec content - all sections]
-
-"**Quick Summary:**
-
-- {task_count} tasks to implement
-- {ac_count} acceptance criteria to verify
-- {files_count} files to modify"
-
-**Present review menu:**
-
-Display: "**Select:** [C] Continue [E] Edit [Q] Questions [A] Advanced Elicitation [P] Party Mode"
-
-**HALT and wait for user selection.**
-
-#### Menu Handling Logic:
-
-- IF C: Proceed to Section 3 (Finalize the Spec)
-- IF E: Proceed to Section 2 (Handle Review Feedback), then return here and redisplay menu
-- IF Q: Answer questions, then redisplay this menu
-- IF A: Read fully and follow: `{advanced_elicitation}` with current spec content, process enhanced insights, ask user "Accept improvements? (y/n)", if yes update spec then redisplay menu, if no keep original then redisplay menu
-- IF P: Read fully and follow: `{party_mode_exec}` with current spec content, process collaborative insights, ask user "Accept changes? (y/n)", if yes update spec then redisplay menu, if no keep original then redisplay menu
-- IF Any other comments or queries: respond helpfully then redisplay menu
-
-#### EXECUTION RULES:
-
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to finalize when user selects 'C'
-- After other menu items execution, return to this menu
-
-### 2. Handle Review Feedback
-
-a) **If user requests changes:**
-
-- Make the requested edits to `{wipFile}`
-- Re-present the affected sections
-- Ask if there are more changes
-- Loop until user is satisfied
-
-b) **If the spec does NOT meet the "Ready for Development" standard:**
-
-- Point out the missing/weak sections (e.g., non-actionable tasks, missing ACs).
-- Propose specific improvements to reach the standard.
-- Make the edits once the user agrees.
-
-c) **If user has questions:**
-
-- Answer questions about the spec
-- Clarify any confusing sections
-- Make clarifying edits if needed
-
-### 3. Finalize the Spec
-
-**When user confirms the spec is good AND it meets the "Ready for Development" standard:**
-
-a) Update `{wipFile}` frontmatter:
-
-   ```yaml
-   ---
-   # ... existing values ...
-   status: 'ready-for-dev'
-   stepsCompleted: [1, 2, 3, 4]
-   ---
-   ```
-
-b) **Rename WIP file to final filename:**
-   - Using the `slug` extracted in Section 1
-   - Rename `{wipFile}` → `{implementation_artifacts}/tech-spec-{slug}.md`
-   - Store this as `finalFile` for use in menus below
-
-### 4. Present Final Menu
-
-a) **Display completion message and menu:**
-
-```
-**Tech-Spec Complete!**
-
-Saved to: {finalFile}
-
----
-
-**Next Steps:**
-
-[A] Advanced Elicitation - refine further
-[R] Adversarial Review - critique of the spec (highly recommended)
-[B] Begin Development - start implementing now (not recommended)
-[D] Done - exit workflow
-[P] Party Mode - get expert feedback before dev
-
----
-
-Once you are fully satisfied with the spec (ideally after **Adversarial Review** and maybe a few rounds of **Advanced Elicitation**), it is recommended to run implementation in a FRESH CONTEXT for best results.
-
-Copy this prompt to start dev:
-
-\`\`\`
-quick-dev {finalFile}
-\`\`\`
-
-This ensures the dev agent has clean context focused solely on implementation.
-```
-
-b) **HALT and wait for user selection.**
-
-#### Menu Handling Logic:
-
-- IF A: Read fully and follow: `{advanced_elicitation}` with current spec content, process enhanced insights, ask user "Accept improvements? (y/n)", if yes update spec then redisplay menu, if no keep original then redisplay menu
-- IF B: Read the entire workflow file at `{quick_dev_workflow}` and follow the instructions with the final spec file (warn: fresh context is better)
-- IF D: Exit workflow - display final confirmation and path to spec
-- IF P: Read fully and follow: `{party_mode_exec}` with current spec content, process collaborative insights, ask user "Accept changes? (y/n)", if yes update spec then redisplay menu, if no keep original then redisplay menu
-- IF R: Execute Adversarial Review (see below)
-- IF Any other comments or queries: respond helpfully then redisplay menu
-
-#### EXECUTION RULES:
-
-- ALWAYS halt and wait for user input after presenting menu
-- After A, P, or R execution, return to this menu
-
-#### Adversarial Review [R] Process:
-
-1. **Invoke Adversarial Review Skill**:
-       > With `{finalFile}` constructed, invoke the `xiaoma-review-adversarial-general` skill. If possible, use information asymmetry: invoke the skill in a separate subagent or process with read access to the project, but no context except the `{finalFile}`.
-       > Pass `{finalFile}` as the content to review. The skill should return a list of findings.
-
-    2. **Process Findings**:
-       > Capture the findings from the skill output.
-       > **If zero findings:** HALT - this is suspicious. Re-analyze or request user guidance.
-       > Evaluate severity (Critical, High, Medium, Low) and validity (real, noise, undecided).
-       > DO NOT exclude findings based on severity or validity unless explicitly asked to do so.
-       > Order findings by severity.
-       > Number the ordered findings (F1, F2, F3, etc.).
-       > If TodoWrite or similar tool is available, turn each finding into a TODO, include ID, severity, validity, and description in the TODO; otherwise present findings as a table with columns: ID, Severity, Validity, Description
-
-    3. Return here and redisplay menu.
-
-### 5. Exit Workflow
-
-**When user selects [D]:**
-
-"**All done!** Your tech-spec is ready at:
-
-`{finalFile}`
-
-When you're ready to implement, run:
-
-```
-quick-dev {finalFile}
-```
-
-Ship it!"
-
----
-
-## REQUIRED OUTPUTS:
-
-- MUST update status to 'ready-for-dev'.
-- MUST rename file to `tech-spec-{slug}.md`.
-- MUST provide clear next-step guidance and recommend fresh context for dev.
-
-## VERIFICATION CHECKLIST:
-
-- [ ] Complete spec presented for review.
-- [ ] Requested changes implemented.
-- [ ] Spec verified against **READY FOR DEVELOPMENT** standard.
-- [ ] `stepsCompleted: [1, 2, 3, 4]` set and file renamed.

package/src/xmc/workflows/xiaoma-quick-flow/quick-spec/workflow.md

@@ -1,79 +0,0 @@
----
-name: quick-spec
-description: 'Very quick process to create implementation-ready quick specs for small changes or features. Use when the user says "create a quick spec" or "generate a quick tech spec"'
-main_config: '{project-root}/_xiaoma/xmc/config.yaml'
-
-# Checkpoint handler paths
-advanced_elicitation: '{project-root}/_xiaoma/core/workflows/advanced-elicitation/workflow.md'
-party_mode_exec: '{project-root}/_xiaoma/core/workflows/party-mode/workflow.md'
-quick_dev_workflow: '{project-root}/_xiaoma/xmc/workflows/xiaoma-quick-flow/quick-dev/workflow.md'
----
-
-# Quick-Spec Workflow
-
-**Goal:** Create implementation-ready technical specifications through conversational discovery, code investigation, and structured documentation.
-
-**READY FOR DEVELOPMENT STANDARD:**
-
-A specification is considered "Ready for Development" ONLY if it meets the following:
-
-- **Actionable**: Every task has a clear file path and specific action.
-- **Logical**: Tasks are ordered by dependency (lowest level first).
-- **Testable**: All ACs follow Given/When/Then and cover happy path and edge cases.
-- **Complete**: All investigation results from Step 2 are inlined; no placeholders or "TBD".
-- **Self-Contained**: A fresh agent can implement the feature without reading the workflow history.
-
----
-
-**Your Role:** You are an elite developer and spec engineer. You ask sharp questions, investigate existing code thoroughly, and produce specs that contain ALL context a fresh dev agent needs to implement the feature. No handoffs, no missing context - just complete, actionable specs.
-
----
-
-## WORKFLOW ARCHITECTURE
-
-This uses **step-file architecture** for disciplined execution:
-
-### Core Principles
-
-- **Micro-file Design**: Each step is a self-contained instruction file that must be followed exactly
-- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until directed
-- **Sequential Enforcement**: Sequence within step files must be completed in order, no skipping or optimization
-- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array
-- **Append-Only Building**: Build the tech-spec by updating content as directed
-
-### Step Processing Rules
-
-1. **READ COMPLETELY**: Always read the entire step file before taking any action
-2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
-3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
-4. **CHECK CONTINUATION**: Only proceed to next step when user selects [C] (Continue)
-5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
-6. **LOAD NEXT**: When directed, read fully and follow the next step file
-
-### Critical Rules (NO EXCEPTIONS)
-
-- **NEVER** load multiple step files simultaneously
-- **ALWAYS** read entire step file before execution
-- **NEVER** skip steps or optimize the sequence
-- **ALWAYS** update frontmatter of output file when completing a step
-- **ALWAYS** follow the exact instructions in the step file
-- **ALWAYS** halt at menus and wait for user input
-- **NEVER** create mental todo lists from future steps
-
----
-
-## INITIALIZATION SEQUENCE
-
-### 1. Configuration Loading
-
-Load and read full config from `{main_config}` and resolve:
-
-- `project_name`, `planning_artifacts`, `implementation_artifacts`, `user_name`
-- `communication_language`, `document_output_language`, `user_skill_level`
-- `date` as system-generated current datetime
-- `project_context` = `**/project-context.md` (load if exists)
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-### 2. First Step Execution
-
-Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/xiaoma-quick-flow/quick-spec/steps/step-01-understand.md` to begin the workflow.

package/src/xmc/workflows/xiaoma-quick-flow/quick-spec/xiaoma-skill-manifest.yaml

@@ -1,3 +0,0 @@
-canonicalId: xiaoma-quick-spec
-type: workflow
-description: "Very quick process to create implementation-ready quick specs for small changes or features"

package/test/README.md

@@ -1,295 +0,0 @@
-# Agent Schema Validation Test Suite
-
-Comprehensive test coverage for the XiaoMa agent schema validation system.
-
-## Overview
-
-This test suite validates the Zod-based schema validator (`tools/schema/agent.js`) that ensures all `*.agent.yaml` files conform to the XiaoMa agent specification.
-
-## Test Statistics
-
-- **Total Test Fixtures**: 50
-- **Valid Test Cases**: 18
-- **Invalid Test Cases**: 32
-- **Code Coverage**: 100% all metrics (statements, branches, functions, lines)
-- **Exit Code Tests**: 4 CLI integration tests
-
-## Quick Start
-
-```bash
-# Run all tests
-npm test
-
-# Run with coverage report
-npm run test:coverage
-
-# Run CLI integration tests
-./test/test-cli-integration.sh
-
-# Validate actual agent files
-npm run validate:schemas
-```
-
-## Test Organization
-
-### Test Fixtures
-
-Located in `test/fixtures/agent-schema/`, organized by category:
-
-```
-test/fixtures/agent-schema/
-├── valid/                    # 15 fixtures that should pass
-│   ├── top-level/           # Basic structure tests
-│   ├── metadata/            # Metadata field tests
-│   ├── persona/             # Persona field tests
-│   ├── critical-actions/    # Critical actions tests
-│   ├── menu/                # Menu structure tests
-│   ├── menu-commands/       # Command target tests
-│   ├── menu-triggers/       # Trigger format tests
-│   └── prompts/             # Prompts field tests
-└── invalid/                  # 32 fixtures that should fail
-    ├── top-level/           # Structure errors
-    ├── metadata/            # Metadata validation errors
-    ├── persona/             # Persona validation errors
-    ├── critical-actions/    # Critical actions errors
-    ├── menu/                # Menu errors
-    ├── menu-commands/       # Command target errors
-    ├── menu-triggers/       # Trigger format errors
-    ├── prompts/             # Prompts errors
-    └── yaml-errors/         # YAML parsing errors
-```
-
-## Test Categories
-
-### 1. Top-Level Structure Tests (4 fixtures)
-
-Tests the root-level agent structure:
-
-- ✅ Valid: Minimal core agent with required fields
-- ❌ Invalid: Empty YAML file
-- ❌ Invalid: Missing `agent` key
-- ❌ Invalid: Extra top-level keys (strict mode)
-
-### 2. Metadata Field Tests (7 fixtures)
-
-Tests agent metadata validation:
-
-- ✅ Valid: Module agent with correct `module` field
-- ❌ Invalid: Missing required fields (`id`, `name`, `title`, `icon`)
-- ❌ Invalid: Empty strings in metadata
-- ❌ Invalid: Module agent missing `module` field
-- ❌ Invalid: Core agent with unexpected `module` field
-- ❌ Invalid: Wrong `module` value (doesn't match path)
-- ❌ Invalid: Extra unknown metadata fields
-
-### 3. Persona Field Tests (6 fixtures)
-
-Tests persona structure and validation:
-
-- ✅ Valid: Complete persona with all fields
-- ❌ Invalid: Missing required fields (`role`, `identity`, etc.)
-- ❌ Invalid: `principles` as string instead of array
-- ❌ Invalid: Empty `principles` array
-- ❌ Invalid: Empty strings in `principles` array
-- ❌ Invalid: Extra unknown persona fields
-
-### 4. Critical Actions Tests (5 fixtures)
-
-Tests optional `critical_actions` field:
-
-- ✅ Valid: No `critical_actions` field (optional)
-- ✅ Valid: Empty `critical_actions` array
-- ✅ Valid: Valid action strings
-- ❌ Invalid: Empty strings in actions
-- ❌ Invalid: Actions as non-array type
-
-### 5. Menu Field Tests (4 fixtures)
-
-Tests required menu structure:
-
-- ✅ Valid: Single menu item
-- ✅ Valid: Multiple menu items with different commands
-- ❌ Invalid: Missing `menu` field
-- ❌ Invalid: Empty `menu` array
-
-### 6. Menu Command Target Tests (4 fixtures)
-
-Tests menu item command targets:
-
-- ✅ Valid: All 6 command types (`workflow`, `validate-workflow`, `exec`, `action`, `tmpl`, `data`)
-- ✅ Valid: Multiple command targets in one menu item
-- ❌ Invalid: No command target fields
-- ❌ Invalid: Empty string command targets
-
-### 7. Menu Trigger Validation Tests (7 fixtures)
-
-Tests trigger format enforcement:
-
-- ✅ Valid: Kebab-case triggers (`help`, `list-tasks`, `multi-word-trigger`)
-- ❌ Invalid: Leading asterisk (`*help`)
-- ❌ Invalid: CamelCase (`listTasks`)
-- ❌ Invalid: Snake_case (`list_tasks`)
-- ❌ Invalid: Spaces (`list tasks`)
-- ❌ Invalid: Duplicate triggers within agent
-- ❌ Invalid: Empty trigger string
-
-### 8. Prompts Field Tests (8 fixtures)
-
-Tests optional `prompts` field:
-
-- ✅ Valid: No `prompts` field (optional)
-- ✅ Valid: Empty `prompts` array
-- ✅ Valid: Prompts with required `id` and `content`
-- ✅ Valid: Prompts with optional `description`
-- ❌ Invalid: Missing `id`
-- ❌ Invalid: Missing `content`
-- ❌ Invalid: Empty `content` string
-- ❌ Invalid: Extra unknown prompt fields
-
-### 9. YAML Parsing Tests (2 fixtures)
-
-Tests YAML parsing error handling:
-
-- ❌ Invalid: Malformed YAML syntax
-- ❌ Invalid: Invalid indentation
-
-## Test Scripts
-
-### Main Test Runner
-
-**File**: `test/test-agent-schema.js`
-
-Automated test runner that:
-
-- Loads all fixtures from `test/fixtures/agent-schema/`
-- Validates each against the schema
-- Compares results with expected outcomes (parsed from YAML comments)
-- Reports detailed results by category
-- Exits with code 0 (pass) or 1 (fail)
-
-**Usage**:
-
-```bash
-npm test
-# or
-node test/test-agent-schema.js
-```
-
-### Coverage Report
-
-**Command**: `npm run test:coverage`
-
-Generates code coverage report using c8:
-
-- Text output to console
-- HTML report in `coverage/` directory
-- Tracks statement, branch, function, and line coverage
-
-**Current Coverage**:
-
-- Statements: 100%
-- Branches: 100%
-- Functions: 100%
-- Lines: 100%
-
-### CLI Integration Tests
-
-**File**: `test/test-cli-integration.sh`
-
-Bash script that tests CLI behavior:
-
-1. Validates existing agent files
-2. Verifies test fixture validation
-3. Checks exit code 0 for valid files
-4. Verifies test runner output format
-
-**Usage**:
-
-```bash
-./test/test-cli-integration.sh
-```
-
-## Manual Testing
-
-See **[MANUAL-TESTING.md](./MANUAL-TESTING.md)** for detailed manual testing procedures, including:
-
-- Testing with invalid files
-- GitHub Actions workflow verification
-- Troubleshooting guide
-- PR merge blocking tests
-
-## Coverage Achievement
-
-**100% code coverage achieved!** All branches, statements, functions, and lines in the validation logic are tested.
-
-Edge cases covered include:
-
-- Malformed module paths (e.g., `src/bmm` without `/agents/`)
-- Empty module names in paths (e.g., `src/modules//agents/`)
-- Whitespace-only module field values
-- All validation error paths
-- All success paths for valid configurations
-
-## Adding New Tests
-
-To add new test cases:
-
-1. Create a new `.agent.yaml` file in the appropriate `valid/` or `invalid/` subdirectory
-2. Add comment metadata at the top:
-
-   ```yaml
-   # Test: Description of what this tests
-   # Expected: PASS (or FAIL - error description)
-   # Path context: src/xmc/agents/test.agent.yaml (if needed)
-   ```
-
-3. Run the test suite to verify: `npm test`
-
-## Integration with CI/CD
-
-The validation is integrated into the GitHub Actions workflow:
-
-**File**: `.github/workflows/lint.yaml`
-
-**Job**: `agent-schema`
-
-**Runs on**: All pull requests
-
-**Blocks merge if**: Validation fails
-
-## Files
-
-- `test/test-agent-schema.js` - Main test runner
-- `test/test-cli-integration.sh` - CLI integration tests
-- `test/MANUAL-TESTING.md` - Manual testing guide
-- `test/fixtures/agent-schema/` - Test fixtures (47 files)
-- `tools/schema/agent.js` - Validation logic (under test)
-- `tools/validate-agent-schema.js` - CLI wrapper
-
-## Dependencies
-
-- **zod**: Schema validation library
-- **yaml**: YAML parsing
-- **glob**: File pattern matching
-- **c8**: Code coverage reporting
-
-## Success Criteria
-
-All success criteria from the original task have been exceeded:
-
-- ✅ 50 test fixtures covering all validation rules (target: 47+)
-- ✅ Automated test runner with detailed reporting
-- ✅ CLI integration tests verifying exit codes and output
-- ✅ Manual testing documentation
-- ✅ **100% code coverage achieved** (target: 99%+)
-- ✅ Both positive and negative test cases
-- ✅ Clear and actionable error messages
-- ✅ GitHub Actions integration verified
-- ✅ Aggressive defensive assertions implemented
-
-## Resources
-
-- **Schema Documentation**: `schema-classification.md`
-- **Validator Implementation**: `tools/schema/agent.js`
-- **CLI Tool**: `tools/validate-agent-schema.js`
-- **Project Guidelines**: `CLAUDE.md`