Goal

Bring AI collaboration to the next level: the user defines a working goal in natural language, for example:

"Find out why project X is not working"

After that, the agent independently goes through the process from finding the project and gathering context to testing hypotheses and recording the results in fi1osof.ru.

Target Scenario

Example of the desired workflow:

1. Find the project by name or ID.
2. Get its current context.
3. Read related tasks.
4. Read recent worklogs.
5. View recent events/changes for the project.
6. Check website/API/services availability, if applicable.
7. Retrieve data on recent deployments, errors, logs, and environment states.
8. Formulate several hypotheses for the cause of the problem.
9. Test the hypotheses that can be checked with available tools.
10. Create a new task or update an existing one.
11. Record the investigation result, evidence, links, and next actions in the task.

Roughly:

find project
→ gather recent changes
→ view open tasks
→ read recent worklogs
→ check website/API availability
→ view errors and deployments
→ formulate hypotheses
→ test available hypotheses
→ create/update task
→ record investigation result

What Already Exists

The GraphQL API already provides the basic entities needed to start such a process:

• projects;
• tasks;
• task worklogs;
• skills;
• timers/activity;
• executeSkill;
• readWebPage;
• other GraphQL queries/mutations.

This already makes it possible to implement part of the agent loop without separate external orchestration.

What is Missing

1. Standardized Technical Project Context

It should be possible to unambiguously retrieve technical sources related to the project:

• repositories;
• services;
• production/staging/dev environments;
• public and internal URLs;
• API endpoints;
• deployments;
• CI/CD runs;
• logs;
• errors;
• monitoring;
• configuration;
• documentation.

Without this, the agent can analyze tasks and work history well, but is not always able to determine the technical root cause of an incident.

2. Explicit Entity Relationships

It is desirable to have a machine-readable relationship graph, for example:

Project
├─ Repository
├─ Service
│  ├─ Environment
│  ├─ Endpoint
│  ├─ Deployment
│  └─ LogSource
├─ Task
│  └─ TaskWorkLog
└─ Documentation

It is important that the agent does not determine object ownership solely based on similar names.

3. Activity Feed / Change History

A unified way is needed to answer the question:

"What changed right before the problem occurred?"

Useful events:

• task modification;
• new worklog;
• deployment;
• commit/release;
• configuration change;
• health-check failure;
• new error;
• DNS/SSL change;
• service restart;
• user/agent actions affecting the project.

It is desirable to have a single query for recent project events with filtering by time and type.

4. Secure Hypothesis Testing Tools

The agent needs read-only or controlled diagnostic actions, such as:

• HTTP health-check;
• reading a web page;
• checking an API endpoint;
• getting HTTP status/headers/body fragment;
• DNS lookup;
• SSL certificate check;
• reading logs;
• checking service status;
• reading recent deployments;
• running a test;
• executing a diagnostic skill.

Part of this can be built on top of existing readWebPage and executeSkill.

5. Autonomy Policy

It is necessary to explicitly define which actions the agent can perform autonomously.

Allowed Without Additional Confirmation

• read data;
• search for a project and related entities;
• perform read-only diagnostics;
• formulate hypotheses;
• read logs and monitoring;
• create a diagnostic worklog;
• create a regular task if it is a natural result of the investigation;
• supplement the task with diagnostic results.

Only Upon Explicit User Command

• production deploy;
• restart production services;
• change production configuration;
• delete data;
• bulk changes;
• financial operations;
• administrative actions;
• change access rights;
• any other potentially destructive operations.

High-Level Skills

Not only low-level skills like "get list of tasks" are needed, but also working-goal level procedures.

Possible skills:

• investigate_project
• check_project_health
• analyze_recent_failures
• summarize_project_state
• investigate_incident
• analyze_recent_changes

For example, investigate_project can define a reproducible procedure:

resolve project
→ collect context
→ collect recent activity
→ inspect tasks/worklogs
→ run health checks
→ inspect deployments/errors/logs
→ produce hypotheses
→ test hypotheses
→ persist findings

A skill should describe not a specific response, but an investigation algorithm, safety rules, and the result formatting rules.

Investigation Result Format

It is desirable to save the result in Task.content or a worklog in Markdown.

Example structure:

# Investigation Result

## Symptom
...

## What Was Checked
- ...
- ...

## Observations
- ...

## Hypotheses
1. ...
2. ...

## Confirmed Cause
...

## Evidence
- [log / URL / deployment / commit](...)

## What Was Done
- ...

## Next Actions
- [ ] ...
- [ ] ...

Important Task Storage Principle

For tasks in fi1osof.ru, observe the separation:

• description — a short description of the task essence, literally a few sentences;
• content — all main problem statements, details, Markdown, links, checklists, examples, technical context, and analysis results.

Do not use description as the main long task field.

First Practical Stage

Before implementing the full workflow, audit the current GraphQL schema and available skills:

1. Determine which of the listed data sources already exist.
2. Check existing relationships between Project, Task, TaskWorkLog, skills, and other entities.
3. Find available operations for web/API diagnostics.
4. Determine if models for deployments, logs, environments, repositories, events/activity already exist.
5. Perform a gap analysis: what can already be done now / what is missing in the API / what is missing in skills.
6. Based on this, design a minimal investigate_project workflow.

Definition of Done

A task can be considered implemented when a command like:

"Find out why haih.net is not working today"

can be processed by the agent as a working goal, rather than as a series of manual GraphQL commands, and as a result the agent:

• independently gathers relevant context;
• shows exactly what it checked;
• distinguishes between facts and hypotheses;
• tests available hypotheses;
• does not perform dangerous actions without permission;
• saves the investigation summary to fi1osof.ru.