opkg 0.6.1 → 0.7.0

package/specs/save/save-conflict-resolution.md

@@ -2,145 +2,267 @@
 
 #### 1. Overview
 
-When multiple candidates exist for the same registry path, the pipeline must decide which content to use. This document describes the conflict resolution rules.
+When multiple workspace candidates exist for the same registry path, the pipeline must decide which content to save. This document describes the conflict resolution rules for the **workspace → source** save flow.
 
 ---
 
-#### 2. Resolution Goals
+#### 2. Single-Direction Principle
 
-For each group, the pipeline decides:
+Save is a **unidirectional** operation: workspace content overwrites source content. There is no comparison or "merging" with existing source files. The only conflicts that need resolution are:
 
-- Whether any action is needed (no-op when everything matches).
-- Which content becomes the **universal** package content for that registry path.
-- Which workspace candidates, if any, should be treated as **platform‑specific** sidecars.
+1. **Multiple workspace files mapping to the same registry path**
+2. **Platform-specific vs. universal content selection**
+
+The source file is only used for **optimization** (skip writes when content is identical) and **parity checking** (skip prompts when workspace matches source).
 
 ---
 
-#### 3. Conflict Types
+#### 3. Resolution Goals
 
-There are two main flavors of groups:
+For each group where multiple workspace candidates exist, the pipeline decides:
 
-1. **Root conflicts** (root documentation file for the package)
-2. **Regular conflicts** (all other paths)
+- Which workspace candidate becomes the **universal** package content
+- Which workspace candidates should be saved as **platform-specific** variants
+- Which candidates should be skipped (already at parity or user choice)
 
 ---
 
-#### 4. Root Conflicts
+#### 4. Parity Checking
+
+Before prompting, the pipeline checks if workspace files are already at parity with source:
 
-For the root package section file (e.g. the unified agents document):
+##### Universal Parity
+A workspace file is at **universal parity** if its content hash matches the universal source file.
 
-##### Ordering and deduplication
+##### Platform-Specific Parity
+A workspace file is at **platform-specific parity** if:
+- It has a platform association (e.g., `cursor`, `claude`)
+- Its content hash matches the corresponding platform-specific source file (e.g., `commands.cursor.md`)
 
-- The pipeline orders candidates roughly by:
-  - Existing local content first (if any).
-  - Workspace candidates by newest modification time, then by display path.
-- Deduplicates candidates by content hash.
+##### Auto-Skipping
+Files at parity are automatically skipped with a clear message:
+- "Already matches universal - auto-skipping"
+- "Already matches platform-specific file - auto-skipping"
 
-##### Single candidate
+This eliminates unnecessary prompts when files are already up-to-date.
 
-- If there is exactly one unique candidate:
-  - That candidate is used as the universal content for the root file.
+---
 
-##### Multiple differing candidates
+#### 5. Conflict Types
 
-- If the local candidate is newer than or equal to all workspace candidates:
-  - The local candidate is selected automatically.
-- Otherwise:
-  - With `--force`:
-    - The local candidate always wins.
-  - Without `--force`:
-    - The user is prompted to choose which candidate should become the universal root content.
+##### No Workspace Candidates
+- No action needed
+- Group is skipped entirely
 
-##### Output
+##### Single Workspace Candidate
+- **If matches source (parity)**: Auto-skip (no write needed)
+- **If differs from source**: Write to source automatically (no prompt)
 
-- The chosen root content is written into the package's root file location.
-- Platform‑specific root selections (e.g. separate root files for individual platforms) are persisted as separate package files where appropriate.
+##### Multiple Identical Workspace Candidates (Same Content Hash)
+- **If all match source (parity)**: Auto-skip all
+- **If differ from source**: Pick newest by mtime, write to source (no prompt)
+
+##### Multiple Differing Workspace Candidates
+- **With `--force` flag:**
+  - Auto-select newest by mtime (alphabetical tie-breaker if mtimes equal)
+  - Skip others
+  - No prompts
+- **Without `--force`:**
+  - Interactive resolution (see below)
 
 ---
 
-#### 5. Regular Conflicts
+#### 6. Interactive Resolution Flow
 
-For non‑root paths:
+When multiple differing workspace candidates exist, the user is prompted **once per file** in a single-step process:
 
