chore: initialize qiming workspace repository

qimingcode/specs/project.md

@@ -0,0 +1,64 @@
+## project
+
+The goal is to let a single instance of OpenCode run sessions for multiple projects and different worktrees per project.
+
+### api
+
+```
+GET /project -> Project[]
+
+POST /project/init -> Project
+
+
+GET /project/:projectID/session -> Session[]
+
+GET /project/:projectID/session/:sessionID -> Session
+
+POST /project/:projectID/session -> Session
+{
+  id?: string
+  parentID?: string
+  directory: string
+}
+
+DELETE /project/:projectID/session/:sessionID
+
+POST /project/:projectID/session/:sessionID/init
+
+POST /project/:projectID/session/:sessionID/abort
+
+POST /project/:projectID/session/:sessionID/share
+
+DELETE /project/:projectID/session/:sessionID/share
+
+POST /project/:projectID/session/:sessionID/compact
+
+GET /project/:projectID/session/:sessionID/message -> { info: Message, parts: Part[] }[]
+
+GET /project/:projectID/session/:sessionID/message/:messageID -> { info: Message, parts: Part[] }
+
+POST /project/:projectID/session/:sessionID/message -> { info: Message, parts: Part[] }
+
+POST /project/:projectID/session/:sessionID/revert -> Session
+
+POST /project/:projectID/session/:sessionID/unrevert -> Session
+
+POST /project/:projectID/session/:sessionID/permission/:permissionID -> Session
+
+GET /project/:projectID/session/:sessionID/find/file -> string[]
+
+GET /project/:projectID/session/:sessionID/file -> { type: "raw" | "patch", content: string }
+
+GET /project/:projectID/session/:sessionID/file/status -> File[]
+
+POST /log
+
+// These are awkward
+
+GET /provider?directory=<resolve path> -> Provider
+GET /config?directory=<resolve path> -> Config // think only tui uses this?
+
+GET /project/:projectID/agent?directory=<resolve path> -> Agent
+GET /project/:projectID/find/file?directory=<resolve path> -> File
+
+```

qimingcode/specs/v2/session.md

@@ -0,0 +1,17 @@
+# Session API
+
+## Remove Dedicated `session.init` Route
+
+The dedicated `POST /session/:sessionID/init` endpoint exists only as a compatibility wrapper around the normal `/init` command flow.
+
+Current behavior:
+
+- the route calls `SessionPrompt.command(...)`
+- it sends `Command.Default.INIT`
+- it does not provide distinct session-core behavior beyond running the existing init command in an existing session
+
+V2 plan:
+
+- remove the dedicated `session.init` endpoint
+- rely on the normal `/init` command flow instead
+- avoid reintroducing `Session.initialize`-style special cases in the session service layer