Go 项目不是按“类文件”组织，而是按 package 和 module 组织。今天先把这四个词钉稳。

go list 是今天的主命令。它让你从 Go 工具链视角看项目，而不是只看文件夹。

Day05 的小 CLI 可以先从扁平结构开始，今天把它拆成一个命令入口和一个内部业务包。

tasknote/
  go.mod
  cmd/
    tasknote/
      main.go
  internal/
    task/
      task.go
      format.go
      task_test.go
  README.md

先建目录，再移动文件。移动后要改 package 名、import path 和测试文件位置。

内部业务包示例：

package task

import "strings"

type Task struct {
  Title string
  Done  bool
}

func New(title string) (Task, error) {
  title = strings.TrimSpace(title)
  if title == "" {
    return Task{}, ErrEmptyTitle
  }
  return Task{Title: title}, nil
}

命令入口示例。把 import path 里的 module path 换成你自己的 go.mod 第一行。

package main

import (
  "fmt"
  "os"

  "example.com/tasknote/internal/task"
)

func main() {
  item, err := task.New(strings.Join(os.Args[1:], " "))
  if err != nil {
    fmt.Fprintln(os.Stderr, err)
    os.Exit(1)
  }
  fmt.Println(task.Format(item))
}

重构后先问 Go，不要先问编辑器。Go 工具链通过，Nvim 才有稳定基础。

现在回到 Nvim。目标不是“找到文件”，而是让每个目录、package、符号和引用在脑子里连起来。

vim.keymap.set("n", "<leader>ps", function()
  vim.lsp.buf.workspace_symbol(vim.fn.input("Symbol: "))
end, { desc = "Workspace symbol" })

internal/ 的意思是：只有它父目录树以内的代码能 import 它。它让“这是项目私有实现”变成工具链规则。

Go 的 package 名会出现在调用处，所以命名要短、具体、少重复。

今天的日志要回答一个问题：这个项目的边界在哪里？边界清楚，后面写测试、重构、调试都会轻很多。

# Day11 package and module boundary log

## Module
- module path:
- go list output:

## Layout
- command package:
- internal package:
- public package, if any:

## Import paths
- cmd imports:
- internal imports:
- external deps:

## Nvim map
- package declarations checked:
- workspace symbol tested:
- grep pattern used:

## Boundary decision
- what stays in internal:
- what can be public:
- one package name I improved: