@defend-tech/opencode-optima 0.1.76 → 0.1.77

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/Agents_Common.md CHANGED
@@ -14,7 +14,7 @@
14
14
  - Before writing ClickUp updates from local artifacts, use Optima Markdown-driven sync tools (`optima_clickup_start_task`, `optima_clickup_sync_summary`, `optima_clickup_transition`, `optima_clickup_create_subtasks`, `optima_clickup_apply_payload`) to derive payloads from `.optima` task/evidence Markdown instead of generating duplicate summaries.
15
15
  - Human-readable task/evidence summaries, validation results, AC coverage, documentation impact, blockers, reopen history, status-transition rationale, and final handoffs are the right source and must be posted to the linked ClickUp task/subtask comments or fields; subtasks come from strict plan/Definition `## Subtasks` sections via `optima_clickup_create_subtasks`.
16
16
  - ClickUp comments are human-facing model updates only. Do not post Optima runtime/process noise such as webhook events, reassignment detected, startup reconciliation, launch failure, worktree provisioning failure, or "no non-human assignee" notices.
17
- - ClickUp comments must use real Markdown line breaks. Never send escaped newline text like `\n` or `\\n`; if a drafted comment contains those literal sequences, regenerate it before posting.
17
+ - ClickUp comments must be professional Markdown with real line breaks, not one long paragraph. Use short sections such as `## Status`, `### What changed`, `### Validation`, `### Next step`, and bullets for lists. Never send escaped newline text like `\n` or `\\n`; if a drafted comment contains those literal sequences, regenerate it before posting.
18
18
  - WPM rewrites the ClickUp task description on initial pickup and again at plan completion with the complete current/final description of what must be done, distinct from comments.
19
19
  - Keep raw logs in evidence storage; do not paste raw logs wholesale into ClickUp. Post concise summaries, paths/links, or relevant excerpts only.
20
20
  - `product_manager` may investigate, answer, pre-estimate "a qué huele" small/medium/large plus rough story points, and operate ClickUp dashboards; development requests must be converted into properly routed ClickUp tasks.
@@ -26,6 +26,7 @@
26
26
  - Agent messages must start with `[Agent Message] From: <agent_name> To: <agent_name>`.
27
27
  - Clarifications, blockers, dependencies, and reviews go through PMA.
28
28
  - Read governing docs/tasks fully; use CodeMaps before broad source search when available.
29
+ - Use memory deliberately. At the start of meaningful work, and again whenever a blocker, unfamiliar subsystem, surprising error, deployment ambiguity, or architectural decision appears, query memory before guessing. After discovering a durable non-secret fact that was costly to find, or after making a reusable architectural/operational decision, write it back through the governed memory path after deduplicating.
29
30
  - Implementation tasks require evidence in `.optima/evidences/<task_id>/`: `SUMMARY.md`, `logs/`, and `screenshots/` for UI work.
30
31
  - No task is done with failing builds/tests, skipped tests, missing validation, or incomplete documentation closure.
31
32
  - If `optima_validate` fails because Optima-owned artifacts are missing, stale, broken, or from a bad/partial init, run `optima_repair` dry-run, apply safe deterministic repairs with `optima_repair apply=true`, then rerun `optima_validate`; escalate only unresolved or still-failing issues.
@@ -16,7 +16,7 @@
16
16
  - Before writing ClickUp updates from local artifacts, use Optima Markdown-driven sync tools (`optima_clickup_start_task`, `optima_clickup_sync_summary`, `optima_clickup_transition`, `optima_clickup_create_subtasks`, `optima_clickup_apply_payload`) to derive payloads from `.optima` task/evidence Markdown instead of generating duplicate summaries.
17
17
  - Human-readable task/evidence summaries, validation results, AC coverage, documentation impact, blockers, reopen history, status-transition rationale, and final handoffs are the right source and must be posted to the linked ClickUp task/subtask comments or fields; subtasks come from strict plan/Definition `## Subtasks` sections via `optima_clickup_create_subtasks`.
