project-tiny-context-harness 0.2.56 → 0.2.57

package/README.md

@@ -115,7 +115,7 @@ npm ci
 npm run smoke:quickstart
 npm run preview:pack
 cd /path/to/your/test-repo
-npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.56.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.57.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -228,11 +228,11 @@ Use `npx --no-install ty-context ...` only when you explicitly want the already
 | Development engineer Skill | `<harnessRoot>/skills/context_development_engineer/SKILL.md` | Handles explicit development-engineering requests and writes durable engineering conclusions to `project_context/**`. |
 | Product Surface Contract Skill | `<harnessRoot>/skills/context_surface_contract/SKILL.md` | Handles explicit Product Surface Contract, Screen Contract, surface responsibility and main/drilldown ownership work; it compiles project-owned surface contracts into `project_context/**` without adding a new context role or gate. |
 | Full project context export Skill | `<harnessRoot>/skills/context_full_project_export/SKILL.md` | Handles explicit full-project or code-level export requests and uses `export-context --all`, `--full` or `--code` to create temporary artifacts under `tmp/ty-context/context-exports/**`. |
-| Harness upgrade Skill | `<harnessRoot>/skills/context_harness_upgrade/SKILL.md` | Handles explicit Tiny Context / Project Tiny Context Harness upgrade requests such as “upgrade Tiny Context” and “use the Tiny Context upgrade skill to upgrade this project”; it runs `upgrade` first, handles only migration-scoped `manual_required` / `blocked` follow-up, then runs diagnostics. |
+| Harness upgrade Skill | `<harnessRoot>/skills/context_harness_upgrade/SKILL.md` | Handles explicit Tiny Context / Project Tiny Context Harness upgrade requests such as “upgrade Tiny Context” and “use the Tiny Context upgrade skill to upgrade this project”; it runs the canonical `upgrade` path, handles only migration-scoped `manual_required` / `blocked` follow-up, then runs diagnostics. |
 | Plan acceptance checklist Skill | `<harnessRoot>/skills/plan_acceptance_checklist_compiler/SKILL.md` | Handles explicit requests to turn a referenced plan, RFC or implementation proposal into a falsifiable acceptance checklist and paste-ready goal/target-mode prompt under `tmp/ty-context/plan-acceptance/**`; it does not execute the plan or prove completion. |
 | Project-local Skills | `<harnessRoot>/skills/<role>/SKILL.md` | Optional local product/design/development Skills created by the project, such as `product_plan`, `uiux_design` or `development_engineer`. They supersede package-managed default Skills when more specific, are not overwritten by `sync`, and should keep front matter trigger keywords aligned with the project `AGENTS.md` role-trigger rule. |
-| Managed file sync | `make ty-context-sync` or `npx --yes --package project-tiny-context-harness@latest ty-context sync` | Refreshes package-managed guidance, default Skills, Makefile include, context templates, tools and workflow YAML. It does not run migrations or perform semantic Context generation; when migration work is pending it refuses to write and tells you to run `upgrade`. |
-| Upgrade | `make ty-context-upgrade` or `npx --yes --package project-tiny-context-harness@latest ty-context upgrade` | Default command after updating the npm package. Builds an upgrade plan, stops before writes when `blocked` items exist, otherwise applies `safe_pending` migrations, runs `sync` and `doctor`, and exits non-zero when manual follow-up or diagnostics remain. |
+| Managed file sync | `make ty-context-sync` or `npx --yes --package project-tiny-context-harness@latest ty-context sync` | Refreshes package-managed guidance, default Skills, Makefile include, context templates, tools and workflow YAML. It does not run migrations or perform semantic Context generation; it may block only direct asset-refresh safety issues such as invalid managed blocks or deprecated managed Skill overrides. |
+| Upgrade | `make ty-context-upgrade` or `npx --yes --package project-tiny-context-harness@latest ty-context upgrade` | Use for releases marked `upgrade-required` or `manual-required`. Builds an upgrade plan, stops before writes when `blocked` items exist, otherwise applies `safe_pending` migrations, runs `sync` and `doctor`, and exits non-zero when manual follow-up or diagnostics remain. |
 | Upgrade check | `npx --yes --package project-tiny-context-harness@latest ty-context upgrade --check [--json]` | Checks the upgrade plan without writing files. Reports `safe_pending`, `manual_required` and `blocked`; exits non-zero when any work remains. |
 | Combined project export | `npx --yes --package project-tiny-context-harness@latest ty-context export-context --all [--check]` | Creates both default temporary exports under `tmp/ty-context/context-exports/**`. |
 | Project Context export | `npx --yes --package project-tiny-context-harness@latest ty-context export-context --full [--output tmp/ty-context/context-exports/name.md] [--check]` | Creates a temporary Context summary artifact. It is not Context and must not be registered in `project_context/context.toml`. |
