oversized files: 7 source files exceed structural thresholds

[allenhutchison]

What

Architecture-audit nightly sweep flagged seven source files that exceed the structural size thresholds (700 lines for general source, 1000 for src/main.ts). Files this large tend to mix multiple responsibilities, make code review harder, and complicate diffs when small changes ripple across many concerns.

Evidence

Line counts as of master:

• src/main.ts — 1046 lines (threshold 1000)
• src/services/hook-manager.ts — 958 lines
• src/ui/agent-view/agent-view-messages.ts — 931 lines
• src/services/scheduled-task-manager.ts — 919 lines
• src/ui/agent-view/agent-view.ts — 904 lines
• src/ui/agent-view/agent-view-ui.ts — 894 lines
• src/ui/hook-management-modal.ts — 703 lines

Proposed unit of work

Each file is its own discrete unit of work — don't bundle. Suggested split strategies (to be confirmed during design):

• src/main.ts — keep the ObsidianGemini plugin class as the lifecycle entry point; extract the command-registration block to a new src/commands/register-commands.ts, and any inline ribbon/settings hooks that don't belong in lifecycle.
• src/services/hook-manager.ts — split into hook-manager.ts (registry + dispatch) and hook-runner.ts already exists; consider whether matcher/condition evaluation can move into its own hook-matcher.ts.
• src/ui/agent-view/agent-view-messages.ts — message rendering already has helpers in agent-view-tool-display.ts; consider extracting the tool-section parser (the Tool Execution Results: block detection) into a separate tool-section-parser.ts.
• src/services/scheduled-task-manager.ts — schedule parsing, missed-run detection, and execution dispatch could each live in their own module under src/services/scheduled-tasks/.
• src/ui/agent-view/agent-view.ts + agent-view-ui.ts — already broken up by concern (-messages, -send, -tools, -tool-display, etc.); audit which methods on the view class could move into one of the existing helpers, or warrant a new agent-view-projects.ts / agent-view-attachments.ts (if not already present).
• src/ui/hook-management-modal.ts — only 3 lines over threshold; lowest-priority split, may not be worth the diff.

File one sub-issue per file when picking up; this issue is a tracker, not a single PR target.

Out of scope

• Behavior changes. Each split should be a pure code-motion refactor with full test coverage maintained.
• Renames of public surface (anything in src/index.ts). Splits should preserve external imports via re-exports if needed.
• Changing the file-size threshold itself. If you disagree with 700 lines, file a separate discussion issue.

---

Filed by the architecture-audit skill. If this isn't worth doing, close with wontfix — the skill checks closed-with-wontfix and won't refile.

[coderabbitai]

🔗 Related PRs

#462 - refactor: Extract plugin initialization into LifecycleService [merged]
#472 - feat: Log tool execution summaries to session history [merged]
#489 - refactor: Move accessed files tracking to toolChainComplete subscriber [merged]
#491 - refactor: Extract event bus subscribers into dedicated files [merged]
#582 - Refactor: Extract tool display and follow-up from agent-view-tools.ts (#512) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[allenhutchison]

Before this can be planned for implementation, a few things need clarification:

1. This issue is a tracker — the body says "file one sub-issue per file when picking up; this issue is a tracker, not a single PR target." Should I file the 7 sub-issues now (one per oversized file, each with a concrete split strategy based on the suggestions in the body)? Doing so would let individual files enter the build queue one at a time. Or would you prefer to keep them bundled here and pick them up manually when ready?

---

Reply here and the next automation pass will pick it up, or add the auto:skip label to opt this issue out of automation.

---

Generated by Claude Code

[allenhutchison]

Filed sub-issues for the 4 files with clean extraction seams: #1070 (main.ts → commands package), #1071 (scheduled-task-manager → scheduled-tasks/ package), #1072 (agent-view-messages → tool-section-parser), #1073 (hook-manager → hook-matcher).

Holding agent-view.ts and agent-view-ui.ts — no obvious cut line yet ("audit which methods could move" risks a sprawling diff for little gain); better done by hand when a natural seam appears.

hook-management-modal.ts is only 3 lines over the guideline — not worth a dedicated refactor PR.

The 700-line threshold is a soft guideline; the goal here is splitting large files into readable packages, which the 4 filed sub-issues serve.