---
name: aoa-core-logic-boundary
description: Separate reusable core logic from glue, orchestration, and infrastructure detail. Use when stable rules are mixed with wiring, the same logic repeats in several places, or reviews are muddy because the responsibility center is unclear. Do not use for tiny isolated fixes or when the real task is introducing a port or adapter around a concrete dependency.
license: Apache-2.0
compatibility: Designed for Codex or similar coding agents with repository file access and an interactive shell. Network access is optional and only needed when repository validation or referenced workflows require it.
metadata:
  aoa_scope: core
  aoa_status: evaluated
  aoa_invocation_mode: explicit-preferred
  aoa_source_skill_path: skills/aoa-core-logic-boundary/SKILL.md
  aoa_source_repo: 8Dionysus/aoa-skills
  aoa_technique_dependencies: AOA-T-0016,AOA-T-0015
  aoa_portable_profile: codex-facing-wave-3
---

# aoa-core-logic-boundary

## Intent
Use this skill to separate reusable core logic from surrounding glue, orchestration, or infrastructure detail so future changes land in the right place.

## Trigger boundary
Use this skill when:
- a module mixes stable rules with wiring or execution detail
- the same logic is starting to appear in several places
- tests or reviews are muddy because the center of responsibility is unclear
- you need to decide whether something belongs in the core or at the edges

Do not use this skill when:
- the task is a tiny isolated fix with no meaningful boundary ambiguity
- the code is already clearly partitioned
- the result would only rename folders without improving understanding
- the main problem is recording decision rationale rather than boundary placement; use `aoa-adr-write` first
- the boundary is already clear and the main task is introducing a port or adapter around a concrete dependency; use `aoa-port-adapter-refactor`

## Inputs
- target module, service, or slice
- current responsibilities
- repeated or reusable logic candidates
- surrounding glue or orchestration context

## Outputs
- clarified boundary between core logic and surrounding glue
- notes on what should stay reusable versus edge-specific
- small refactor proposal or bounded implementation
- verification summary

## Procedure
1. identify which rules or behaviors are stable enough to count as reusable core logic
2. identify which parts are mostly wiring, orchestration, I/O, or environment detail
3. separate the concerns conceptually before moving code
4. move or propose moving only the bounded subset that clearly belongs in the core
5. avoid renaming or restructuring for ceremony alone
6. verify that the new boundary improves changeability and review clarity

## Contracts
- reusable logic should not stay trapped in glue if that blocks testing or reuse
- glue should not be over-promoted into domain logic without reason
- the boundary should improve clarity, not just aesthetics
- the change should remain reviewable and bounded

## Risks and anti-patterns
- treating all logic as core logic and over-abstracting the system
- moving orchestration detail into the core under the label of purity
- renaming layers without reducing actual confusion
- hiding a broad rewrite inside a boundary-cleanup task

## Verification
- confirm the core candidate is genuinely reusable or stability-shaped
- confirm edge-specific code remains at the edge when appropriate
- confirm the refactor improved clarity for future changes
- confirm no unrelated structural churn was introduced

## Technique traceability
Manifest-backed techniques:
- AOA-T-0016 from `8Dionysus/aoa-techniques` at `5c6f0496edc3c2e74590baa35627c85fe58ef765` using path `techniques/docs/bounded-context-map/TECHNIQUE.md` and sections: Intent, When to use, Outputs, Core procedure, Contracts, Validation
- AOA-T-0015 from `8Dionysus/aoa-techniques` at `5c6f0496edc3c2e74590baa35627c85fe58ef765` using path `techniques/evaluation/contract-test-design/TECHNIQUE.md` and sections: Intent, When to use, Inputs, Outputs, Core procedure, Contracts, Risks, Validation

## Adaptation points
Future project overlays may add:
- local layering conventions
- preferred directories or module boundaries
- repository-specific examples of core versus glue
- local verification commands