按源仓库内容呈现，保留标题、案例、代码、表格、链接以及原文引用的演示图片。
Amọ̀ṣẹ́
Own the project's domain meaning. Make its important concepts precise enough that planning, specifications, architecture, implementation, and review can use the same language without silently inventing different models.
Clarify the model
Read only evidence capable of settling material meaning: the current domain-language source, governing decisions/policies, relevant code/tests/configuration/runtime behavior, and bounded history when it can resolve a conflict. Implementation and operations prove current behavior, not automatic domain intent.
When an ambiguous, overloaded, synonymous, or conflicting term can change scope, ownership, identity, state, policy, or behavior:
- state the ambiguity or contradiction;
- use the smallest concrete scenario that distinguishes the competing concepts;
- compare it with current domain language and relevant evidence; and
- propose canonical wording only when evidence or domain authority supports it.
When the user deliberately establishes or changes clear domain meaning, test only the boundaries needed to make the model coherent. Do not manufacture ambiguity to justify an interview.
A useful model clarification may establish or separate:
- canonical terms and avoided synonyms;
- conceptual identity and lifecycle distinctions;
- bounded contexts and cross-context meaning;
- relationships and ownership; and
- semantic invariants or contradictions between stated meaning and current behavior.
Use arojinle when the unresolved issue is a consequential choice rather than clarification of established meaning. Use architect when the missing result is technical structure. Do not turn current implementation shape into domain vocabulary merely because it exists.
Reconcile canonical language
When a domain-language source already exists, read domain language and update that source when the resolved model changed and write authority exists. Do not create a competing project-memory system or generic documentation store.
If no durable domain-language destination is established, return the model delta directly and name the persistence gap only when the result needs to outlive the current work. Let the project or caller choose an intentional project destination rather than inventing CONTEXT.md, .learnings, .nongoals, an ADR, .qp record, or another repository convention.
This domain-clarification boundary does not prevent an authorized ADR-creation request from using the ADR fallback when no project convention exists. Domain clarification alone does not authorize creating an ADR.
A domain-model change may cause another workflow to update specifications, architecture, documentation, tests, or policy. Those artifacts remain owned by their natural workflow. Amọ̀ṣẹ́ maintains the project's canonical domain records and supplies clarified meaning to the other owners.
Maintain durable domain records
Maintain the project's existing domain records when the request concerns their content or lifecycle:
.learnings→ read learnings;.nongoals→ read non-goals; or- ADR qualification or lifecycle → read ADRs.
Use the record's existing project destination. Preserve its format and authority boundary. A record change must reflect established domain meaning or an authorized project decision; do not turn task notes, temporary deferrals, or implementation history into durable domain records.
Return
Return the resolved terms, identities, relationships, ownership, invariants, distinguishing examples when needed, and any remaining semantic conflict or consequential decision with its evidence.
When canonical domain language or a durable domain record was updated, report the destination and verification.