-##### Ordering and deduplication
+##### Step 1: Parity Filtering
+For each candidate (ordered by mtime, newest first):
+- Check universal parity → Auto-skip if matches
+- Check platform-specific parity → Auto-skip if matches
+- Continue to prompt if not at parity
 
-- The pipeline again orders and deduplicates candidates.
-- Checks whether any workspace candidate actually **differs** from the local candidate.
+##### Step 2: Per-File Prompts
+For each remaining candidate:
 
-##### No local candidate
+**Before universal selected:**
+- Options: `[Set as universal]` `[Mark as platform-specific]` `[Skip]`
 
-- If the file does not yet exist in the package:
-  - The selected workspace candidate becomes the new file content.
+**After universal selected:**
+- Check if identical to selected universal → Auto-skip if matches
+- Options: `[Mark as platform-specific]` `[Skip]`
 
-##### Identical content
+##### Step 3: Resolution
+After all prompts:
+- **Universal selected**: Write to `<registry-path>`
+- **Platform-specific marked**: Write to `<registry-path>.<platform>.<ext>`
+- **Skipped**: No action (neither written)
+- **No universal selected**: Original universal file remains untouched, only platform-specific files written
 
-- If local and all workspace candidates have identical content:
-  - The group is skipped (no changes).
+---
 
-##### Differences with local candidate
+#### 7. Resolution Principles
 
-When there are differences and a local candidate exists:
+The save flow ensures:
 
-- If the local candidate is newer or as new as any workspace candidate:
-  - The local version wins silently (no prompt).
-- If a newer workspace candidate exists:
-  - Without `--force`:
-    - The user is prompted to choose which candidate should become universal content.
-  - With `--force`:
-    - The local candidate wins even if workspace content is newer.
+1. **Workspace always wins**: Source content is overwritten by workspace selections
+2. **Smart filtering**: Files at parity are auto-skipped (no unnecessary prompts)
+3. **Progressive disclosure**: Options simplify after universal is selected
+4. **No data loss**: Skipped files remain in workspace, can be saved later
+5. **Platform-aware**: Respects both universal and platform-specific parity
+6. **User control**: User can skip individual files or mark as platform-specific
 
 ---
 
-#### 6. Resolution Principles
+#### 8. Force Mode Behavior
+
+With `--force` flag:
+- Auto-selects newest workspace file by mtime
+- **Tie-breaking**: If multiple files have same mtime, selects first alphabetically
+- No prompts (fully automated)
+- Transparent logging of selections and skipped files
+- Does NOT auto-create platform-specific variants (only universal)
+
+Example force mode output:
+```
+ℹ Force mode: Auto-selecting newest (.cursor/commands/test.md)
+  Skipping: .claude/commands/test.md (older)
+  Skipping: .opencode/commands/test.md (older)
+
+✓ Saved my-pkg
+  Updated: commands/test.md
+```
+
+Example with tie-breaking:
+```
+ℹ Force mode: Multiple files have same modification time (1/15/2024 10:30 AM)
+  Auto-selecting first alphabetically: .claude/commands/test.md
+  Tied files:
+    → .claude/commands/test.md
+      .cursor/commands/test.md
+  Skipping: .cursor/commands/test.md (tied, not alphabetically first)
+
+💡 Tip: If this wasn't the file you wanted, run without --force
+```
+
+---
+
+#### 9. Edge Cases
+
+##### No Universal Selected
+If user skips all candidates or marks all as platform-specific:
+- Original universal file remains **untouched**
+- Only platform-specific files are written
+- No confirmation prompt needed
 
-In all cases, the goal is to:
+##### All Files Skipped
+If user skips all files (or all are at parity):
+- No changes made
+- No confirmation prompt needed
+- Message: "No changes to `<path>`"
 
-- Prefer local content when it is at least as new as workspace content.
-- Ask the user only when a newer workspace change would override local content.
-- Respect an explicit `--force` override in favor of local content.
+##### All Files at Parity
+If all workspace files match source:
+- All auto-skipped with clear messages
+- No prompts shown
+- Message: "No changes needed"
 
 ---
 
-#### 7. Platform‑Specific Selection
+#### 10. Example Scenarios
 
