export declare const CORE_HELP = "# Core Operations\n- **Workspace Isolation**: When creating or reading entries, consider the `workspace_id` parameter. If a default workspace is active, entries are automatically scoped to it unless explicitly overridden.\n\n### Session Summaries\n\nUse the `memory-journal-mcp entry create` terminal command to record session summaries. You MUST provide the markdown content via `--content \"<string>\"` or `--file <path>` (or pipe to stdin). Required fields:\n\n- `--type retrospective`\n- `--tags session-summary` (plus relevant domain/activity tags, comma-separated)\n- `--project` from the briefing\n- `--impact-score`, `--trust-score`, and `--validation-status` MUST be evaluated and populated.\n- `--related-to` MUST be populated with IDs of related tasks, architectural plans, or preceding summaries.\n- `--auto-context` MUST be populated with a concise JSON payload representing the context (e.g. `{ \"commits\": [\"abc1234\", \"def5678\"] }`)\n\nDo NOT create session summaries for testing passes where everything passed and no code changes were made. Only summarize sessions with substantive work.\n\n### Entry Type Selection\n\nChoose the correct `entry_type` \u2014 do NOT default everything to `personal_reflection`:\n\n- `retrospective` \u2014 Session summaries, certification reports, any \"what was accomplished\" recap\n- `bug_fix` \u2014 Specific bug identification and/or resolution\n- `project_decision` \u2014 Architecture decisions, pattern adoptions, technology choices\n- `planning` \u2014 Roadmaps, sprint plans, project initialization\n- `code_review` \u2014 Security audits, code quality reviews, copilot findings\n- `technical_note` \u2014 Implementation notes, gotchas, reference documentation\n- `feature_implementation` \u2014 New feature completions\n- `research` \u2014 Investigation, benchmarking, evaluation of alternatives\n- `meeting_notes` \u2014 Meeting minutes, sync notes, discussion summaries\n- `learning` \u2014 Lessons learned, tutorials completed, skill acquisition\n- `standup` \u2014 Daily standup notes, status updates\n- `milestone` \u2014 Major project milestones, release checkpoints\n- `technical_achievement` \u2014 Significant technical accomplishments\n- `enhancement` \u2014 Incremental improvements, optimizations\n- `development_note` \u2014 Day-to-day development context and progress\n- `system_integration_test` \u2014 Full integration/e2e test results\n- `test_entry` \u2014 Automated or manual test results\n- `plan_draft` \u2014 Initial drafts of implementation plans\n- `adversarial_review` \u2014 Reviews and critiques from adversarial subagents\n- `plan_refinement` \u2014 Refinements to plans based on reviews\n- `plan_finalized` \u2014 Finalized implementation plans after review\n- `copilot_validation` \u2014 Validation of copilot suggestions\n- `maintenance` \u2014 Scheduled or manual database optimization, CMS consolidation, and infrastructure healing reports\n- `other` \u2014 Anything that doesn't fit the above categories\n- `personal_reflection` \u2014 Only for genuinely personal notes that don't fit above\n\n### Tag Taxonomy\n\nEvery entry MUST have at least one tag. Use kebab-case exclusively.\nTags are limited to a maximum of 100 characters. Journal entry content is limited to a maximum of 50,000 characters.\n\n- _Activity_: `session-summary`, `certification`, `stress-test`, `bug-fix`, `release`, `audit`, `remediation`, `refactor`\n- _Domain_: `security`, `performance`, `architecture`, `code-mode`, `documentation`, `ci-cd`, `github-integration`\n- _Tool group_: Name of the tool group being worked on (e.g., `core`, `search`, `github`, `admin`)\n- _Pattern_: `split-schema`, `zod`, `error-handling`, `dual-schema`\n\n### Heuristic Scoring Criteria\n\nALL entries MUST define heuristic scores. Use these explicit thresholds:\n\n- `validation_status`: \n  - `none`: Work completed but not yet explicitly tested/verified.\n  - `passed`: Work explicitly validated via tests, manual confirmation, or peer review.\n  - `failed`: Work that failed verification or was found to be hallucinatory.\n- `trust_score` (Confidence):\n  - `0.0 - 0.2`: Suspected hallucination or failed validation.\n  - `0.3 - 0.5`: Unverified work, draft plans, or assumptions (Baseline for unverified work).\n  - `0.6 - 0.8`: Partially verified or low-risk routine changes.\n  - `0.9 - 1.0`: Rigorously verified via automated tests, peer review, or explicitly confirmed by the user.\n  - *Note: `trust_score` acts as a multiplier on the entry's importance. Low trust entries will decay and be auto-pruned faster.*\n- `impact_score` (Blast Radius):\n  - `0.0 - 0.2`: Trivial changes, typos, minor doc updates.\n  - `0.3 - 0.5`: Standard feature work, isolated bug fixes.\n  - `0.6 - 0.8`: Major new features, cross-module changes.\n  - `0.9 - 1.0`: Core architectural shifts, destructive operations, critical security patches.\n\n### Significance Marking\n\nMark important entries with `significance_type`:\n\n- `release` \u2014 Version deployments\n- `milestone` \u2014 Major completions (full certification, security audit, feature launch)\n- `decision` \u2014 Technology or process decisions\n- `architecture` \u2014 Architecture decisions, pattern adoptions, structural changes\n- `blocker_resolved` \u2014 Critical blockers that were resolved\n- `lesson_learned` \u2014 Documented lessons from failures or unexpected outcomes\n- `breakthrough` \u2014 Significant technical or conceptual breakthroughs\n- `security` \u2014 Security audit completions, vulnerability remediations, hardening milestones\n\nDo NOT mark routine session summaries or pass-only testing results as significant.\n\n### Link Entries\n\nCreate relationships to build traversable context chains:\n\n- `implements` \u2014 implementation\u2192spec, remediation\u2192audit findings\n- `resolved` \u2014 bugfix\u2192issue that reported the bug\n- `evolves_from` \u2014 v2\u2192v1, new iteration\u2192prior version\n- `references` \u2014 cross-project parity work, related entries\n- `clarifies` \u2014 documentation\u2192implementation it explains\n- `response_to` \u2014 reply to a question or issue raised in another entry\n- `blocked_by` \u2014 entry was blocked by another (blocker\u2192resolution)\n- `caused` \u2014 entry caused or led to another outcome\n\nOnly link truly related entries. Do NOT create bulk relationships between unrelated entries that happen to share tags.\n- **Opportunistic Superseding (Awake Contradiction Resolution)**: When creating a `project_decision`, `bug_fix`, or `technical_note` that invalidates or replaces an earlier entry surfaced in your briefing or search results, immediately link the new entry to the superseded entry via `evolves_from` or `resolved` so the knowledge graph reflects the superseding chain in real time.\n\n### Git Commit Standards\n\nWhen committing changes to a repository:\n\n- **Commit Journaling**: Record a corresponding `commit-narrative` journal entry containing `auto_context: { \"commits\": [\"<sha>\"] }` along with accurate heuristic scores (`impact_score`, `trust_score`, `validation_status`). If your workspace provides a `commit.ts` wrapper (e.g. `.agents/scripts/commit.ts`), append `--journal` to automate this step; otherwise use standard `git commit` and log the entry via `mj_execute_code`, `create_entry`, or `memory-journal-mcp entry create`.\n- **Scoring**: Provide accurate scores (`0.1-1.0`) for blast radius (`impact_score`) and verification level (`trust_score`). **NEVER \"rubber stamp\" 1.0** without rigorous validation; accurately reflect verification.\n- **Validation**: Provide `validation_status` (`passed`, `failed`, or `none`).\n\n## Available Tools\n\n- **Entry Lifecycle**: `create_entry`, `get_entry_by_id`, `get_recent_entries`, `get_entry_history`\n- **Taxonomy & Graph**: `list_tags`, `mark_anchors_stale`\n- **Testing Tools**: `test_simple`, `test_error_handling`, `trigger_progress`\n\n";
//# sourceMappingURL=core.d.ts.map