1c-autoresearch-queue-worker

name	1c-autoresearch-queue-worker
description	Process exactly one task in a concrete 1C autoresearch repository. Use when selecting, claiming, executing, reviewing, or updating a task from analysis/queue/tasks.jsonl; creating feature evidence packs; or running static 1C customization analysis with project.toml, RLM, MCP, and web evidence policies.

1C Autoresearch Queue Worker

Ground Rules

• For /goal Исследование, use $1c-autoresearch-research-goal first; this skill is the queue execution route after the research-goal router selects queue work.
• Process exactly one queue task per run.
• Read project.toml before using source paths, RLM projects, MCP servers, or web access.
• Prefer static source evidence and cached indexes before live 1C access.
• Do not use MCP or web evidence unless both project.toml and the selected task allow it.
• Record file and line evidence for confirmed claims where possible.
• Mark runtime-data-dependent conclusions as needs_infobase_data.
• Run python -m one_c_autoresearch doctor before updating the selected task status.
• Stop after updating the selected task status.

Workflow

1. Read project.toml.

2. Read analysis/queue/README.md, task-schema.md, review-checklist.md, and tasks.jsonl.

3. Atomically claim one pending task with the highest priority whose dependencies are done:

   python -m one_c_autoresearch queue claim
   

4. Create a run log folder under analysis/runs/<timestamp>-<task-id>/ when the run produces useful diagnostics.

5. Inspect static sources, generated indexes, metadata, BSL, forms, roles, scheduled jobs, business processes, and extension overrides as required by the task quality gates.

6. Write evidence under analysis/features/<feature-id>/.

7. Run python -m one_c_autoresearch doctor and report any warnings or failures.

8. Update the selected task to evidence_pack, drafted, needs_review, needs_followup, blocked, or done. Use --expected-status claimed when moving a freshly claimed task forward.

Evidence Pack

Create or update only the selected feature folder:

analysis/features/<feature-id>/
  brief.md
  findings.md
  evidence.csv
  open-questions.md
  review.md
  artifacts/

Use evidence.csv for machine-readable source evidence. Keep human-facing deliverables under outputs/, not inside the feature evidence pack.

Review Standard

• Separate vendor baseline, target cf, target cfe, and next vendor evidence.
• Run positive and negative search.
• Label confidence as high, medium, or low.
• For subject-card tasks, recover the business scenario, user work, regulatory process, or integration process. Treat BF groups, tax domains, reports, XML, object kinds, forms, registers, and detail maps as evidence, not final card boundaries.
• Create follow-up tasks instead of expanding scope beyond the selected task.