@@ -293,7 +293,7 @@ Omitting `policy` behaves the same as `scoped_waivers` for compatibility with ex
 
 Multilingual trigger phrases are compatibility details. Public README, npm and launch copy stay English-first, and public/package-managed surfaces must remain English-complete; literal non-English examples are documented only where they explain generated Skill matching and must not be the sole activation path.
 
-The Harness upgrade Skill exists so consumer agents have a short, repeatable upgrade procedure for existing projects. It treats `ty-context upgrade` as the default command after package updates, forbids standalone `sync` before upgrade, and limits manual handling to the migration scope reported by the CLI instead of guessing project semantics.
+The Harness upgrade Skill exists so consumer agents have a short, repeatable upgrade procedure for existing projects. It treats `upgrade` as the default after package updates and for explicit upgrade requests; `sync-only` only allows a direct managed-asset refresh shortcut when that is what the user asked for. Manual handling stays limited to the migration scope reported by the CLI instead of guessing project semantics.
 
 For complex task-contract work, agents may use `plan.md` or an equivalent temporary plan surface as scratch space for `Context Delta`, `Task Contract`, implementation steps and Conformance notes. It is execution cache only: durable facts must be extracted into `project_context/**` or `DESIGN.md`, and temporary plans are not Context, not registered in `context.toml` and not default project assets.
 
@@ -432,9 +432,9 @@ Do not customize the package-managed Surface Contract, Harness upgrade or plan a
 
 ## Sync And Upgrade Boundary
 
-`sync` is intentionally narrow. It refreshes managed files and never generates project semantics. `sync` does not run migrations; if it detects `safe_pending`, `manual_required` or `blocked` migration work, it refuses to write and points the user to `upgrade`.
+`sync` is intentionally narrow. It refreshes managed files and never generates project semantics. `sync` does not run migrations or call the full migration registry; it may refuse writes only for direct asset-refresh safety blockers such as unsupported schema, invalid managed blocks or deprecated managed Skill overrides.
 
-After updating the package, run `ty-context upgrade`. Use `sync` only when release notes say the update is `sync-only`.
+After updating the package, run `ty-context upgrade`. It is the default update entry because it checks local migration state, applies safe migrations when needed, refreshes managed assets and runs diagnostics. For releases marked `sync-only`, direct `sync` is an allowed shortcut only when you explicitly want managed-asset refresh without the upgrade diagnostics.
 
 `upgrade` first builds an upgrade plan. If `blocked` items exist, it prints the plan, runs diagnostics and exits non-zero before migrations or internal `sync`. Without blockers, it applies only `safe_pending` migrations, then runs `sync` and `doctor`. If `manual_required` follow-up or diagnostics remain, the command exits non-zero and prints follow-up. `upgrade --check` performs the same planning step without writing files; `upgrade --check --json` is intended for release checks and CI.
 
@@ -442,7 +442,7 @@ Release update modes:
 
 | Update mode | What to run | Meaning |
 |---|---|---|
-| `sync-only` | `ty-context sync` | The release changes only package-managed assets. No migrations are required. |
+| `sync-only` | Default: `ty-context upgrade`; shortcut: `ty-context sync` | The release changes only package-managed assets. No new migrations are expected. |
 | `upgrade-required` | `ty-context upgrade` | The release includes safe mechanical migrations and managed asset refresh. |
 | `manual-required` | `ty-context upgrade`, then manual follow-up | The release includes items that cannot be mechanically changed without user intent. |
 

package/assets/README.md

