[RFC] Make publishability gate an explicit startup-contract policy

[gaofeng21cn]

Problem

DeepScientist already nudges paper-required quests to stop weak lines and to judge publishability before opening write, but this behavior is currently mostly implicit in prompt/skill wording.

That makes three things hard:

• users cannot explicitly choose how strong this gate should be for a given quest
• UIs and startup contracts cannot clearly show whether a project is running with a soft warning or a hard write admission rule
• downstream automation cannot reliably inspect a stable gate policy or gate result contract

Proposal

Introduce an explicit startup-contract policy for paper-mode publishability gating.

Possible shape:

• publishability_gate_mode: off | warn | enforce
• optional gate checkpoints such as post_scout, post_main_result, and pre_write
• a stable gate result contract that records at least:
  • allow_continue
  • allow_write
  • recommended_action
  • missing_key_evidence

Why this helps

This would turn an important workflow norm into an auditable runtime contract without forcing one house style on every user.

It should help teams that want:

• paper-first autonomous quests
• stronger stop / branch discipline after weak main results
• cleaner separation between "can draft" and "should continue"

Non-goals

This RFC is not proposing that DeepScientist hard-code any specific venue target, domain preference, or metric threshold.

Examples of things that should stay out of core defaults:

• "Q2+ only"
• domain-specific thresholds such as a fixed AUC delta cutoff
• field-specific clinical utility priorities

Those belong in quest briefs, workspace policy, or higher-level orchestration.

Candidate implementation scope

• prompt builder reads explicit gate mode from startup contract
• decision and write skills align with that mode
• project creation / startup docs expose the option
• prompt tests cover enabled vs disabled behavior

Alternatives considered

• Keep the current implicit prompt-only behavior: simple, but hard to inspect and hard to tune per quest
• Make strict publishability gating the default for all paper quests: too opinionated for general upstream behavior

Compatibility

A safe migration path would be:

• existing quests default to current behavior
• new explicit field overrides the default when present