Add simple menu item to derive DDD context for an existing repo

[tninja]

Motivation

For an existing codebase that was not originally designed with Domain-Driven Design, it would still be useful to derive a lightweight DDD-style domain context document from the current repository.

The immediate goal is not to introduce a full DDD workflow or refactor code into DDD patterns. The goal is simpler: provide one easy entry point that asks the configured AI coding backend to inspect the current repo and generate a useful domain/context document that can later be used as project context for AI-assisted development.

This fits the existing direction of ai-code-interface.el as an Emacs-based AI coding interface focused on context engineering, task files, and harness-style workflows.

MVP scope

Add a single menu item / command, for example:

• ai-code-derive-ddd-context
• menu label: Derive DDD Context for Repo

The command should:

1. Work on the current project/repo.
2. Ask the configured AI backend to analyze the repository at a high level.
3. Generate a lightweight DDD/context document under .ai.code.files/.
4. Keep the output simple and useful for future AI coding tasks.

Suggested output location:

.ai.code.files/domain-context.md

or, if we want some room for future expansion:

.ai.code.files/domain/domain-context.md

Suggested generated document structure

The generated document can be a single Markdown file for now:

# Domain Context

## Purpose
What this repository appears to do.

## Ubiquitous Language
Important domain terms and what they mean in this codebase.

## Main Domain Concepts
Key entities, value-like objects, services, jobs, workflows, or concepts inferred from the repo.

## Bounded Context Candidates
Possible logical boundaries. These are candidates, not final design decisions.

## Core Flows
Important business/application flows inferred from code, tests, docs, and filenames.

## Domain Invariants / Business Rules
Rules that appear important to preserve when making future changes.

## Testing Ideas
Characterization tests, unit tests, golden tests, or integration tests that could protect important behavior.

## Notes and Uncertainties
Places where the AI is uncertain and human review is needed.

Prompt behavior

The prompt should explicitly tell the AI:

• This is an existing repo, not necessarily a DDD-designed repo.
• Do not invent an ideal architecture.
• Derive concepts from actual code, tests, docs, filenames, and existing behavior.
• Mark uncertain conclusions clearly.
• Prefer practical context useful for future AI coding tasks.
• Do not suggest large refactors unless listed separately as optional future ideas.

Example instruction:

Derive a lightweight Domain-Driven Design style context document for this existing repository.
Do not assume the repo follows DDD today. Infer domain terms, core flows, invariants, and bounded context candidates from the existing code, tests, docs, and filenames.
The output is intended to help future AI coding sessions understand the domain and avoid semantic mistakes.
Keep it practical, concise, and mark uncertainty explicitly.
Write the result to .ai.code.files/domain-context.md.

Non-goals for the first version

• No full DDD implementation.
• No automatic refactoring.
• No multi-file domain model required.
• No mandatory integration with the TDD harness loop yet.
• No automatic enforcement of domain invariants yet.

Future expansion ideas

This issue should keep room for future growth without requiring it now:

1. Inject .ai.code.files/domain-context.md automatically into future AI coding prompts.
2. Add a command to update the domain context from the current diff or current org task.
3. Connect domain invariants to the TDD harness loop.
4. Generate test ideas from the domain invariants.
5. Add a diff review command that checks whether a code change violates documented domain rules.
6. Support a richer directory structure later, such as:

.ai.code.files/domain/
  glossary.md
  bounded-contexts.md
  flows.md
  invariants.md
  test-ideas.md

Acceptance criteria

• A user can trigger one command/menu item from Emacs.
• The command creates or updates a Markdown domain context document under .ai.code.files/.
• The generated prompt is oriented toward deriving context from an existing repo, not forcing idealized DDD.
• The feature remains simple enough to be useful immediately, while leaving room for later integration with prompt context injection and the TDD harness loop.