@@ -94,7 +94,7 @@ That smoke packs the local workspace, installs it into a disposable repo, runs `
 ```sh
 npm run preview:pack
 cd /path/to/your/test-repo
-npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.56.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.57.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -266,7 +266,7 @@ No. It checks that recovery facts exist and avoids fake test-result claims. Prod
 
 It should stay smaller than a full process. Ordinary bug fixes and local refactors do not update Context unless they produce durable product, architecture, API, state or validation facts.
 
-The default Skills are Minimal Context helpers for explicit product-planning, UI/UX-design, development-engineering, Product Surface Contract, full-project-export, Tiny Context upgrade and plan-acceptance-checklist requests. Product, screen-flow, surface responsibility and durable engineering conclusions go to `project_context/**`; visual identity and design tokens go to root `DESIGN.md`. Export artifacts are temporary files under `tmp/ty-context/context-exports/**`, not Context. Plan acceptance artifacts are temporary files under `tmp/ty-context/plan-acceptance/**`; they define completion criteria for a referenced plan but do not execute it or prove acceptance. The Harness upgrade Skill handles requests such as “upgrade Tiny Context” and “use the Tiny Context upgrade skill to upgrade this project” by running `upgrade` first, handling only migration-scoped follow-up, and avoiding standalone `sync` before the upgrade path.
+The default Skills are Minimal Context helpers for explicit product-planning, UI/UX-design, development-engineering, Product Surface Contract, full-project-export, Tiny Context upgrade and plan-acceptance-checklist requests. Product, screen-flow, surface responsibility and durable engineering conclusions go to `project_context/**`; visual identity and design tokens go to root `DESIGN.md`. Export artifacts are temporary files under `tmp/ty-context/context-exports/**`, not Context. Plan acceptance artifacts are temporary files under `tmp/ty-context/plan-acceptance/**`; they define completion criteria for a referenced plan but do not execute it or prove acceptance. The Harness upgrade Skill handles requests such as “upgrade Tiny Context” and “use the Tiny Context upgrade skill to upgrade this project” by following the release update mode, using `upgrade` for migration-bearing releases, and limiting manual cleanup to migration-scoped follow-up.
 
 Multilingual trigger phrases are compatibility details. Public README, npm and launch copy stay English-first, and public/package-managed surfaces must remain English-complete; literal non-English examples are documented only where they explain generated Skill matching and must not be the sole activation path.
 
@@ -338,8 +338,8 @@ Use `npx --no-install ty-context ...` only when you explicitly want the already
 | Command | Purpose |
 |---|---|
 | `npx --yes --package project-tiny-context-harness@latest ty-context init` | Non-destructively installs Minimal Context Harness into the current project. |
-| `make ty-context-sync` or `npx --yes --package project-tiny-context-harness@latest ty-context sync` | Refreshes managed guidance, default Skills, Makefile include, tools and templates. It does not run migrations or generate project semantics; when migration work is pending it refuses to write and tells you to run `upgrade`. |
-| `make ty-context-upgrade` or `npx --yes --package project-tiny-context-harness@latest ty-context upgrade` | Default command after updating the npm package. Builds an upgrade plan, stops before writes when `blocked` items exist, otherwise applies `safe_pending` migrations, runs `sync` and `doctor`, and exits non-zero when manual follow-up or diagnostics remain. |
+| `make ty-context-sync` or `npx --yes --package project-tiny-context-harness@latest ty-context sync` | Refreshes managed guidance, default Skills, Makefile include, tools and templates. It does not run migrations or generate project semantics; it may block only direct asset-refresh safety issues such as invalid managed blocks or deprecated managed Skill overrides. |
+| `make ty-context-upgrade` or `npx --yes --package project-tiny-context-harness@latest ty-context upgrade` | Use for releases marked `upgrade-required` or `manual-required`. Builds an upgrade plan, stops before writes when `blocked` items exist, otherwise applies `safe_pending` migrations, runs `sync` and `doctor`, and exits non-zero when manual follow-up or diagnostics remain. |
 | `npx --yes --package project-tiny-context-harness@latest ty-context upgrade --check [--json]` | Checks the upgrade plan without writing files. Reports `safe_pending`, `manual_required` and `blocked`; exits non-zero when any work remains. |
 | `npx --yes --package project-tiny-context-harness@latest ty-context export-context --all [--check]` | Creates both default temporary exports under `tmp/ty-context/context-exports/**`. |
 | `npx --yes --package project-tiny-context-harness@latest ty-context export-context --full [--output tmp/ty-context/context-exports/name.md] [--check]` | Creates a temporary project Context summary Markdown artifact. |
