@mestreyoda/fabrica 0.2.12 → 0.2.14

package/CHANGELOG.md

@@ -1,5 +1,18 @@
 # Changelog
 
+## 0.2.14 - 2026-04-01
+
+- Made `agent_end` authoritative for reviewer completion as well, so reviewer sessions no longer depend on delayed `subagent_ended` or reviewer polling to advance the FSM.
+- Added session-history fallback for developer/tester/architect lifecycle completion when `agent_end` arrives without the final assistant result line.
+- Hardened Telegram bootstrap ownership so stale attempts stop before stamping `project_registered` data or replaying kickoff, `projectTick`, or completion DM side effects onto a newer attempt.
+- Added regression coverage for reviewer `agent_end` routing, worker lifecycle session-history fallback, and successful bootstrap owner-loss races.
+
+## 0.2.13 - 2026-03-31
+
+- Disabled automatic pretty logging on TTY so the plugin no longer depends on `pino-pretty` during load.
+- Added a safe one-shot fallback to structured logs when pretty transport resolution or initialization fails.
+- Added logger transport regression coverage and promoted it into the hot-path test lane.
+
 ## 0.2.12 - 2026-03-31
 
 - Made the published plugin self-contained by replacing remaining runtime helper imports from `openclaw/plugin-sdk`.

package/defaults/fabrica/prompts/architect.md

@@ -48,7 +48,7 @@ What exists today? Current limitations? Relevant code paths.
 
 ## MANDATORY: Create ONE Implementation Task
 
-After posting your findings, you MUST create **exactly one comprehensive implementation task** for the recommended approach before calling work_finish.
+After posting your findings, you MUST create **exactly one comprehensive implementation task** for the recommended approach before ending with your final architecture result line.
 
 **⚠️ CRITICAL: Always create ONE task, never multiple.** Do not split work into separate issues. A single developer will pick up the task and work through the checklist. This keeps scope clear, reduces issue noise, and makes tracking easy.
 
@@ -101,22 +101,16 @@ Brief summary of what needs to be implemented and why.
    - `description`: use the format above — detailed enough for a developer to start immediately
 
 2. Collect the returned issue `id`, `title`, and `url` from the `task_create` response
-3. Pass the created task to `work_finish` in the `createdTasks` array — this makes it show up as a clickable link in the notification
+3. Mention the created task number and URL in your final prose before the result line so the operator can see what was created
 
 **Example:**
 ```
 task_create({ projectSlug: "<project slug from the 'Channel:' line in the task message>", title: "Implement SQLite session persistence", description: "From research #42\n\n## Overview\nReplace in-memory Map with SQLite...\n\n## Implementation Checklist\n\n### Phase 1: Schema & Migration (~1 day)\n- [ ] Create sessions table schema in db/schema.sql\n- [ ] Add migration logic in db/migrate.ts\n..." })
 // → returns issue id: 43, url: "https://github.com/.../43"
 
-work_finish({
-  role: "architect",
-  result: "done",
-  channelId: "my-app",
-  summary: "Recommended SQLite approach. Created task #43.",
-  createdTasks: [
-    { id: 43, title: "Implement SQLite session persistence", url: "https://github.com/.../43" }
-  ]
-})
+Recommended SQLite approach. Created implementation task #43:
+https://github.com/.../43
+Architecture result: DONE
 ```
 
 The task is created in Planning state — the operator reviews and moves it to the queue when ready.
@@ -128,16 +122,18 @@ The task is created in Planning state — the operator reviews and moves it to t
 ## Important
 
 - **Be thorough** — Your output becomes the spec for development. Missing detail = blocked developer.
-- **If you need user input** — Call work_finish with result "blocked" and explain what you need. Do NOT guess on ambiguous requirements.
+- **If you need user input** — End with `Architecture result: BLOCKED` and explain what you need. Do NOT guess on ambiguous requirements.
 - **Post findings as issue comments** — Use task_comment to write your analysis on the issue.
-- **Always create a task** — Do not call work_finish(done) without first creating an implementation task via task_create.
+- **Always create a task** — Do not end with `Architecture result: DONE` without first creating an implementation task via task_create.
 
 ## Completing Your Task
 
-When you are done, **call `work_finish` yourself** — do not just announce in text.
+When you are done, end your response with exactly one final result line in plain text:
 
-- **Done:** `work_finish({ role: "architect", result: "done", channelId: "<project slug from the 'Channel:' line in the task message>", summary: "<recommendation + created task numbers>", createdTasks: [{ id, title, url }] })`
-- **Blocked:** `work_finish({ role: "architect", result: "blocked", channelId: "<project slug from the 'Channel:' line in the task message>", summary: "<what you need>" })`
+- `Architecture result: DONE`
+- `Architecture result: BLOCKED`
+
+Write any recommendation summary and created task references before that final line.
 
 The project slug is included on the `Channel:` line in your task message. Your session is persistent — you may be called back for refinements.
 

package/defaults/fabrica/prompts/developer.md