-Some workspace candidates are associated with specific platforms (e.g. platform‑specific variants of a shared file).
+##### Scenario A: Mixed Parity
+```
+Workspace:
+  .cursor/commands/test.md   (hash: abc123) ← Matches universal
+  .claude/commands/test.md   (hash: def456) ← Different!
 
-##### Marking platform-specific candidates
+Source:
+  commands/test.md           (hash: abc123)
 
-- Before choosing the universal content, the user can be offered a chance to:
-  - Mark one or more workspace candidates as **platform‑specific**.
-  - These marked candidates will be written to platform‑specific registry paths instead of becoming the universal content.
+Interactive flow:
+  ✓ .cursor/commands/test.md
+    Already matches universal - auto-skipping
 
-##### After marking
+  .claude/commands/test.md (claude) [1/14/2024]
+  What should we do with this file?
+  > Mark as platform-specific
 
-- The remaining candidates (local + unmarked workspace candidates) participate in universal conflict resolution as described above.
-- Marked candidates are saved as platform‑specific sidecars if they are not chosen as the universal content.
+Result:
+  Created: commands.claude.md (platform-specific)
+```
 
-##### Use case
+##### Scenario B: Platform-Specific at Parity
+```
+Workspace:
+  .cursor/commands/test.md   (hash: abc123) ← Different from universal
+  .claude/commands/test.md   (hash: def456) ← Matches platform file!
 
-This mechanism lets a user:
+Source:
+  commands/test.md           (hash: xyz789)
+  commands.claude.md         (hash: def456) ← Matches!
 
-- Keep a single universal file.
-- Simultaneously maintain richer, platform‑specific versions where needed.
+Interactive flow:
+  .cursor/commands/test.md (cursor) [1/15/2024]
+  What should we do with this file?
+  > Set as universal
+
+  ✓ .claude/commands/test.md
+    Already matches platform-specific file - auto-skipping
+
+Result:
+  Updated: commands/test.md (from cursor)
+```
+
+##### Scenario C: One Edited, Others at Parity
+```
+Workspace:
+  .cursor/commands/test.md   (hash: NEW123) ← User just edited
+  .claude/commands/test.md   (hash: abc123) ← At parity
+  .opencode/commands/test.md (hash: abc123) ← At parity
+
+Source:
+  commands/test.md           (hash: abc123)
+
+Interactive flow:
+  .cursor/commands/test.md (cursor) [1/15/2024 10:35 AM]
+  What should we do with this file?
+  > Set as universal
+
+  ✓ .claude/commands/test.md
+    Already matches universal - auto-skipping
+  ✓ .opencode/commands/test.md
+    Already matches universal - auto-skipping
+
+Result:
+  Updated: commands/test.md (from cursor)
+```
 
 ---
 
-#### 8. Escalation from YAML Overrides to Full Platform Markdown
+#### 11. Removed Behaviors
 
-When a registry path participates in the frontmatter/YAML override pipeline (e.g. `.openpackage/agents/*.md`) **and** the user marks one or more workspace candidates as platform‑specific during conflict resolution:
+The following behaviors have been removed as they conflicted with single-direction flow:
 
-- **Universal body update**
-  - The universal markdown file keeps its existing frontmatter.
-  - If the selected universal candidate’s body differs, only the **markdown body** is updated.
-  - Frontmatter for that path continues to be managed by the YAML override pipeline.
+- ❌ Comparing workspace mtime against source mtime for resolution
+- ❌ Preferring source content when it's newer
+- ❌ Prompting to choose between source and workspace versions
+- ❌ "Local wins with --force" logic
+- ❌ Two-phase prompt flow (platform marking + universal selection)
+
+---
 
-- **Escalating a platform to full `.platform.md`**
-  - Each marked platform‑specific workspace candidate is written to a platform‑specific markdown path (e.g. `yaml-test.qwen.md`) using the **full candidate content** (frontmatter + body).
-  - For root conflicts, only the section body is used (consistent with root handling elsewhere).
+#### 12. Summary
 
-- **Interaction with YAML overrides**
-  - If a platform has an existing YAML override file (e.g. `yaml-test.qwen.yml`) and is escalated to a full `.platform.md`:
-    - The corresponding YAML override file is removed as redundant.
-    - That platform is removed from the frontmatter merge plan for that registry path.
-  - After escalation, the remaining frontmatter/YAML plans (if any) are applied only for platforms that still use YAML overrides, ensuring universal frontmatter is not recomputed based on escalated full‑markdown variants.
+| Situation | Behavior |
+|-----------|----------|
+| **Single workspace file** | Write if differs from source, skip if at parity |
+| **Multiple identical** | Pick newest, write if differs from source |
+| **Multiple differing + force** | Auto-select newest (alphabetical tie-breaker) |
+| **Multiple differing + interactive** | Prompt per file (parity-filtered, single-step) |
+| **File matches universal** | Auto-skip with message |
+| **File matches platform-specific** | Auto-skip with message |
+| **No universal selected** | Original untouched, only platform-specific written |
+| **All skipped** | No changes, no confirmation |
 