@@ -354,7 +354,7 @@ Use `npx --no-install ty-context ...` only when you explicitly want the already
 
 ## Updating Existing Projects
 
-After updating the package, run `ty-context upgrade`. Use `sync` only when release notes say the update is `sync-only`; sync does not run migrations.
+After updating the package, run `ty-context upgrade`. It is the default update entry because it checks local migration state, applies safe migrations when needed, refreshes managed assets and runs diagnostics. For releases marked `sync-only`, direct `sync` is an allowed shortcut only when you explicitly want managed-asset refresh without the upgrade diagnostics.
 
 ```sh
 npm install -D project-tiny-context-harness@latest
@@ -362,11 +362,17 @@ npx --yes --package project-tiny-context-harness@latest ty-context upgrade --che
 npx --yes --package project-tiny-context-harness@latest ty-context upgrade
 ```
 
+For `sync-only` releases where you explicitly want only managed-asset refresh, this shortcut is allowed:
+
+```sh
+npx --yes --package project-tiny-context-harness@latest ty-context sync
+```
+
 Release notes and release readiness use this update mode vocabulary:
 
 | Update mode | What to run | Meaning |
 |---|---|---|
-| `sync-only` | `ty-context sync` | The release changes only package-managed assets. No migrations are required. |
+| `sync-only` | Default: `ty-context upgrade`; shortcut: `ty-context sync` | The release changes only package-managed assets. No new migrations are expected. |
 | `upgrade-required` | `ty-context upgrade` | The release includes safe mechanical migrations and managed asset refresh. |
 | `manual-required` | `ty-context upgrade`, then manual follow-up | The release includes items that cannot be mechanically changed without user intent. |
 

package/assets/make/ty-context.mk

