@taskset/cli 5.1.0 → 6.0.0

package/docs/task-files.md

@@ -1,16 +1,19 @@
 ---
-title: Task Files
+title: Understand Taskset task files
 description: The canonical Markdown representation for Taskset work items.
+contentType: Conceptual
+navLabel: Task Files
 ---
 
-# Task Files
+# Understand Taskset task files
 
-Task files live under `.taskset/tasks/`. YAML frontmatter owns structured
-metadata and the Markdown body owns durable human context.
+Tasks are the executable layer of Taskset. Use them to carry ownership, status, dependencies, and code impact for delivery work. Pair them with [stories, research, decisions, flows, and runbooks](document-types.md) when the surrounding memory should stay durable.
+
+Task files live under `.taskset/tasks/`. YAML frontmatter owns structured metadata. The Markdown body owns durable human context for that piece of execution.
 
 ```markdown
 ---
-id: 0000001-add-task-validation
+id: a1b2c3
 title: Add task validation
 status: doing
 priority: high
@@ -48,9 +51,10 @@ Explain why the task exists.
 ## Canonical Data
 
 Required fields are `id`, `title`, `status`, `createdAt`, and `updatedAt`.
-Task IDs are immutable seven-digit sequences plus a lowercase title slug, such
-as `0000001-add-task-validation`. The sequence prevents title collisions while
-the slug keeps filenames recognizable.
+Task IDs are immutable 5-6 character lowercase hex values, such as `a1b2c3`.
+Filenames keep a separate display sequence and title slug:
+`0000001-add-task-validation-a1b2c3.md`. Agents and commands reference the short
+`id`, never the mutable sequence prefix.
 
 Task files use one strict versionless metadata shape. Optional fields:
 
@@ -74,10 +78,12 @@ back to deterministic task ID ordering.
 
 ## Compatibility Cutover
 
-Legacy `TS-` ULIDs remain readable so a repository can migrate safely. Run
-`taskset task migrate-ids` once to atomically rename task files and rewrite all
-`dependsOn`, `related`, `duplicates`, and `parent` references. The command
-prints the old-to-new mapping for updating references outside `.taskset/`.
+Legacy `TS-` ULIDs and sequential `0000001-title` IDs remain readable so a
+repository can migrate safely. Run `taskset sync` or `taskset task migrate-ids`
+to atomically assign short hex IDs, normalize filenames to
+`{sequence}-{slug}-{id}.md`, repair duplicate sequence prefixes by `createdAt`,
+and rewrite relationships plus repository text references. The command prints
+the old-to-new mapping for any ID rewrites.
 
 Task metadata is versionless. Versioned task frontmatter is invalid input and
 fails with a schema diagnostic rather than being silently rewritten.
@@ -126,7 +132,7 @@ text, file, and directory filters. Numeric and timestamp ranges are inclusive:
 taskset task list --file packages/core --impact --json
 taskset task list --sort order
 taskset task list --estimate-min 30 --estimate-max 120 --risk high
-taskset task list --duplicate 0000001-add-task-validation
+taskset task list --duplicate a1b2c3
 ```
 
 Repeated enum, person, project, file, and directory values use OR within the

package/package.json

@@ -2,8 +2,8 @@
   "name": "@taskset/cli",
   "type": "module",
   "private": false,