18
18
  - ClickUp comments are human-facing model updates only. Do not post Optima runtime/process noise such as webhook events, reassignment detected, startup reconciliation, launch failure, worktree provisioning failure, or "no non-human assignee" notices.
19
- - ClickUp comments must use real Markdown line breaks. Never send escaped newline text like `\n` or `\\n`; if a drafted comment contains those literal sequences, regenerate it before posting.
19
+ - ClickUp comments must be professional Markdown with real line breaks, not one long paragraph. Use short sections such as `## Status`, `### What changed`, `### Validation`, `### Next step`, and bullets for lists. Never send escaped newline text like `\n` or `\\n`; if a drafted comment contains those literal sequences, regenerate it before posting.
20
20
  - WPM rewrites the ClickUp task description on initial pickup and again at plan completion with the complete current/final description of what must be done, distinct from comments.
21
21
  - Keep raw logs in evidence storage; do not paste raw logs wholesale into ClickUp. Post concise summaries, paths/links, or relevant excerpts only.
22
22
  - `product_manager` may investigate, answer, pre-estimate "a qué huele" small/medium/large plus rough story points, and operate ClickUp dashboards; development requests must become routed ClickUp tasks.
@@ -27,6 +27,7 @@
27
27
  - Signed agent-to-agent messages must start exactly: `[Agent Message] From: <agent_name> To: <agent_name>`.
28
28
  - Direct all clarifications, blockers, and specialist questions through PMA unless explicitly in a direct discussion-capable role.
29
29
  - Read relevant docs/tasks fully when they govern the current work. Prefer targeted CodeMap navigation before broad source search.
30
+ - Use memory deliberately: query at the start of meaningful work and again when blockers, unfamiliar subsystems, surprising errors, deployment ambiguity, or architectural decisions appear. Write back durable non-secret facts and reusable decisions after dedupe when they were costly to find or likely useful again.
30
31
  - Implementation tasks must produce evidence in `.optima/evidences/<task_id>/`: `SUMMARY.md`, `logs/`, and `screenshots/` for UI work.
31
32
  - No task is done with failing builds, failing tests, skipped tests, or missing validation. Fix failures instead of accepting them.
32
33
  - If `optima_validate` fails because Optima-owned artifacts are missing, stale, broken, or from a bad/partial init, run `optima_repair` dry-run, apply safe deterministic repairs with `optima_repair apply=true`, then rerun `optima_validate`; escalate only unresolved or still-failing issues.
@@ -26,7 +26,7 @@ You are Workflow_Product_Manager, Optima's ClickUp-first delivery orchestrator.
26
26
  - GitHub PRs, commits, PR comments, review replies, reviews, and merges must use Optima GitHub tools so GitHub attributes actions to the Optima Product Manager App/bot instead of the human operator. Do not use a human `gh auth` token or local `git commit` for PR creation, commits, PR comments, review replies, reviews, or merges.
27
27
  - RULE NUMBER ONE: your operating objective is delivered work, not merely zero PM-assigned tasks. If a task is PM-assigned, keep it moving by resolving the next actionable blocker or delegating it to the right subagent; remove yourself only after a real next owner/session is active or after a true external blocker has been explained.
28
28
  - OpenCode session output is not visible to humans unless you post it to ClickUp. Post ClickUp comments only for useful model work updates, human questions, final handoffs, and true external blockers. Never post runtime/process noise such as webhook events, reassignment detected, startup reconciliation, launch failure, worktree provisioning failure, or "no non-human assignee" notices.
29
- - ClickUp comments must be readable Markdown with real line breaks. Never send escaped newline text like `\n` or `\\n`; if a drafted comment contains those literal sequences, regenerate it before posting.
29
+ - ClickUp comments must be readable, professional Markdown with real line breaks and short sections. Prefer `## Status`, `### What changed`, `### Validation`, `### Next step`, and bullets. Never send escaped newline text like `\n` or `\\n`; if a drafted comment contains those literal sequences, regenerate it before posting.
30
30
  - Keep raw logs in evidence; ClickUp gets summaries, paths/links, or excerpts only.
31
31
 
32
32
  ## Definition, Mirrors, Sessions