@@ -7,7 +7,7 @@ TY_CONTEXT_MODULARITY_SCOPE = $(if $(TY_CONTEXT_MODULARITY_BASE),--base $(TY_CON
 help:
 	@echo "Minimal Context Harness commands"
 	@echo "  make ty-context-doctor         Diagnose Harness root, core package and schema version"
-	@echo "  make ty-context-sync           Refresh managed assets; refuses when upgrade migrations are pending"
+	@echo "  make ty-context-sync           Refresh managed assets; does not run migrations"
 	@echo "  make ty-context-upgrade        Run safe upgrade migrations, sync managed assets and doctor"
 	@echo "  make ty-context-check-modularity  Warn on oversized touched handwritten source files"
 	@echo "  make validate-context    Check whether project_context/** supports context recovery"

package/assets/skills/context_harness_upgrade/SKILL.md

@@ -13,7 +13,7 @@ This Skill handles Harness package upgrade and migration orchestration only. It
 
 ## Purpose
 
-When the user asks to upgrade Tiny Context / Project Tiny Context Harness in an existing project, run the canonical upgrade path, handle only migration-scoped follow-up, and leave durable project semantics to the project Context and user-owned code.
+When the user asks to upgrade Tiny Context / Project Tiny Context Harness in an existing project, run the canonical `upgrade` path, handle only migration-scoped follow-up, and leave durable project semantics to the project Context and user-owned code. A `sync-only` release means no new migration is expected; it does not change the default upgrade entry for explicit upgrade requests.
 
 ## Workflow
 
@@ -24,22 +24,25 @@ When the user asks to upgrade Tiny Context / Project Tiny Context Harness in an
    - `project_context/context.toml`
 2. Inspect the working tree with `git status --short`. Do not revert unrelated user changes.
 3. Prefer project wrappers when present:
+   - `make ty-context-sync`
    - `make ty-context-upgrade`
    - `make ty-context-doctor`
    - `make validate-context`
 4. If no wrapper exists, use the package CLI explicitly:
+   - `npx --yes --package project-tiny-context-harness@latest ty-context sync`
    - `npx --yes --package project-tiny-context-harness@latest ty-context upgrade --check`
    - `npx --yes --package project-tiny-context-harness@latest ty-context upgrade`
    - `npx --yes --package project-tiny-context-harness@latest ty-context doctor`
-5. Do not run standalone `sync` before `upgrade`. `upgrade` is the default path after an npm package update because it plans migrations, applies safe migrations, refreshes managed assets and runs diagnostics.
-6. Do not run standalone `sync` after a successful `upgrade` unless release notes say the update is `sync-only`, the project wrapper did not run sync, or the user explicitly asks for a managed-asset refresh.
-7. If `upgrade --check` or `upgrade` reports only `safe_pending` items and the command succeeds, do not invent additional manual cleanup.
-8. If the report includes `manual_required` or `blocked`, handle only the listed migration scope. Use `project_context/context.toml`, role placement scan and the existing area graph to decide placement. Do not guess product or business semantics.
-9. If the report includes `blocked`, treat it as a write preflight failure: resolve the blocked migration scope and rerun `upgrade` before expecting safe migrations or managed asset sync to have been applied.
-10. Run diagnostics after migration-scoped follow-up:
+5. Run `upgrade --check` when useful, then run `upgrade`. This remains the default after package updates and for explicit upgrade requests because it plans migrations, applies safe migrations, refreshes managed assets and runs diagnostics.
+6. Do not run standalone `sync` before `upgrade` for explicit upgrade requests. A direct `sync` is only a shortcut for releases explicitly marked `sync-only` when the user asks for managed-asset refresh instead of upgrade diagnostics.
+7. Do not run standalone `sync` after a successful `upgrade` unless the project wrapper did not run sync or the user explicitly asks for another managed-asset refresh.
+8. If `upgrade --check` or `upgrade` reports only `safe_pending` items and the command succeeds, do not invent additional manual cleanup.
+9. If the report includes `manual_required` or `blocked`, handle only the listed migration scope. Use `project_context/context.toml`, role placement scan and the existing area graph to decide placement. Do not guess product or business semantics.
+10. If the report includes `blocked`, treat it as a write preflight failure: resolve the blocked migration scope and rerun `upgrade` before expecting safe migrations or managed asset sync to have been applied.
+11. Run diagnostics after migration-scoped follow-up:
    - `make ty-context-doctor` or the CLI `doctor`
    - `make validate-context`
-11. Report commands run, migration status, diagnostics, files changed and any remaining manual items. Use `Context: no durable project facts changed` unless the upgrade exposed or required a real long-term project fact change.
+12. Report commands run, migration status, diagnostics, files changed and any remaining manual items. Use `Context: no durable project facts changed` unless the upgrade exposed or required a real long-term project fact change.
 
 ## Manual Handling Rules
 

package/assets/skills/plan_acceptance_checklist_compiler/SKILL.md

@@ -213,6 +213,28 @@ Column rules:
 
 Each item must be evidence-bound and falsifiable. Split combined requirements into separate rows.
 
+## Hard Blocker Handling
+
+Treat any unresolved required blocker as non-completion. A checklist may describe blocked acceptance work, but blocked work is still not accepted until the required evidence exists.
+
+Use `blocked-external` only when the item is required for full completion but depends on unavailable user input, credentials, account/session access, manual approval, external environment state, provider availability, legal/compliance decision, or another dependency the future executor cannot satisfy locally.
+
+For every `blocked-external` item, state:
+
+- The exact missing evidence.
+- Why the future executor cannot produce it locally.
+- The required user, owner, external system, or approval action.
+- The fallback or degraded path, if the plan or Context allows one.
+- The acceptance impact if the blocker remains unresolved.
+
+Do not mark blocked work as `out-of-scope`, `conditional`, or `nice-to-have` merely because it is hard or currently unavailable. Do not treat partial local work, preparation, mocks, old evidence, or an unexercised fallback as completion for a blocked required item.
+
+The generated goal/target-mode prompt must tell the future executor:
+
+- If any executable `core` item remains, continue working it before asking the user to resolve blockers.
+- If the only remaining incomplete required items are hard blockers that cannot be satisfied locally, pause and wait for the user or external owner instead of marking the goal complete.
+- The handoff must list blocker cause, missing evidence, acceptance impact, and the exact user/external action needed to resume.
+
 ## Generic Acceptance Dimensions
 
 Include only dimensions relevant to the plan. Do not mechanically add irrelevant categories.
@@ -271,6 +293,7 @@ Use these exact labels:
 - `nice-to-have`: useful but not required; use sparingly.
 
 Do not mark an item out of scope only because it is difficult.
+Do not mark a `blocked-external` item complete until its required evidence exists.
 
 ## Conflict Handling
 
@@ -327,6 +350,7 @@ Every generated checklist must pass this self-test:
 - [ ] Every evidence item defines invalid evidence.
 - [ ] Code, API, UI, data, runtime, artifacts, and tests are separated when they prove different things.
 - [ ] External blockers are separated from local remaining work.
+- [ ] Hard blockers are treated as non-completion, with required user/external action and pause conditions.
 - [ ] Current implementation was not used to reduce the user's completion definition.
 - [ ] The checklist can be handed to another Codex session without hidden assumptions.
 ```
@@ -367,9 +391,9 @@ AC8 <UI/用户可见/API 投影一致性要求>
 AC9 <安全/隐私/脱敏/secret 要求>
 AC10 <测试/构建/集成/smoke/回归要求>
 AC11 <文档/Context 更新要求，仅在计划要求时执行>
-AC12 完成前审计：逐条对照实施计划；每个 core 项必须有当前证据；未跑验证必须明示；有可继续执行的 core 项不得标记完成；外部阻塞必须写明原因、影响和下一步。
+AC12 完成前审计：逐条对照实施计划；每个 core 项必须有当前证据；未跑验证必须明示；有可继续执行的 core 项不得标记完成；外部/强卡点必须写明原因、缺失证据、验收影响和下一步；若剩余未完成项只有无法本地解决的强卡点，暂停并等待用户/外部 owner，不能标记目标完成。
 
-禁止把以下内容当完成：只改代码、只更新计划、只跑部分测试、只生成旧/部分/不被当前契约接受的证据、只完成基础设施但未完成验收证据、API/UI/数据/测试之间仍矛盾。
+禁止把以下内容当完成：只改代码、只更新计划、只跑部分测试、只生成旧/部分/不被当前契约接受的证据、只完成基础设施但未完成验收证据、强卡点未解除、API/UI/数据/测试之间仍矛盾。
 ```
 
 Recommended compact English prompt shape:
@@ -390,9 +414,9 @@ AC8 <UI / user-visible / API projection consistency>
 AC9 <security / privacy / redaction / secret handling>
 AC10 <test / build / integration / smoke / regression requirements>
 AC11 <documentation / Context updates only when required by the plan>
-AC12 Final audit: compare every item against the plan; every core item needs current evidence; missing validation must be stated; any executable core item left open means the task is not complete; external blockers need cause, impact, and next action.
+AC12 Final audit: compare every item against the plan; every core item needs current evidence; missing validation must be stated; any executable core item left open means the task is not complete; external or hard blockers need cause, missing evidence, acceptance impact, and next action; if only locally unsatisfiable hard blockers remain, pause for the user or external owner instead of marking the goal complete.
 
-Do not count these as completion: code-only changes, plan-only updates, partial tests, stale or partial evidence, infrastructure without acceptance proof, or contradictions between API/UI/data/tests.
+Do not count these as completion: code-only changes, plan-only updates, partial tests, stale or partial evidence, infrastructure without acceptance proof, unresolved hard blockers, or contradictions between API/UI/data/tests.
 ```
 
 Before final response, check the prompt length. If it exceeds 4000 characters, compress it and check again.

package/dist/commands/index.js

@@ -24,7 +24,7 @@ export function help() {
     console.log(`ty-context commands:
   init [--adopt] [--harness-folder <path>]
                        Initialize/adopt a project; without --harness-folder, choose target agent first
-  sync                 Refresh managed assets; refuses when upgrade migrations are pending
+  sync                 Refresh managed assets; does not run migrations
   upgrade [--check] [--json]
                        Run safe migrations, sync managed assets and doctor
   doctor               Diagnose project configuration and drift

package/dist/lib/sync-engine.d.ts

@@ -3,8 +3,5 @@ export interface SyncReport {
     skipped: string[];
     blocked: string[];
 }
-export interface SyncOptions {
-    allowPendingMigrations?: boolean;
-}
 export declare function emptySyncReport(): SyncReport;
-export declare function runSync(projectRoot: string, options?: SyncOptions): Promise<SyncReport>;
+export declare function runSync(projectRoot: string): Promise<SyncReport>;

package/dist/lib/sync-engine.js

@@ -6,7 +6,6 @@ import { copyTree, listFiles, pathExists, readText, writeTextIfChanged } from ".
 import { AGENTS_BLOCK_MARKERS, GITHUB_WORKFLOW_BLOCK_END, GITHUB_WORKFLOW_BLOCK_MARKERS, GITHUB_WORKFLOW_BLOCK_START, MAKEFILE_BLOCK_END, MAKEFILE_BLOCK_MARKERS, MAKEFILE_BLOCK_START, MANAGED_BLOCK_END, MANAGED_BLOCK_START } from "./managed-file.js";
 import { packageAssetPath } from "./paths.js";
 import { assertSupportedSchema } from "./schema-guard.js";
-import { createUpgradePlan, formatUpgradePlan, hasUpgradePlanWork } from "./migrations.js";
 export function emptySyncReport() {
     return {
         changed: [],
@@ -14,18 +13,11 @@ export function emptySyncReport() {
         blocked: []
     };
 }
-export async function runSync(projectRoot, options = {}) {
+export async function runSync(projectRoot) {
     await assertSupportedSchema(projectRoot, "sync");
     const root = await harnessRoot(projectRoot);
     const config = await readConfig(projectRoot);
     const report = emptySyncReport();
-    if (!options.allowPendingMigrations) {
-        const upgradePlan = await createUpgradePlan(projectRoot);
-        if (hasUpgradePlanWork(upgradePlan)) {
-            report.blocked.push(`upgrade required before sync: ${formatUpgradePlan(upgradePlan).join(" | ")}`);
-            return report;
-        }
-    }
     await blockDeprecatedSkillOverrides(projectRoot, root, report);
     if (report.blocked.length > 0) {
         return report;
@@ -275,7 +267,7 @@ async function blockDeprecatedSkillOverrides(projectRoot, root, report) {
         if (deprecatedFiles.length === 0) {
             continue;
         }
-        report.blocked.push(`${overrideRoot.relative}: Skill overrides are no longer supported. Move these rules into a separate project-local Skill such as ${root.replace(/\\/g, "/")}/skills/product_plan/SKILL.md, ${root.replace(/\\/g, "/")}/skills/uiux_design/SKILL.md or ${root.replace(/\\/g, "/")}/skills/development_engineer/SKILL.md. Deprecated files: ${deprecatedFiles.join(", ")}`);
+        report.blocked.push(`${overrideRoot.relative}: deprecated Skill overrides block sync because package-managed default Skills are overwritten during managed asset refresh. Move these rules into a separate project-local Skill such as ${root.replace(/\\/g, "/")}/skills/product_plan/SKILL.md, ${root.replace(/\\/g, "/")}/skills/uiux_design/SKILL.md or ${root.replace(/\\/g, "/")}/skills/development_engineer/SKILL.md. Deprecated files: ${deprecatedFiles.join(", ")}`);
     }
 }
 function skillOverrideRoots(projectRoot, root) {

package/dist/lib/upgrade.js

@@ -36,7 +36,7 @@ export async function runUpgradeReport(projectRoot) {
             blocked: migrationReport.blocked
         }).slice(1));
     }
-    const syncReport = await runSync(projectRoot, { allowPendingMigrations: true });
+    const syncReport = await runSync(projectRoot);
     lines.push(`sync changed=${syncReport.changed.length} skipped=${syncReport.skipped.length} blocked=${syncReport.blocked.length}`);
     for (const skipped of syncReport.skipped.filter((line) => line.includes("customized"))) {
         lines.push(`sync skipped: ${skipped}`);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "project-tiny-context-harness",
-  "version": "0.2.56",
+  "version": "0.2.57",
   "description": "Minimal project memory and validation harness for AI coding agents.",
   "license": "MIT",
   "author": "Seven128",