-  "version": "5.1.0",
-  "description": "The scriptable command-line interface for Taskset.",
+  "version": "6.0.0",
+  "description": "CLI for Taskset: plan, research, decide, operate, and track repository work as Markdown.",
   "license": "MIT",
   "author": {
     "name": "junkieshuffle",
@@ -46,8 +46,8 @@
   },
   "dependencies": {
     "zod": "4.6.5",
-    "@taskset/contracts": "5.0.0",
-    "@taskset/core": "5.0.0"
+    "@taskset/contracts": "6.0.0",
+    "@taskset/core": "6.0.0"
   },
   "devDependencies": {
     "@types/node": "^26.6.3",

package/skills/taskset/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: taskset
-description: Taskset workflow guidance for agents that plan and track work with tasks, stories, user flows, decisions, research, and runbooks stored in .taskset/, including batch imports and cross-package monorepo work. While executing work, agents must create follow-up tasks or subtasks (Taskset child tasks or body checklist items) for newly discovered work, keep parent and subtask progress current mid-work, mark every finished subtask done or checked, create Taskset documents (research, decision, runbook, story, or flow) when work produces reusable evidence, lasting choices, or procedures, link them with --related, and update the session or repository primary skill when lasting lessons should prevent future failures.
+description: Taskset workflow guidance for agents that plan, research, decide, operate, and track delivery with stories, flows, research, decisions, runbooks, and tasks stored in .taskset/, including batch imports and cross-package monorepo work. While executing work, agents must create follow-up tasks or subtasks (Taskset child tasks or body checklist items) for newly discovered work, keep parent and subtask progress current mid-work, mark every finished subtask done or checked, create Taskset documents (research, decision, runbook, story, or flow) when work produces reusable evidence, lasting choices, or procedures, link them with --related, and update the session or repository primary skill when lasting lessons should prevent future failures.
 ---
 
 # Taskset
 
-Use this skill when working in a repository that uses Taskset to store work as human-readable Markdown beside the code.
+Use this skill when working in a repository that uses Taskset to store plans, research, decisions, runbooks, and executable tasks as human-readable Markdown beside the code. Tasks move delivery. Documents preserve the memory that makes delivery coherent.
 
 ## Packaged Docs And Skills
 
@@ -18,7 +18,8 @@ treat those paths as the detailed offline reference set:
 | `node_modules/@taskset/cli/skills/taskset/SKILL.md` | This skill (agent workflow for tasks and documents) |
 | `node_modules/@taskset/cli/skills/taskset/references/` | Task modeling, document modeling, monorepo, and Changesets examples |
 | `node_modules/@taskset/cli/skills/taskset-implement/` | Engineering standards used while developing Taskset itself |
-| `node_modules/@taskset/cli/docs/` | User docs: getting started, configuration, CLI reference, task files, document types |
+| `node_modules/@taskset/cli/docs/` | Human docs: getting started, configuration, CLI reference, task files, document types |
+| `node_modules/@taskset/cli/docs/agents/` | Agent docs: workflows, command contracts, discovery index |
 | `node_modules/@taskset/cli/docs/maintainers/` | Architecture, ADRs, testing, and maintainer workflows |
 
 In the Taskset repository itself, prefer the workspace copies at `skills/` and
@@ -43,10 +44,15 @@ package root.
 
 - Treat `.taskset/tasks/` as the canonical task source of truth and the sibling
   document-kind directories as the canonical durable project-document source.
-- Treat `taskset.config.ts` as the repository entrypoint for Taskset behavior and defaults.
+- Treat the nearest `.taskset/` directory as the repository marker. Optional
+  `taskset.config.ts` at that root overlays defaults; built-in defaults apply
+  when it is absent.
 - Do not create a second task store, hidden database, or alternate sync layer.
 - Use Taskset commands to inspect and mutate tasks instead of editing canonical task files by hand when a command exists.
-- Prefer `pnpm taskset` in project repositories; use the repo root `pnpm taskset` script when available.
+- Invoke Taskset with whatever runner the environment provides:
+  `npx @taskset/cli`, `pnpm dlx @taskset/cli`, `yarn dlx @taskset/cli`,
+  `bunx @taskset/cli`, `pnpm exec taskset`, or a global `taskset` binary. Do not
+  require `pnpm taskset`.
 - While executing or working a task, agents MUST create follow-up Taskset tasks or subtasks for newly discovered work. In this skill, "subtask" means either a Taskset child task (`--parent`) or a Markdown checklist item (`- [ ]`) in the parent task body—choose child tasks when independent status, ownership, dependencies, or history are needed; otherwise prefer checklist items. Do not leave that work only in chat, memory, or an informal note.
 - Agents MUST keep the parent task status and every subtask current mid-work: set Taskset tasks and child tasks to `doing` when work starts, check off completed checklist items as `- [x]`, update statuses when progress or blockers change, and mark each finished child task `done` when its acceptance criteria are met. Do not leave finished checklist items unchecked or finished child tasks open, and do not mark a parent task `done` while any tracked subtask (child task or checklist item) remains unfinished.
 - While executing a task, agents MUST create a Taskset document in the same change when work produces reusable evidence (`research`), a lasting choice (`decision` / `adr`), an operational procedure (`runbook`), or durable product context (`story` / `flow`). Link the document and originating task with `--related`. Do not leave that material only in chat, memory, or a closed task body. Short scratch notes and one-off checklist steps stay in the task body.
@@ -54,8 +60,8 @@ package root.
 
 ## Recommended Workflow
 
-1. Confirm the repository root and Taskset config.
-2. Inspect repository health with `taskset config --json` and `taskset doctor`.
+1. Confirm the repository root with `taskset config --json` (look for `.taskset/`, not a required config file).
+2. Inspect repository health with `taskset doctor --json`.
 3. List or show tasks and check their owner and assignees before changing or executing them.
 4. Resolve whether the current Git user is authorized to take the selected task; obtain confirmation when another person is responsible and the request does not already authorize that specific takeover.
 5. Create, update, execute, or close tasks with Taskset commands.
@@ -75,24 +81,24 @@ For ownership-gate scenarios, read [owner and assignee examples](references/task
 ## Common Commands
 
 ```bash
-pnpm taskset config --json
-pnpm taskset doctor
-pnpm taskset task list
-pnpm taskset task show <task-id>
-pnpm taskset task create --title "Describe the work"
-pnpm taskset task update <task-id> --status doing
-pnpm taskset task status <task-id> done
-pnpm taskset task delete <task-id>
-pnpm taskset task list --search "multiple terms"
-pnpm taskset task list --file packages/core --impact
-pnpm taskset document create story --title "Describe the user outcome"
-pnpm taskset document create research --title "Evaluate options" --related <task-id>
-pnpm taskset document update <document-id> --status ready --type research
-pnpm taskset document list research --search "queue" --impact
-pnpm taskset document show <document-id> --type research --include-derived --json
-pnpm taskset document import docs/adr/0001-example.md --type adr --move
-pnpm taskset document batch taskset-documents.json --concurrency 4 --json
-pnpm taskset sync
+taskset config --json
+taskset doctor --json
+taskset task list --json
+taskset task show your_task_id_here --json
+taskset task create --title "Describe the work"
+taskset task update your_task_id_here --status doing
+taskset task status your_task_id_here done
+taskset task delete your_task_id_here
+taskset task list --search "multiple terms" --json
+taskset task list --file packages/core --impact --json
+taskset document create story --title "Describe the user outcome"
+taskset document create research --title "Evaluate options" --related your_task_id_here
+taskset document update your_document_id_here --status ready --type research
+taskset document list research --search "queue" --impact --json
+taskset document show your_document_id_here --type research --include-derived --json
+taskset document import docs/adr/0001-example.md --type adr --move
+taskset document batch taskset-documents.json --concurrency 4 --json
+taskset sync --json
 ```
 
 ## Practical Guidance
@@ -123,14 +129,18 @@ pnpm taskset sync
 - Use `document batch <manifest.json>` for repeatable multi-document create,
   import, update, and export jobs. Progress belongs on stderr and `--json`
   output on stdout. Use `sync` after upgrades to ensure canonical directories,
-  migrate legacy IDs and repository text references, refresh data `.gitignore`
-  patterns for scoped `.generated/` directories, and rebuild views.
+  migrate legacy IDs to short hex IDs, normalize filenames, repair duplicate
+  sequence prefixes, rewrite repository text references, refresh data
+  `.gitignore` patterns for scoped `.generated/` directories, and rebuild views.
 - Disposable metadata indexes live beside each entity folder
   (`.taskset/tasks/.generated/`, `.taskset/stories/.generated/`, and the other
   document-kind folders), not under a global `.taskset/generated/`.
-- New task and document IDs use `0000001-short-title` naming. Use
-  `task migrate-ids` for legacy task repositories; do not rename task files by
-  hand because canonical relationships must be rewritten together.
+- New task and document IDs are immutable 5-6 character lowercase hex values
+  such as `a1b2c3`. Filenames use `{sequence}-{slug}-{id}.md`. Agents MUST
+  reference the short `id` in commands, relationships, and handoffs—never the
+  mutable filename sequence prefix. Use `sync` or `task migrate-ids` for legacy
+  repositories; do not rename entity files by hand because canonical
+  relationships must be rewritten together.
 - When a task change affects repository behavior, follow up with the relevant tests, docs, and `git diff --check`.
 
 ## Task Modeling
@@ -223,5 +233,8 @@ For paired examples of required, multi-package, and unnecessary changesets, read
 - In monorepos, verify affected packages and consumers against the workspace and task-runner graphs rather than relying only on the initially named directory.
 - In repositories using Changesets, reconcile the task's declared Changeset requirement with the actual affected packages before completion.
 - Prefer the smallest Taskset command that proves the intended state.
+- Cite tasks and documents by their short hex `id` (`a1b2c3`), not by filename
+  sequence numbers. Use that `id` with `task show`, `task update`, `--related`,
+  `--depends-on`, and `--parent`.
 - Avoid editing generated output, caches, or any non-canonical `.taskset/` artifacts.
 - Report validation failures plainly and only claim success after the command has run.

package/skills/taskset-implement/SKILL.md

@@ -85,9 +85,9 @@ listed in Preserve Product Invariants, the invariant takes precedence. Explain
 the conflict to the user and request an explicit override with rationale before
 proceeding.
 
-The repository is currently an early scaffold. Do not turn accidental manifest
-mistakes, empty packages, or placeholder dependencies into conventions. Report
-them and follow the intended `@taskset/<directory-name>` ownership model.
+Do not turn accidental manifest mistakes, empty packages, or placeholder
+dependencies into conventions. Report them and follow the intended
+`@taskset/<directory-name>` ownership model.
 
 ## Preserve Product Invariants
 
@@ -126,20 +126,26 @@ Non-negotiable rules:
 - Document mutations, imports, exports, and batches belong to core. The CLI
   validates manifests and renders output only. Use TanStack Pacer for bounded
   heavy batches and migrations, emit count and percentage progress, preserve
-  manifest result order, and serialize writes that allocate sequential IDs.
+  manifest result order, and serialize writes that allocate short hex IDs plus
+  filename display sequences.
 - Disposable metadata indexes live in each entity folder's `.generated/`
   directory (for example `.taskset/tasks/.generated/` and
   `.taskset/research/.generated/`), not a global `.taskset/generated/` tree.
 - Repository sync is the maintenance entrypoint: ensure canonical `.taskset/`
-  directories, migrate task IDs and repository text references atomically,
+  directories, migrate task and document IDs to immutable short hex IDs,
+  normalize `{sequence}-{slug}-{id}.md` filenames, repair duplicate sequence
+  prefixes by `createdAt`, rewrite repository text references atomically,
   refresh data `.gitignore` rules for scoped generated output, remove legacy
   global generated directories, then rebuild disposable generated views.
-- `taskset.config.ts` marks the repository root and configures validated project
-  metadata and task creation defaults. It never relocates canonical
-  `.taskset/` data or becomes a second task store.
-- Taskset is developed using its own root config, CLI, and canonical task
-  files. Keep that dogfooding workflow operational when changing core, CLI,
-  workspace commands, or persisted contracts.
+- The nearest `.taskset/` directory marks the repository root. Optional
+  `taskset.config.ts` at that root configures validated project metadata and
+  task creation defaults. Missing config uses built-in defaults. Config never
+  relocates canonical `.taskset/` data or becomes a second task store.
+- Taskset is developed using its own `.taskset/` data, optional root config,
+  CLI, and canonical task files. Keep that dogfooding workflow operational when
+  changing core, CLI, workspace commands, or persisted contracts.
+- Public docs split three audiences: humans (`docs/`), agents (`docs/agents/`
+  plus `skills/` and root `AGENTS.md`), and maintainers (`docs/maintainers/`).
 
 ## Organize by Ownership
 

package/skills/taskset-implement/references/architecture/documentation-and-generated.md

@@ -31,7 +31,9 @@ Recommended website stack:
 Register blog posts in the app-local post registry so static export can
 enumerate `/posts/[slug]`. Keep blog posts in plain Markdown by default with
 `title`, `description`, and `date` frontmatter. Do not merge docs and blog theme
-wrappers in the global MDX component map.
+wrappers in the global MDX component map. Agent operating pages live under
+`docs/agents/` and appear in usage navigation; maintainer pages stay under
+`/maintainers`.
 
 Keep architectural decisions under
 `docs/maintainers/architecture/decisions/`.

package/skills/taskset-implement/references/architecture/ownership-and-dependencies.md

@@ -39,7 +39,8 @@ surfaces such as package names, the CLI command, `taskset.config.ts`, and
 `.taskset/`.
 
 Taskset dogfoods these boundaries. The root workspace installs core and CLI,
-loads `taskset.config.ts`, and stores its own planned work in `.taskset/tasks/`.
+may load optional `taskset.config.ts`, and stores its own planned work in
+`.taskset/tasks/`.
 
 ## Dependency Flow
 

package/skills/taskset-implement/references/architecture/product-and-source.md

@@ -4,13 +4,12 @@ Product direction and the canonical source-of-truth model.
 
 ## Product Direction
 
-Taskset began as an offline, inline, AI-friendly, human-readable task manager
-designed to accelerate software delivery and give development teams immediate
-awareness of the work surrounding their code.
+Taskset began as an offline, inline, AI-friendly, human-readable delivery
+workspace: not only tasks, but the plans, research, decisions, flows, and
+runbooks that make delivery coherent.
 
-It grows from that core into a Git-native software delivery platform. Tasks,
-stories, flows, decisions, research, runbooks, and related project knowledge
-live beside the code as human-readable Markdown.
+It is a Git-native software delivery platform. Stories, flows, decisions,
+research, runbooks, and tasks live beside the code as human-readable Markdown.
 
 Vision: become the Git-native operating system for software delivery.
 
@@ -58,8 +57,10 @@ Canonical project state lives under `.taskset/`.
 Rules:
 
 - Entity Markdown files are authoritative persisted state.
-- `taskset.config.ts` is the discoverable repository usage configuration. It
-  controls validated behavior and defaults, not canonical entity state.
+- The nearest `.taskset/` directory is the discoverable repository marker.
+  Optional `taskset.config.ts` at that root overlays validated behavior and
+  defaults. Missing config uses built-in defaults. Config never owns entity
+  state.
 - YAML frontmatter contains structured metadata. Markdown bodies contain
   durable human context.
 - Do not store the same field independently in frontmatter and body.
@@ -73,8 +74,8 @@ Rules:
   state, or another hidden store as an undeclared authority.
 - Git is the versioning and collaboration layer around the files. Do not assume
   it provides database transactions or conflict-free identifiers.
-- Repository discovery walks upward for exactly `taskset.config.ts`; canonical
-  storage remains fixed under `.taskset/`.
+- Repository discovery walks upward for `.taskset/`; canonical storage remains
+  fixed under that directory.
 
 Any persisted format change must define validation, compatibility, migration,
 and failure behavior before implementation.

package/skills/taskset-implement/references/architecture/storage-and-snapshots.md

@@ -9,8 +9,8 @@ Storage, graph, and snapshot rules for canonical repository data.
   expressions.
 - Normalize stored code references to repository-relative POSIX paths.
 - Reject paths that escape the repository or `.taskset/` ownership boundary.
-- Keep IDs immutable. Do not adopt sequential IDs without a documented
-  branch-collision strategy.
+- Keep entity IDs immutable short hex values. Filename display sequences are
+  mutable maintenance metadata repaired by `sync`; they are not identity.
 - Store one canonical direction for inverse relationships unless the schema
   explicitly defines otherwise. Derive `blocks` from `dependsOn`, for example,
   rather than allowing silent divergence.

package/skills/taskset-implement/references/conventions/naming-and-packages.md

@@ -55,7 +55,7 @@ taskset task list --file packages/core --impact
 taskset context-bundle
 ```
 
-The root usage configuration is exactly `taskset.config.ts`. Export a
+Optional root usage configuration is exactly `taskset.config.ts`. Export a
 versionless object, preferably through `defineConfig` from `@taskset/core`.
 Keep configuration fields behavioral; never use config to redirect canonical
 entity storage outside `.taskset/`.

package/skills/taskset-implement/references/conventions/task-files.md

@@ -8,7 +8,7 @@ Use YAML frontmatter for machine metadata and Markdown for human context:
 
 ```markdown
 ---
-id: 0000001-add-task-validation
+id: a1b2c3
 title: Add task validation
 status: doing
 priority: high
@@ -31,6 +31,8 @@ Describe why the work exists.
 - [ ] Invalid statuses produce an actionable diagnostic.
 ```
 
+Filename: `0000001-add-task-validation-a1b2c3.md`
+
 Rules:
 
 - Require `id`, `title`, `status`, `createdAt`, and `updatedAt`.
@@ -53,9 +55,12 @@ Rules:
   reading the documented legacy ISO 8601 UTC form until a compatibility change
   explicitly removes it.
 - Keep IDs immutable and compare them exactly.
-- Format new task IDs as a seven-digit sequence plus a lowercase title slug.
-  Keep legacy `TS-` ULIDs readable only so `task migrate-ids` can rewrite them
-  and all canonical relationships atomically.
+- Format new task and document IDs as 5-6 character lowercase hex values.
+  Store display order in the filename as `{sequence}-{slug}-{id}.md`. Keep
+  legacy `TS-` ULIDs and sequential `0000001-title` IDs readable only so
+  `sync` / `task migrate-ids` can rewrite them, normalize filenames, repair
+  duplicate sequence prefixes by `createdAt`, and update canonical
+  relationships atomically.
 - Preserve user-authored body text and meaningful list order.
 - Use stable key ordering and one final newline in generated output.
 - Generated metadata indexes cover supported non-ID metadata fields, group

package/skills/taskset-implement/references/workflows/environment-and-pnpm.md

@@ -96,9 +96,10 @@ must remain available. Root-only architecture tests run once after Turbo rather
 than being duplicated inside every package. There is no `transit` script;
 Turbo's dependency traversal is orchestration, not another test suite.
 
-`taskset.config.ts` is loaded as trusted project code using Node's native
-erasable TypeScript support. Keep it free of syntax that requires TypeScript
-code generation.
+Optional `taskset.config.ts` is loaded as trusted project code using Node's
+native erasable TypeScript support when present. Keep it free of syntax that
+requires TypeScript code generation. Repository discovery uses `.taskset/`, not
+the config file.
 
 If Turbo reports duplicate workspace names, fix the incorrect package manifest.
 Do not work around the graph with directory filters or aliases.

package/src/cli.ts

@@ -60,7 +60,7 @@ import {
 import * as z from 'zod'
 
 const USAGE = `Usage:
-  taskset init [--cwd <path>]
+  taskset init [--config] [--cwd <path>]
   taskset config [--json] [--cwd <path>]
   taskset doctor [--json] [--cwd <path>]
   taskset generate [--json] [--cwd <path>]
@@ -139,6 +139,11 @@ const CommonValuesSchema = z.strictObject({
 	json: JsonSchema,
 })
 
+const InitValuesSchema = z.strictObject({
+	cwd: CwdSchema,
+	config: z.boolean().optional(),
+})
+
 const ConcurrencySchema = z.coerce.number().int().min(1).max(32).optional()
 const DocumentKindInputSchema = TrimmedStringSchema.transform((value, context) => {
 	try {
@@ -866,6 +871,24 @@ export async function runCli(args: readonly string[], context: CliContext = {}):
 		}
 
 		if (command === 'init' || command === 'config' || command === 'doctor') {
+			if (command === 'init') {
+				const parsed = parseArgs({
+					args: commandArgs,
+					allowPositionals: false,
+					options: {
+						cwd: { type: 'string' },
+						config: { type: 'boolean' },
+					},
+				})
+				const values = parseSchema(InitValuesSchema, parsed.values, 'init options')
+				const commandCwd = resolveCommandCwd(cwd, values.cwd)
+				const repository = await initializeRepository(commandCwd, {
+					writeConfig: values.config === true,
+				})
+				stdout(`Initialized Taskset in ${repository.rootDirectory}\n`)
+				return 0
+			}
+
 			const parsed = parseArgs({
 				args: commandArgs,
 				allowPositionals: false,
@@ -873,13 +896,6 @@ export async function runCli(args: readonly string[], context: CliContext = {}):
 			})
 			const values = parseSchema(CommonValuesSchema, parsed.values, `${command} options`)
 			const commandCwd = resolveCommandCwd(cwd, values.cwd)
-
-			if (command === 'init') {
-				const repository = await initializeRepository(commandCwd)
-				stdout(`Initialized Taskset in ${repository.rootDirectory}\n`)
-				return 0
-			}
-
 			const repository = await discoverRepository(commandCwd)
 
 			if (command === 'config') {
@@ -889,6 +905,7 @@ export async function runCli(args: readonly string[], context: CliContext = {}):
 							{
 								rootDirectory: repository.rootDirectory,
 								configPath: repository.configPath,
+								hasConfig: repository.hasConfig,
 								dataDirectory: repository.dataDirectory,
 								config: repository.config,
 							},
@@ -896,8 +913,10 @@ export async function runCli(args: readonly string[], context: CliContext = {}):
 							2,
 						)}\n`,
 					)
-				} else {
+				} else if (repository.hasConfig) {
 					stdout(`${repository.configPath}\n`)
+				} else {
+					stdout(`defaults (${repository.rootDirectory})\n`)
 				}
 				return 0
 			}
@@ -958,7 +977,7 @@ export async function runCli(args: readonly string[], context: CliContext = {}):
 			stdout(
 				values.json
 					? `${JSON.stringify(result, null, 2)}\n`
-					: `Synced ${result.migrations.length} migrations and generated views\n`,
+					: `Synced ${result.migrations.length + result.documentMigrations.length} migrations and generated views\n`,
 			)
 			return 0
 		}