Core Layer
Core Layer
Map Custy's pipeline, workflow, Git, changelog, initialization, maintenance, and shared runtime services.
app/core/Category
Quick Command
orchestration + domain services + infrastructure adaptersOverview
app/core contains both application orchestration and reusable domain or
infrastructure services. The central WorkflowEngine is the application
facade used by most pipeline steps, while focused packages own lower-level Git,
changelog, initialization, backup, cleanup, and project-file behavior.
Subsystem Map
Pipeline
app/core/pipeline
Defines profiles, step priority, expansion, registry construction, shared context, progress presentation, and sequential failure behavior.
Workflow
app/core/workflow
Builds WorkflowConfig, constructs services, holds release runtime state, and
coordinates validation, generation, commit, tag, push, and finalization.
Git Operations
app/core/git_ops
Separates high-level repository policy from protocol-backed subprocess execution, version-tag generation, tag sorting, and format conversion.
Changelog
app/core/changelog
Loads typed settings, collects messages, creates release models, transforms commit content, applies release behavior, sorts, renders Jinja, and writes Markdown.
Initialization
app/core/initialize
Converts an initialization mode into an InitSpec, locates packaged resources,
creates directories and files, and reports results through Rich presentation.
Backup and Cleanup
backup, cleanup, branch_workflow
Creates retained message backups, removes old artifacts, filters and deletes branches, and coordinates experimental release-branch transitions.
Dry Run and Files
dry_run and files
Wraps subprocess simulation through Runner and updates supported project
version files through shared file utilities.
Shared Contracts
shared and exceptions
Provides base application exceptions and result types used across configuration, validation, Git, and workflow boundaries.
Dependency Direction
The common runtime direction is:
CLI callback
-> pipeline resolver and builders
-> registered step
-> WorkflowEngine
-> focused service
-> executor, filesystem, template, or subprocess
Changelog providers and cleanup services depend on GitService, not directly
on the low-level executor. Pipeline steps depend on the workflow engine through
GitContext. Initialization is a separate coordinator that builds a scaffold
plan instead of using the general workflow engine for file selection.
Centralization Trade-off
WorkflowEngine provides a convenient cohesive API for steps and owns shared
services, but it also concentrates validation, versioning, editing, staging,
backup, commit, tag, push, and branch-finalization behavior in one large
application service. New behavior should prefer a focused service plus a thin
engine method rather than expanding low-level implementation inside the
facade.