### 2026-09-20
1. Each agent has a *Model* for both input and output
2. Implemented base class for Model that provide abstract render_dbg function (allows print debug info in console) and to_prompt_text that allows to summarize a model for prompting
3. Model was renamed to Contract as it best represent the future usage
4. IssueReader renamed to IssueTriage since it create a step sequence for solution
5. IssueTriage can now post comments to clarify requirements and ask for missing agents skills 

### 2026-09-19
1. Created an agent that can accept YouTrack™ task ID, read an issue, create a context for a task (body, comments, image attachments) and decompose it for implementing
2. **[missing]** extract a decomposing because it's manner depends on the task context (i.e. backend-dev, frontend-dev, seller, marketing, ad, design, ...) so an issue_reader agent should listen for not delivered tasks, create a context and delegate a decomposition for specific agent. If there is no agent can create this work - add comment that it cannot be resolved until appropriate agent will be created, assign a task to admin and change status to "To Be Discussed". There should be an agent that has information about all the rest of agents and can provide the information, who can do that task and how (in case of confusing - ask another agents if they can do the task). As this architecture is a very future automatization, it is enough to have just a registry of agents and omit the conversation of issue reader with another agents. **[adopted restrictions]** agents work in context of single project which is zArch (issues ARCH-*) so: 
   1. project is defined, .yaml exists
   2. agent list is known agents can ask each other