K Configuration

- Adhere to Clean Architecture principles, as written by Robert Martin.
- Use type hints.
- Keep imports sorted at the top of the file.
- Limit classes to one per file.
- Keep service definitions up to date when modifying dependencies. Definitions are in services.yaml and follow a format similar to the Symfony framework.
- Commands can be configured in commands.yaml as needed to add functionality to the CLI.
- Update the README when appropriate.
- Remove unaccessed imports.
- Protocols and Use Case classes have "Protocol" and "UseCase" in their name, respectively, but do not have "_protocol" or "_use_case" in their file names.
- Follow the module resolution guidelines as defined in domain/util/module_resolution.py. Verify that all module paths referenced in services.yaml, commands.yaml, and elsewhere are valid to prevent errors, especially when invoking commands like 'k pr'.
- Leave existing comments in place when rewriting code. Add additional comments and comment blocks to improve code clarity.
- About Clean Architecture: This project contains directories representing four layers: Domain, Application, Adapters, and Infrastructure. Domain is at the core and Infrastructure is the outer layer. The layers should follow the dependency rule, with outer layers depending on inner layers only, and never the other way around. Use inversion of control in order to comply with the dependency rule by creating protocols (interfaces) at the Application layer which are implemented in the Infrastructure layer. 
- About Dependency Injection: This project uses a custom dependency injection container inspired by the Symfony framework. Service defintions are created in services.yaml. Look at container.py to see how these definitions get parsed. The syntax of the service definition file allows for environment variables and yaml definitions to be injected into services. Registries are commonly used to inject collections of like services as dependencies. These are assembled using tags, where the registry definition defines a tag to be used to identify services going into the collection, and the individual services in the definition are configured using the defined tag. Aliases are used for retrieving specific services from the registries. Lean heavily on this dependency injection. You should always inject dependencies and register them in the service container, rather than importing dependencies directly, unless it is infeasible to do so.
- About Workflows: This project enables the creation of workflows using Langgraph. Workflows are configured using a custom declarative syntax in workflows.yaml. Node names used in workflows.yaml correspond with the aliases that the node services have been tagged with in their respective definitions in services.yaml. This enables workflows to be created by composing and reusing pre-existing nodes. You should aim to maximize reusability when making any modifications to these workflows. Stick to established conventions. When modifying workflows, YOU MUST ALWAYS ENSURE THAT THE WORKFLOW, STATE, NODES, AND CONFIGURATION FILES ARE ALIGNED. DO NOT change a workflow without ensuring the workflow definition, service definitions, nodes and states are all aligned!! For example, it is useless to add a new state variable to a workflow if there is no node that uses this new state variable in a meaningful way. DO NOT DO THAT.
- Do not duplicate code. If a function already exists elsewhere in a state in which it cannot be reused, go ahead and refactor it into a shared component.