36 lines
2.4 KiB
Markdown
36 lines
2.4 KiB
Markdown
### 2026-09-23
|
|
1. Add memory for Agent - memory dir. Not count timestamps, need work
|
|
2. Add FileSelection - file graph is converting to consumable table, works for small amount of files
|
|
3. Refactor planification prompt - it is better now
|
|
|
|
### 2026-09-22
|
|
1. Add verification step - ensure the issue can be solved by coding
|
|
2. Add repo download step
|
|
3. Add repo analyzer: find entrypoint, build dependency graph
|
|
4. Add IssueComment class instead of dic
|
|
|
|
### 2026-09-21
|
|
1. Now comments are directed to team members in a language they can read
|
|
2. Comments used for context are filtered from TriageAgent to avoid hallucinations
|
|
3. Fixed missing ambiguous comment
|
|
|
|
### 2026-09-20
|
|
1. Each agent has a *Model* for both input and output
|
|
2. Implemented base class for Model that provides abstract render_dbg function (allows printing 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 represents the future usage
|
|
4. IssueReader renamed to IssueTriage since it creates a step sequence for solution
|
|
5. IssueTriage can now post comments to clarify requirements and ask for missing agent 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 the decomposition because its manner depends on the task context (i.e. backend-dev, frontend-dev, seller, marketing, ad, design, ...)
|
|
so an issue_reader agent should listen for undelivered tasks, create a context and delegate the decomposition to a specific agent.
|
|
If there is no agent that can do this work - add comment that it cannot be resolved until an appropriate agent is 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 confusion - ask the others agents if they can do the task).
|
|
As this architecture is a highly future-oriented automation, it is enough to have just a registry of agents and omit the conversation
|
|
between the issue reader and the other agents.
|
|
**[adopted restrictions]** agents work in the context of a single project, which is zArch (issues ARCH-*) so:
|
|
1. the project is defined, the .yaml exists
|
|
2. agent list is known, agents can ask each other |