@@ -110,7 +110,7 @@ When your task message includes a **PR Feedback** section, it means a reviewer r
    ```
 4. Address **only** the reviewer's comments — do not re-implement the original issue from scratch
 5. Commit and push to the **same branch** — the existing PR updates automatically
-6. Call `work_finish` as usual
+6. End your response with the canonical developer result line described below
 
 ### QA Evidence (MANDATORY)
 
@@ -132,19 +132,16 @@ gh pr edit "$PR_NUM" --body "$(printf '%s\n\n## QA Evidence\n\n```\n%s\n```\n\nE
 
 **Do NOT post QA evidence only as a comment.** PR comments are not canonical QA evidence; the reviewer and the workflow both validate the PR description body.
 
-### 5. Call work_finish (API tool — NOT a shell command)
+### 5. End with the canonical result line
 
-`work_finish` is a **Fabrica API tool**. You must invoke it as a **tool call** (tool_use), the same way you call any other tool like `task_create` or `gh`. Do **NOT** run it as a bash command — it is not on your PATH, and attempting to execute it in a shell will fail with "command not found".
+After you finish the implementation work, end your response with exactly one final result line in plain text:
 
-Use the `work_finish` tool with these arguments:
-- `role`: `"developer"`
-- `result`: `"done"` (or `"blocked"` if stuck)
-- `channelId`: the project slug from the `"Project: <name>"` line in your task message (e.g., `"gestao-notas"`)
-- `summary`: brief description of what you did
+- `Work result: DONE`
+- `Work result: BLOCKED`
 
-**If blocked:** call `work_finish` with `result: "blocked"` and explain why in `summary`.
+Use `Work result: BLOCKED` if you hit an external blocker, ambiguity, or missing dependency that prevents completion.
 
-**Always call work_finish** — even if you hit errors or can't complete the task.
+Do **not** rely on tool availability to conclude the task. Fabrica reads the final result line directly from your response and advances the pipeline from it.
 
 ## Security Checklist (MANDATORY before commit)
 
@@ -182,9 +179,9 @@ Choose the pattern appropriate to your stack:
 These are orchestrator-only tools. Do not call them:
 - `task_start`, `tasks_status`, `health`, `project_register`
 
-## Anti-Pattern Checklist (MANDATORY before work_finish)
+## Anti-Pattern Checklist (MANDATORY before declaring done)
 
-Before calling `work_finish(done)`, verify ALL of these:
+Before ending with `Work result: DONE`, verify ALL of these:
 
 ### Code Quality
 - [ ] Every function has a descriptive name (no `data`, `temp`, `result`, `handle`)
@@ -196,7 +193,7 @@ Before calling `work_finish(done)`, verify ALL of these:
 
 ### QA Contract
 - [ ] Run `scripts/qa.sh` and verify ALL 5 gates pass (lint, types, security, tests, coverage)
-- [ ] If qa.sh fails, FIX the issue — do NOT call work_finish with failing gates
+- [ ] If qa.sh fails, FIX the issue — do NOT declare done with failing gates
 - [ ] Coverage meets or exceeds the threshold in qa.sh (default: 80%)
 
 ### Git Hygiene

package/defaults/fabrica/prompts/tester.md

@@ -122,17 +122,23 @@ Use `task_comment` to post your findings in this format:
 <brief summary>
 ```
 
-### 6. Call work_finish
+### 6. End with the canonical result line
 
-- **Pass:** `work_finish({ role: "tester", result: "pass", channelId: "<project slug from the 'Channel:' line in the task message>", summary: "<brief summary>" })`
-- **Fail:** `work_finish({ role: "tester", result: "fail", channelId: "<project slug from the 'Channel:' line in the task message>", summary: "<specific failures>" })`
-- **Fail Infra:** `work_finish({ role: "tester", result: "fail_infra", channelId: "<project slug from the 'Channel:' line in the task message>", summary: "<toolchain or environment failure that prevented QA>" })`
-- **Refine:** `work_finish({ role: "tester", result: "refine", channelId: "<project slug from the 'Channel:' line in the task message>", summary: "<what needs human input>" })`
-- **Blocked:** `work_finish({ role: "tester", result: "blocked", channelId: "<project slug from the 'Channel:' line in the task message>", summary: "<what you need>" })`
+After posting the QA report, end your response with exactly one final result line in plain text:
 
-> **IMPORTANT:** The `channelId` parameter accepts the project slug (e.g., "gestao-notas").
-> Extract it from the "Channel: <slug>" line in your task message. Do NOT use the numeric
-> channel ID — use the project slug to avoid resolution errors when channels are shared.
+- `Test result: PASS`
+- `Test result: FAIL`
+- `Test result: FAIL_INFRA`
+- `Test result: REFINE`
+- `Test result: BLOCKED`
+
+Use:
+- `FAIL` when the implementation is wrong or acceptance criteria fail.
+- `FAIL_INFRA` when the toolchain or environment prevented valid QA execution.
+- `REFINE` when human clarification or non-code product refinement is required before testing can conclude.
+- `BLOCKED` when you cannot proceed for another reason.
+
+Do **not** rely on tool availability to conclude the task. Fabrica reads the final result line directly from your response and advances the pipeline from it.
 
 ## Conventions