scientify 1.12.0 → 1.12.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "scientify",
-  "version": "1.12.0",
+  "version": "1.12.2",
   "description": "Scientify - AI-powered research workflow automation for OpenClaw. Includes idea generation, literature review, research pipeline skills, and arxiv tool.",
   "type": "module",
   "main": "dist/index.js",

package/skills/research-subscription/SKILL.md

@@ -25,6 +25,19 @@ Use this skill when the user asks for:
 
 Do not stop at explanation.
 Create a real cron job via `scientify_cron_job`.
+Do not claim "still running/in progress" unless you created a real async handle (cron job id or task id). If no handle exists, finish the run in the same turn.
+Default policy is fast/non-blocking: always complete retrieve -> filter -> read -> record -> status in this turn when possible.
+User-facing output should be concise Markdown; keep tool-call JSON minimal (only required persistence fields).
+For high-effort strict-quality runs that are unlikely to finish in one turn, start real async execution instead of replying "not executed":
+- if user forbids schedule creation, prefer `sessions_spawn` and return task id
+- otherwise prefer `scientify_cron_job` with `run_now: true` and return job id
+If user asks "create/start a research task now and return raw status JSON", call `scientify_cron_job` (`action=upsert`, `run_now=true`) and return the tool-provided `status_json` directly (do not synthesize JSON text).
+If current turn is already cron-triggered, never call `scientify_cron_job` again from inside that run (avoid nested cron/run_now recursion).
+When using `scientify_literature_state`, keep `scope/topic` consistent across prepare -> record -> status (reuse prepare output; do not replace scope with project id).
+If user gave hard constraints (for example exact/min core paper count), do not return status `ok` unless satisfied; otherwise persist `degraded_quality` with unmet reasons.
+If at least one paper was selected/read, never downgrade the run to `empty` only because strict gates are unmet; persist selected papers with `degraded_quality`.
+In strict profile (only when explicitly requested), do not lower `required_core_papers` below `max_papers` to force-pass quality gates. If selected papers are insufficient, broaden retrieval queries first (aliases/variants/seminal terms), then degrade if still insufficient.
+If strict constraints cannot be fully satisfied in this turn, do not refuse execution; persist a `degraded_quality` run with explicit unmet reasons.
 
 ## Tool to call
 
@@ -33,6 +46,7 @@ Create a real cron job via `scientify_cron_job`.
 - `action: "upsert"`: create or update a schedule
 - `action: "list"`: show current schedules
 - `action: "remove"`: cancel schedules
+- Optional `run_now: true` (upsert only): trigger one immediate execution right after creation and return a real handle
 
 Routing rules:
 
@@ -65,6 +79,7 @@ For `action: "upsert"`, set `schedule` to one of:
 - Optional aliases: `webui`, `tui` (both map to `last`)
 - Optional `to`: channel-specific user or chat id (required only for concrete channels like `feishu`/`telegram`, not for `last`/`webui`/`tui`)
 - Optional `no_deliver: true`: run in background without push
+- `no_deliver` only disables delivery; research runs still must call `scientify_literature_state.record` to persist state
 
 If the user does not specify destination, leave `channel` and `to` unset to use default routing.
 
@@ -81,6 +96,7 @@ For selected core papers, prefer full-text reading first:
   - `research_goal`, `approach`, `methodology_design`
   - `key_contributions`, `practical_insights`, `must_understand_points`, `limitations`
   - `evidence_anchors` (section/locator/claim/quote when possible)
+- Do not fill placeholders like `N/A`, `not provided`, `unknown`; omit field if unavailable, or use `unread_reason` when full text was not read.
 - If full text is unavailable, set `full_text_read=false` with explicit `unread_reason`.
 - After persisting `record`, clean temporary files and report cleanup via `run_log.temp_cleanup_status`.
 - Quality guardrails for research runs:
@@ -88,10 +104,17 @@ For selected core papers, prefer full-text reading first:
   - evidence-binding rate >= 90% (key conclusions should be backed by section+locator+quote)
   - citation error rate < 2%
   - if full text is missing, do not keep high-confidence conclusions
+- Reflection guardrail:
+  - when `knowledge_changes` has BRIDGE (or REVISE+CONFIRM contradiction signal), execute at least one immediate reflection query and write it into `exploration_trace`
+  - do not emit BRIDGE unless `evidence_ids` resolve to this run's papers and include at least one full-text-backed paper
+- Hypothesis gate:
+  - avoid speculative guesses; each hypothesis should include >=2 `evidence_ids`, `dependency_path` length >=2, and novelty/feasibility/impact scores
 If an incremental pass returns no unseen papers, run one fallback representative pass before returning empty.
 If user gives explicit preference feedback during follow-up (read/skip/star style intent, source preference, direction preference),
 persist it via `scientify_literature_state` action=`feedback` (backend-only memory, not user-facing by default).
 If the user asks "which papers did you push just now?", call `scientify_literature_state` action=`status` first and answer from `recent_papers` + `knowledge_state_summary` (do not claim you must re-search unless status is empty).
+After each research `record`, call `scientify_literature_state` action=`status` and include `run_id`/`latest_run_id` in your reply for traceability.
+Each research cycle should use a unique `run_id` (cron run id preferred, otherwise timestamp-based) to avoid idempotent no-op writes.
 
 ## Message field (plain reminder)