+The conflict resolution ensures a smooth, intuitive workflow that minimizes prompts while giving users full control over their content.

package/specs/save/save-file-discovery.md

@@ -12,9 +12,11 @@ For each save/pack run, the pipeline considers up to four sets of candidates:
 
 ##### Local platform candidates
 
-- Files already present in the **package directory** under `.openpackage/packages/<name>/`.
+- Files already present in the **package root**:
+  - **Root package**: `<cwd>/` (universal subdirs, root files, `root/` direct copy)
+  - **Nested package**: `<cwd>/.openpackage/packages/<name>/`
 - Excludes:
-  - Internal `package.index.yml` metadata.
+  - Internal `openpackage.index.yml` metadata.
   - Certain root marker files (e.g. the unified root agents file) that are handled specially.
 - Only includes paths that are allowed by the registry path rules (e.g. skip internal or unsupported paths).
 
@@ -54,7 +56,7 @@ Each candidate includes:
 
 #### 4. First Save vs Subsequent Saves
 
-The behavior changes depending on whether the package already has an index (`package.index.yml`) with file mapping information.
+The behavior changes depending on whether the package already has an index (`openpackage.index.yml`) with file mapping information.
 
 ##### First save (no index present, or empty file mapping)
 
@@ -67,7 +69,7 @@ The behavior changes depending on whether the package already has an index (`pac
 
 ##### Subsequent saves (index present with file mappings)
 
-- The pipeline uses `package.index.yml` as a **filter** for which workspace paths are relevant:
+- The pipeline uses `openpackage.index.yml` as a **filter** for which workspace paths are relevant:
   - It builds a set of allowed registry paths and directories based on the index's `files` keys.
   - Workspace candidates whose registry paths are outside this allowed set are ignored, except for root files that are deliberately allowed.
 - It merges local and workspace candidates:

package/specs/save/save-frontmatter-overrides.md

@@ -1,8 +1,8 @@
-### Save Pipeline – Frontmatter and YAML Overrides
+### Save Pipeline – Frontmatter and Inline Platform Overrides
 
 #### 1. Overview
 
-For markdown files, the pipeline manages **frontmatter** and platform‑specific overrides to keep shared metadata centralized while allowing platform-specific behavior.
+For markdown files, the pipeline manages **frontmatter** and platform‑specific overrides to keep shared metadata centralized while allowing platform-specific behavior. Platform overrides now live **inline** inside the universal markdown frontmatter under `openpackage.<platform>` (ids/aliases); no separate `.yml` override files are written.
 
 ---
 
@@ -26,25 +26,22 @@ For each platform:
 
 - The per‑platform frontmatter is compared against the universal frontmatter.
 - Only the **difference** per platform is treated as that platform's override, or omitted if empty.
-- Platform overrides are written into **separate YAML files** in a dedicated overrides location.
+- Platform overrides are embedded **inline** under `openpackage.<platform>` (id/alias) in the universal frontmatter.
+- During apply/install, the target platform’s block is deep‑merged onto the common frontmatter to produce the final frontmatter for that platform. Platform blocks are not emitted in the installed files.
 
 ---
 
 #### 5. Conflicts with Existing Overrides
 
-When a platform override file already exists for a path:
-
-- The pipeline compares existing and new frontmatter, taking modification times into account.
-- Typically:
-  - If the newer change comes from the workspace, it is preferred by default.
-  - When there is a conflicting but not clearly newer override, the user may be prompted to choose between workspace and existing override content where appropriate.
+All overrides are computed from workspace candidates (overwrite-derived). The universal frontmatter is rewritten to contain the shared keys plus per-platform blocks; no external override files are consulted or prompted for.
 
 ---
 
 #### 6. Resulting Layout
 
-- One universal markdown file with shared frontmatter.
-- Zero or more per‑platform YAML override files capturing only the per‑platform differences.
+- One universal markdown file with:
+  - Shared/common frontmatter keys
+  - Per‑platform blocks nested under `openpackage.<platform>` containing only the per‑platform differences
 
 This scheme keeps:
 
@@ -60,15 +57,14 @@ After all conflicts and frontmatter merges are resolved, the pipeline reads the
 
 ##### Excluded
 
-- `package.index.yml`.
+- `openpackage.index.yml`.
 - Internal files that are not considered part of the package content.
 
 ##### Included
 
 - Paths allowed by the regular registry path rules.
 - Root files (the unified root agents file and related root docs).
-- YAML override files that represent platform‑specific metadata.
-- Root‑level files adjacent to `package.yml` that are intended as part of the package.
+- Root‑level files adjacent to `openpackage.yml` that are intended as part of the package.
 
 ---
 
@@ -77,5 +73,5 @@ After all conflicts and frontmatter merges are resolved, the pipeline reads the
 The resulting list of files, with paths relative to the package directory, is what gets:
 
 - Copied into the local registry under the computed version.
-- Used to drive platform sync and any subsequent operations in the save pipeline.
+- Used to drive optional platform apply/sync and any subsequent operations in the save pipeline.
 

package/specs/save/save-modes-inputs.md

@@ -1,55 +1,25 @@
-### Save Pipeline – Modes and Inputs
+### Save – Inputs and Flags
 
 #### 1. Overview
 
-The **save pipeline** is the shared engine behind:
+`opkg save` syncs workspace edits back to a package **source of truth** using the unified workspace index (`.openpackage/openpackage.index.yml`) as the mapping authority.
 
-- `opkg save` – creates a **WIP prerelease** snapshot for the current workspace.
-- `opkg pack` – promotes the current workspace state to a **stable** snapshot.
-
-Both commands:
-
-- Detect which package to operate on.
-- Resolve the effective package name (including scoping and optional rename).
-- Compute a target version (WIP vs stable) following `save-pack-versioning.md`.
-- Select the set of files that belong to the package.
-- Copy those files into the local registry.
-- Clean up outdated WIP copies for the current workspace.
-- Sync files to platform‑specific layouts (platform sync).
-
-Versioning details are defined in `../save-pack-versioning.md`.
-
----
-
-#### 2. Modes
-
-The pipeline runs in one of two **modes**:
-
-##### WIP mode (`save`)
-
-- Always produces a **WIP prerelease** version derived from the stable line in `package.yml`.
-- May optionally auto‑bump `package.yml.version` to the next patch after a stable cycle, per `../save-pack-versioning.md`.
-
-##### Stable mode (`pack`)
-
-- Produces a **stable** version exactly equal to the current `package.yml.version`.
-- Never mutates `package.yml.version`.
+It does **not** create registry snapshots (that is `opkg pack`).
 
 ---
 
 #### 3. Inputs
 
-- **Working directory (`cwd`)** – establishes the workspace.
-- **Package name argument (optional)** – may be omitted (context detection) or provided explicitly.
-- **Optional path argument (when package is provided)** – `opkg save <package> <path>` first runs the add pipeline for that path (including conflict handling and optional platform-specific transforms) and then saves the package snapshot.
+- **Working directory (`effective cwd` via shell dir or global `--cwd <dir>` flag)** – establishes the workspace root for file discovery, package detection, and saving (see [../cli-options.md]).
+- **Package name argument (required)** – `save` requires a package name because it operates on mappings stored in the unified workspace index.
+- **Optional path argument** – `opkg save <package> <path>` first runs the add pipeline for that path (copy-to-root for non-platform paths), then runs `save` for the package.
 
 ---
 
 #### 4. Flags
 
 - **`force`**
-  - In WIP mode: can suppress prompts and allow overwriting existing WIP versions.
-  - In stable mode: allows overwriting existing stable registry entries.
-- **`rename <newName>`** – optional new package name to apply during this pipeline run.
-- **`platform-specific` (save only, when path is provided)** – forwarded to the add stage to generate platform-scoped variants for platform subdirectories.
+  - Auto-selects by latest mtime when conflicts occur (non-interactive resolution).
+- **`platform-specific` (only when path is provided)** – forwarded to the add stage to generate platform-scoped variants for platform subdirectory inputs.
+- **`apply` (only when path is provided)** – forwarded to the add stage to immediately apply after adding (sync platforms).
 

package/specs/save/save-naming-scoping.md

@@ -13,7 +13,7 @@ After the package context is known, the pipeline determines the **effective name
   - The detected package config's `name` when no argument is provided.
 - The pipeline **never accepts a version suffix** here:
   - Any `name@version` input is rejected with a clear error.
-  - The error instructs the user to change the stable line in `package.yml` instead.
+  - The error instructs the user to change the stable line in `openpackage.yml` instead.
 
 ---
 
@@ -67,7 +67,7 @@ At the end of this phase the pipeline knows:
 
 When a rename is needed during `save` or `pack`, the workspace is updated so that **on‑disk layout matches the new name**.
 
-##### `package.yml`
+##### `openpackage.yml`
 
 - The package's `name` field is updated to the final name.
 
@@ -75,9 +75,9 @@ When a rename is needed during `save` or `pack`, the workspace is updated so tha
 
 - Root files that contain package markers (e.g. sections in shared documentation) are updated so that markers reference the new name instead of the old one.
 
-##### Root `package.yml` dependencies
+##### Root `openpackage.yml` dependencies
 
-- The workspace's root `package.yml` (if present) updates any dependency entries that reference the old name to the new name in both `packages` and `dev-packages`.
+- The workspace's root `openpackage.yml` (if present) updates any dependency entries that reference the old name to the new name in both `packages` and `dev-packages`.
 
 ##### Nested package directories
 

package/specs/save/save-package-detection.md

@@ -8,7 +8,7 @@ Before any name or version logic, the pipeline determines which package is being
 
 #### 2. Core Rule
 
-Any directory that contains `.openpackage/package.yml` is considered a **valid package**.
+Any directory that contains `openpackage.yml` is considered a **valid package**.
 
 ---
 
@@ -16,23 +16,23 @@ Any directory that contains `.openpackage/package.yml` is considered a **valid p
 
 ##### No package name argument
 
-- Looks for `.openpackage/package.yml` in the current directory.
+- Looks for `openpackage.yml` in the current directory.
 - If found:
   - Treats the current directory as the **root package**.
-  - Uses its `package.yml` as the configuration source.
+  - Uses its `openpackage.yml` as the configuration source.
 - If not found:
   - The pipeline **aborts** with a user‑friendly message describing:
-    - That no package was detected at `cwd`.
-    - That a `.openpackage/package.yml` file is required.
+    - That no package was detected at effective `cwd` (shell dir or `--cwd <dir>`; see [../../cli-options.md]).
+    - That an `openpackage.yml` file is required.
     - How to initialize a package or specify a name explicitly.
 
 ##### Package name argument provided
 
-- First checks whether the **root package** (`.openpackage/package.yml` at `cwd`) has a matching `name`.
+- First checks whether the **root package** (`openpackage.yml` at `cwd`) has a matching `name`.
   - If yes, the root is the target.
 - Otherwise, looks under the **nested packages directory**:
-  - Direct directory match under `.openpackage/packages/<name>/package.yml`.
-  - If necessary, scans all nested package directories to find a `package.yml` whose `name` field equals the requested package name, even if the directory name differs.
+  - Direct directory match under `.openpackage/packages/<name>/openpackage.yml`.
+  - If necessary, scans all nested package directories to find an `openpackage.yml` whose `name` field equals the requested package name, even if the directory name differs.
 - If no matching package is found:
   - The pipeline **aborts** with a message explaining:
     - The package name was not found.
@@ -46,11 +46,11 @@ Any directory that contains `.openpackage/package.yml` is considered a **valid p
 Each detected package context includes:
 
 - **Package directory** (logical package root for reporting).
-- **Path to `package.yml`** (authoritative manifest location).
-- **Package files directory** (`packageFilesDir` in code):
-  - For the **root package**: `<cwd>/.openpackage/…`
-  - For **nested packages**: `<cwd>/.openpackage/packages/<name>/…`
-- Parsed `package.yml` configuration.
+- **Path to `openpackage.yml`** (authoritative manifest location).
+- **Package files directory** (`packageFilesDir` in code; same as package root):
+  - For the **root package**: `<cwd>/`
+  - For **nested packages**: `<cwd>/.openpackage/packages/<name>/`
+- Parsed `openpackage.yml` configuration.
 - Whether it is the **root package** or **nested**.
 - Whether the package's directory is the same as `cwd`.