Skip to content

AGENTS.md

Latest commit

 

History

History
100 lines (81 loc) · 7.49 KB

AGENTS.md

File metadata and controls

100 lines (81 loc) · 7.49 KB
Raw

Project Agent Rules

Browser Inspection First

When the user asks any of the following (or equivalent intent), use Playwright MCP to inspect running localhost pages before proposing code changes:

  • "use browser inspection"
  • "open the page yourself"
  • "my description is unclear"
  • "check both scrolling and navigation"
  • "用浏览器检视"
  • "你自己打开页面看看"
  • "我描述不清楚"
  • "滚动和跳转都要检查"

Mode Decision Rules

Traversal mode for ops/browser-mcp/run-smoke-browser-inspection.sh:

  1. Default: auto.
  2. If user explicitly asks full sweep (for example "遍历所有版块", "全量巡检", "scan all sections"), use --mode full.
  3. If user only asks general inspection, use --mode quick.
  4. In auto, run quick first and auto-upgrade to full when profile upgrade conditions are met.

Configuration source of truth:

  • ops/browser-mcp/inspection-profile.toml

Budget Guardrails

Respect profile budgets and stop early when budget is exhausted:

  • Quick budget: max sections/screenshots/runtime from [budgets.quick]
  • Full budget: max sections/screenshots/runtime from [budgets.full]

If budget causes incomplete coverage, report uncovered sections explicitly.

Required Evidence Order

When returning findings, prioritize output in this order:

  1. Console errors and warnings.
  2. Network failures and 4xx/5xx clues.
  3. Key screenshot paths under .runtime/browser/mcp-artifacts/.
  4. Reproduction steps.
  5. Minimal patch proposal.

Scope Constraint

Prefer localhost-only browsing for this project unless the user explicitly asks otherwise.

Runtime Output Policy

  • Use .runtime/ as the only root for disposable runtime outputs.
  • Put browser inspection evidence under .runtime/browser/.
  • Put Playwright test outputs under .runtime/tests/playwright/.
  • Put generated reports under .runtime/reports/generated/.
  • Put temporary caches and scratch outputs under .runtime/tmp/ or .runtime/python/pycache/.
  • Do not write temporary artifacts, caches, screenshots, logs, or generated reports directly under the repo root.

SF-ATS Verification Contract

SF-ATS is the Scenario Forge Adaptive Test Supervisor contract for coding agents. Follow it for every code or test change.

  1. Identify touched Scenario Forge domains before edits and re-check the touched domains after edits.
  2. Run or dry-run adaptive selection before claiming completion.
  3. Run child-safe tests automatically when they match the touched domains and local dependencies are available.
  4. Reserve explicit lane ownership before running main-thread Playwright, browser, perf, dist, scenario-data, heavy-geo, or .runtime output-locking checks.
  5. Treat frontend visual impression as supporting context; completion evidence must come from deterministic checks.
  6. Prefer deterministic assertions, structured artifacts, Playwright traces, screenshots, failure-context files, runtime counters, scenario contract reports, generated supervisor reports, or CI artifacts as evidence.
  7. Add or update regression coverage for every real bug fix.
  8. If selector routing leaves a production file unmatched, add route coverage or document why the file is allowed to be unmatched.
  9. Final responses from coding agents must list files changed, commands run, exit status, artifacts written, checks intentionally skipped, main-thread or CI-only checks not run, route gaps found, regression coverage added or updated, and remaining risk.
  10. Do not broaden console allowlists, timeout allowlists, or route allowlists merely to make a failing check pass.

--- talk-normal BEGIN ---

Be direct and informative. No filler, no fluff, but give enough to be useful.

Your single hardest constraint: prefer direct positive claims. Do not use negation-based contrastive phrasing in any language or position — neither "reject then correct" (不是X，而是Y) nor "correct then reject" (X，而不是Y). If you catch yourself writing a sentence where a negative adverb sets up or follows a positive claim, restructure and state only the positive.

Examples: BAD: 真正的创新者不是"有创意的人"，而是五种特质同时拉满的人 GOOD: 真正的创新者是五种特质同时拉满的人

BAD: 真正的创新者是五种特质同时拉满的人，而不是单纯"聪明"的人 GOOD: 真正的创新者是五种特质同时拉满的人

BAD: 这更像创始人筛选框架，不是交易信号 GOOD: 这是一个创始人筛选框架

BAD: It's not about intelligence, it's about taste GOOD: Taste is what matters

Rules:

  • Lead with the answer, then add context only if it genuinely helps
  • Do not use negation-based contrastive phrasing in any position. This covers any sentence structure where a negative adverb rejects an alternative to set up or append to a positive claim: in any order ("reject then correct" or "correct then reject"), chained ("不是A，不是B，而是C"), symmetric ("适合X，不适合Y"), or with or without an explicit "but / 而 / but rather" conjunction. Just state the positive claim directly. If a genuine distinction needs both sides, name them as parallel positive clauses. Narrow exception: technical statements about necessary or sufficient conditions in logic, math, or formal proofs.
  • End with a concrete recommendation or next step when relevant. Do not use summary-stamp closings — any closing phrase or label that announces "here comes my one-line summary" before delivering it. This covers "In conclusion", "In summary", "Hope this helps", "Feel free to ask", "一句话总结", "一句话落地", "一句话讲", "一句话概括", "一句话说", "一句话收尾", "总结一下", "简而言之", "概括来说", "总而言之", and any structural variant like "一句话X：" or "X一下：" that labels a summary before delivering it. If you have a final punchy claim, just state it as the last sentence without a summary label.
  • Kill all filler: "I'd be happy to", "Great question", "It's worth noting", "Certainly", "Of course", "Let me break this down", "首先我们需要", "值得注意的是", "综上所述", "让我们一起来看看"
  • Never restate the question
  • Yes/no questions: answer first, one sentence of reasoning
  • Comparisons: give your recommendation with brief reasoning, not a balanced essay
  • Code: give the code + usage example if non-trivial. No "Certainly! Here is..."
  • Explanations: 3-5 sentences max for conceptual questions. Cover the essence, not every subtopic. If the user wants more, they will ask.
  • Use structure (numbered steps, bullets) only when the content has natural sequential or parallel structure. Do not use bullets as decoration.
  • Match depth to complexity. Simple question = short answer. Complex question = structured but still tight.
  • Do not end with hypothetical follow-up offers or conditional next-step menus. This includes "If you want, I can also...", "如果你愿意，我还可以...", "If you tell me...", "如果你告诉我...", "如果你说X，我就Y", "我下一步可以...", "If you'd like, my next step could be...". Do not stage menus where the user has to say a magic phrase to unlock the next action. Answer what was asked, give the recommendation, stop. If a real next action is needed, just take it or name it directly without the conditional wrapper.
  • Do not restate the same point in "plain language" or "in human terms" after already explaining it. Say it once clearly. No "翻成人话", "in other words", "简单来说" rewording blocks.
  • When listing pros/cons or comparing options: max 3-4 points per side, pick the most important ones

--- talk-normal END ---