kanon-cli 3.4.0__tar.gz → 3.4.2__tar.gz

{kanon_cli-3.4.0 → kanon_cli-3.4.2}/.github/CODEOWNERS

@@ -2,5 +2,5 @@
 #
 # Defines code ownership for pull request review requirements.
 
-# All files owned by the primary maintainer
-/ @matt-dresden-caylent
+# All files owned by the Kanon release-approver team
+* @caylent-solutions/kanon-release-approvers

{kanon_cli-3.4.0 → kanon_cli-3.4.2}/.github/workflows/main-validation.yml

@@ -429,3 +429,19 @@ jobs:
         run: |
           NEW_VERSION=$(grep '^version = ' pyproject.toml | sed 's/.*version = "\([^"]*\)".*/\1/')
           gh workflow run publish.yml -f tag="$NEW_VERSION"
+
+  native-windows:
+    name: Native Windows contracts
+    runs-on: windows-latest
+    steps:
+      - name: Checkout reviewed commit
+        uses: actions/checkout@v6
+        with:
+          ref: ${{ github.event.pull_request.head.sha || github.sha }}
+          fetch-depth: 0
+      - uses: ./.github/actions/setup-kanon
+      - name: Run native Windows acceptance
+        env:
+          KANON_NATIVE_STORE_ROOT: ${{ runner.temp }}
+        shell: bash
+        run: make test-windows

{kanon_cli-3.4.0 → kanon_cli-3.4.2}/.github/workflows/pr-validation.yml

@@ -378,3 +378,19 @@ jobs:
           fi
           echo "Final owners: $UNIQUE_OWNERS"
           echo "owners=$UNIQUE_OWNERS" >> $GITHUB_OUTPUT
+
+  native-windows:
+    name: Native Windows contracts
+    runs-on: windows-latest
+    steps:
+      - name: Checkout reviewed commit
+        uses: actions/checkout@v6
+        with:
+          ref: ${{ github.event.pull_request.head.sha || github.sha }}
+          fetch-depth: 0
+      - uses: ./.github/actions/setup-kanon
+      - name: Run native Windows acceptance
+        env:
+          KANON_NATIVE_STORE_ROOT: ${{ runner.temp }}
+        shell: bash
+        run: make test-windows

{kanon_cli-3.4.0 → kanon_cli-3.4.2}/.pre-commit-config.yaml

@@ -33,7 +33,7 @@ repos:
     hooks:
       - id: no-comments
         name: no-comments (kanon-owned Python)
-        entry: python tools/lint/check_no_comments.py
+        entry: uv run python tools/lint/check_no_comments.py
         language: system
         types: [python]
         files: ^(src/kanon_cli|tests)/

{kanon_cli-3.4.0 → kanon_cli-3.4.2}/CHANGELOG.md

@@ -2,8 +2,302 @@
 
 
 
+## v3.4.2 (2026-09-28)
+
+### Build
+
+* build(deps): bump gitpython from 3.1.58 to 3.1.59
+
+Bumps [gitpython](https://github.com/gitpython-developers/GitPython) from 3.1.58 to 3.1.59.
+- [Release notes](https://github.com/gitpython-developers/GitPython/releases)
+- [Changelog](https://github.com/gitpython-developers/GitPython/blob/main/CHANGES)
+- [Commits](https://github.com/gitpython-developers/GitPython/compare/3.1.58...3.1.59)
+
+---
+updated-dependencies:
+- dependency-name: gitpython
+  dependency-version: 3.1.59
+  dependency-type: indirect
+...
+
+Signed-off-by: dependabot[bot] <support@github.com> ([`aa305fd`](https://github.com/caylent-solutions/kanon/commit/aa305fda781cb18119f20117c60469ce340a3428))
+
+### Chore
+
+* chore(pre-commit): run the no-comments gate through uv
+
+The hook invoked a bare `python`, which does not exist on a machine whose
+only interpreter is the uv-managed one. There it failed with "Executable
+`python` not found" on every commit -- the gate reported Failed without ever
+scanning a file, so a disallowed comment could reach a commit unnoticed.
+
+Every other entry point to this check already goes through uv: the Makefile's
+lint-no-comments target, and the sibling completion-snapshots hook by way of
+make.
+
+Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> ([`b8fa7f0`](https://github.com/caylent-solutions/kanon/commit/b8fa7f0fd7dec7698647b1e0a75e45d80e25ba4f))
+
+### Ci
+
+* ci(windows): resolve runner temp in execution step context ([`45b6677`](https://github.com/caylent-solutions/kanon/commit/45b66775169af7906eea3e5640969d55a0db4987))
+
+* ci(windows): align native store with vendored same-volume requirement ([`184023a`](https://github.com/caylent-solutions/kanon/commit/184023aad380ce0197898a15771a5870f17763e5))
+
+### Fix
+
+* fix: preserve source-directory permission diagnostics ([`f88d9c0`](https://github.com/caylent-solutions/kanon/commit/f88d9c03c218cfd6663a5233d4a2bbf6f0d394f0))
+
+* fix(windows): isolate worker imports and preserve concurrent logs ([`0e39afe`](https://github.com/caylent-solutions/kanon/commit/0e39afe8d606d6eda870853ceead99f9afb4be27))
+
+* fix(add): refresh content and ownership after forced replacement ([`9208978`](https://github.com/caylent-solutions/kanon/commit/920897879c730f36fb183bef6adc466e5e08223d))
+
+* fix: isolate consumer linkfiles across shared-store projects ([`418cae0`](https://github.com/caylent-solutions/kanon/commit/418cae0095ed6a4ff40fc5e5f3b6285f9f760ed4))
+
+* fix(windows): enforce native locking and detached worker contracts ([`8bca79c`](https://github.com/caylent-solutions/kanon/commit/8bca79c1740a6809936cadaaefe13298aa51f90f))
+
+* fix(codeowners): assign Kanon release approvers to all files ([`0dc908b`](https://github.com/caylent-solutions/kanon/commit/0dc908b515276f61efce622d637996820f906a96))
+
+* fix(hooks): stop the pre-push gate corrupting the repository it gates
+
+Git exports GIT_DIR and its siblings to hooks, and pre-push inherits
+them into `make test-unit-cov`. GIT_DIR outranks cwd, so the fixture
+helper in TestResetManifestsWorkingTree -- which passes only a working
+directory to `git init` and `git config` -- wrote into the pushing
+developer's own repository instead of its temp fixture: core.bare=true,
+which breaks every worktree of that repo, and a fixture
+user.name/user.email, which silently reattributed their next commit.
+Both were observed on a real checkout.
+
+Fixed at both ends. The helper scrubs GIT_* from the environment it
+hands git, so cwd means what the helper assumes; a regression test
+builds a fixture repo under a deliberately set GIT_DIR and asserts that
+repository's config is untouched. pre-push unsets the same variables
+after resolving the repo root, so no future test acquires the same
+reach.
+
+Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> ([`065caa2`](https://github.com/caylent-solutions/kanon/commit/065caa20fe5ee1c1d74bea71526fd925e3e544b3))
+
+* fix: linkfile symlink target no longer records checkout depth
+
+A <linkfile> delivering into the consuming project pointed at content in
+the KANON_HOME store, which sits outside the project, so the target was
+measured across the filesystem and its ".." chain recorded how deeply the
+checkout happened to sit on disk. Installing from a git worktree -- three
+directories deeper than the clone containing it -- wrote a
+three-level-longer target: correct there, dangling in every ordinary
+clone, with nothing to signal the difference. One such target was
+committed and merged before anyone noticed.
+
+kanon install now maintains <project-root>/.packages, a gitignored
+symlink into the store's aggregated package directory, and measures the
+target between two project-root-relative paths instead. The result is a
+function of the manifest alone and is byte-identical at every checkout
+depth. kanon clean removes the anchor it created.
+
+Marketplace destinations and any source outside a .packages slot keep
+their existing plain relative target; this narrows a target that would
+otherwise escape the project root, and never widens one.
+
+Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> ([`bbc4aa5`](https://github.com/caylent-solutions/kanon/commit/bbc4aa539e83d5c8c225f8a74408b19a351284c2))
+
+* fix(add): resolve a re-add to the block already declaring that manifest name
+
+kanon add resolved an entry's alias from the source URL and ref alone, so a
+re-add whose coordinates differed at all -- a newer tag, a differently spelled
+catalog URL -- missed the same-alias duplicate check and auto-suffixed into a
+fresh alias. The .kanon file was left with two live source blocks declaring the
+same KANON_SOURCE_<alias>_NAME, a state install has no rule for.
+
+An entry whose manifest name is already declared now resolves to that block's
+alias, whatever source it names and whatever alias the block carries. The
+--force gate is unchanged: a hard error with a diff, or an in-place overwrite
+plus lock re-pin. The auto-suffix candidate sequence still separates distinct
+packages whose names sanitize to one alias.
+
+Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> ([`3018b8f`](https://github.com/caylent-solutions/kanon/commit/3018b8f65a2a1798dbeb72ec2a844eaaccb5a9df))
+
+* fix(lint,format): remove unused import and variable in test_spawn, fix ruff format ([`04ef906`](https://github.com/caylent-solutions/kanon/commit/04ef90619d20fb8363534534a1d0236fbaa2be41))
+
+* fix(concurrency,spawn): add Windows backend for issue #75
+
+- concurrency.py: dispatch _exclusive_kernel_lock to platform-specific
+  backend; add _exclusive_kernel_lock_windows using Win32 LockFileEx +
+  WaitForSingleObject — true kernel-level blocking with no poll loop and
+  no sleep, matching the POSIX SIGALRM approach
+- spawn.py: dispatch spawn_detached to _spawn_detached_windows on win32;
+  Windows backend uses multiprocessing.Process(daemon=False) with the
+  spawn context; _windows_child_target redirects stdin/stdout/stderr
+  before calling refresh_fn
+- doctor.py: remove 'fcntl.flock' reference from stale-lock diagnostic
+- tests/test_spawn.py: add three Windows backend unit tests
+
+Resolves #75 — AttributeError: module 'os' has no attribute 'fork'
+Resolves ModuleNotFoundError: No module named 'fcntl' on Windows ([`7b28799`](https://github.com/caylent-solutions/kanon/commit/7b28799e476504596d6698fba493d494b0ba80cc))
+
+* fix(concurrency,spawn): add Windows backend to resolve issue #75
+
+concurrency.py: add _exclusive_kernel_lock_windows using Win32 LockFileEx
++ WaitForSingleObject via ctypes. Dispatches from _exclusive_kernel_lock
+via sys.platform check. True kernel-level blocking with no poll loop and
+no sleep, matching the POSIX SIGALRM approach. import fcntl / import signal
+remain inside _exclusive_kernel_lock_posix; no unconditional POSIX-only
+import on any CLI startup path.
+
+spawn.py: add _spawn_detached_windows + _windows_child_target using
+multiprocessing.Process(daemon=False) with the spawn context. The callable
+is already picklable (module-level functools.partial, noted in cache.py).
+Dispatches from spawn_detached via sys.platform check. The POSIX path
+(os.fork / os.setsid / os.dup2) is unchanged.
+
+doctor.py: remove platform-specific 'fcntl.flock' reference from the
+STALE_INSTALL_LOCK advisory message.
+
+tests/unit/test_spawn.py: add three tests for the Windows backend covering
+non-daemon process creation, correct args, and fail-fast on start() failure.
+All tests use mocking and run on every platform without skipif.
+
+Fixes #75. ([`f4bd55b`](https://github.com/caylent-solutions/kanon/commit/f4bd55b00c8bd8fb49e15b81ee6051eef5dcb419))
+
+### Refactor
+
+* refactor: narrow duplicate-source fix to add and content refresh ([`b78b792`](https://github.com/caylent-solutions/kanon/commit/b78b7927d37acee40f56aff9bf5b6e1d52c9f39b))
+
+* refactor: simplify the linkfile target computation
+
+Four cleanups, no behaviour change. The depth-independence tests still
+fail without the fix, and the full suite passes with it.
+
+_AnchoredTarget returned either a target or None, leaving both call
+sites to repeat the plain-relpath fallback behind an `or`. It is now
+_LinkTarget, always returns a target, and owns that fallback as its own
+named default, so each call site is a single unconditional expression.
+
+Containment of the dest was decided by prefix arithmetic against the
+project root and then re-derived, as a relative path, on the way out.
+One os.path.relpath now does both: a first component of ".." is what
+"outside the project" means, which is also how the src side already
+reads.
+
+The environment carried <project_root>/.packages, which the vendored
+tool took apart with dirname and basename to recover two facts install
+already had. It now carries KANON_PROJECT_ROOT, and ".packages" is a
+module constant in project.py -- shared with _LINKFILE_EXCLUDE_ALWAYS,
+which had the name as a third literal.
+
+ensure_project_packages_anchor guarded against the store resolving to
+the project root, which requires .kanon to live inside the store. The
+full suite passes without it; it was validation for a case that cannot
+arise, and it cost a nesting level.
+
+Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> ([`4f9e77a`](https://github.com/caylent-solutions/kanon/commit/4f9e77a34120d99d1ee6867074910284d2bd3607))
+
+### Test
+
+* test: resolve the stub temp root so absolute-dest tests pass on macOS
+
+Twenty-one absolute-dest tests failed on every macOS checkout, including
+a clean main, which left `make test-unit` -- and with it the pre-push
+gate -- red regardless of the change under test.
+
+An absolute <linkfile>/<copyfile> dest is refused when any component of
+its path is a symlink, and the platform temp root is one on macOS:
+tempfile puts these fixtures under /var/folders/..., and /var is a
+symlink to /private/var. The resolver was right; the fixtures were not.
+install() resolves the consumer project root before publishing it as a
+permitted root, so a stub checkout standing in for one has to be
+resolved too.
+
+Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> ([`de103e7`](https://github.com/caylent-solutions/kanon/commit/de103e7cfd130b3291be3d972b9305f2734c152a))
+
+### Unknown
+
+* Merge pull request #129 from caylent-solutions/fix/add-same-name-duplicate-source-block
+
+fix(add): resolve a re-add to the block already declaring that manifest name ([`0ac1f1c`](https://github.com/caylent-solutions/kanon/commit/0ac1f1c3ab957529bd9eacbe15fcb11dc9518502))
+
+* Merge remote-tracking branch 'refs/remotes/upstream/main' into review/fix-pr129 ([`5d5f562`](https://github.com/caylent-solutions/kanon/commit/5d5f562459556f3c042cf966fafcae2449dba667))
+
+* Merge pull request #128 from caylent-solutions/chore/pre-commit-no-comments-uv
+
+chore(pre-commit): run the no-comments gate through uv ([`7a0e81f`](https://github.com/caylent-solutions/kanon/commit/7a0e81f2d12616f677be2d94285e9fd5bbd8fd07))
+
+* Merge pull request #122 from caylent-solutions/fix/windows-compat-issue-75
+
+fix(windows): enforce native workspace locks and detached workers ([`a4b0df2`](https://github.com/caylent-solutions/kanon/commit/a4b0df24656e9d8d5ef8730cafa22ba3f68f0a0f))
+
+* Merge pull request #127 from caylent-solutions/fix/linkfile-target-checkout-depth
+
+fix: linkfile symlink target no longer records checkout depth ([`9e41cb2`](https://github.com/caylent-solutions/kanon/commit/9e41cb21cc6a70f91049c79dac1d5e3ea9f3724a))
+
+* Merge pull request #125 from caylent-solutions/dependabot/uv/gitpython-3.1.59
+
+build(deps): bump gitpython from 3.1.58 to 3.1.59 ([`388ba57`](https://github.com/caylent-solutions/kanon/commit/388ba57e075582abc2132c05552a24228d528f74))
+
+* Merge pull request #130 from caylent-solutions/chore/builders-codeowners
+
+chore(codeowners): assign Kanon release approvers to all files ([`b0787c2`](https://github.com/caylent-solutions/kanon/commit/b0787c297622573b03ab37ee64664edf6103026e))
+
+
+## v3.4.1 (2026-08-21)
+
+### Chore
+
+* chore(release): 3.4.1 ([`8a9a35c`](https://github.com/caylent-solutions/kanon/commit/8a9a35cde4985d74f1515f7fa52065809dc21e34))
+
+### Fix
+
+* fix: kanon clean --purge-all no longer orphans the marketplace it registered (#120)
+
+Reported from a real machine, reproduced verbatim.
+
+`kanon clean --purge-all` removed the shared store without first unregistering
+what kanon had put into Claude. Claude was left holding a marketplace whose
+content no longer existed and reported it as `failed to load: cache-miss`.
+
+The state was unrecoverable through kanon. `kanon clean` locates the marketplace
+by enumerating the marketplace directory, which the teardown had already deleted,
+so a follow-up clean reports "Broken symlink detected and skipped" then "No
+marketplace entries found. Nothing to uninstall." and gives up. Fixing it meant
+`claude plugin uninstall` and `claude plugin marketplace remove` by hand.
+
+`.kanon.lock` survives a deleted `.kanon` and records `registered_marketplaces`
+per source. kanon always had the marketplace name, the directory, and the fact it
+had registered it; the teardown simply never read them.
+
+Both machine-wide paths now unregister from that ledger BEFORE removing anything.
+The no-project-found path discovers the lockfile by the same upward walk
+`find_kanonenv` uses; the sourceless-project path reads its sibling. Ordering is
+asserted by test, since unregistering after the delete is precisely what produced
+the orphan.
+
+One of the two paths was mine. `_purge_sourceless_project` shipped in 3.4.0 and
+delegated to the same incomplete teardown, so closing the "cannot purge" bug
+extended this defect to a new path rather than merely inheriting it. It also
+deleted `.kanon.lock`, destroying the only record of what to unregister.
+
+Candidates come only from the lockfile ledger, never from enumerating the
+directory, matching the safety invariant `_prune_orphaned_marketplaces` already
+documents: a marketplace kanon did not register was never written to a ledger and
+cannot be unregistered here. A missing lockfile or empty ledger is not an error
+and does not require claude on PATH.
+
+Verified end to end in a container against a 3.4.0 build: the reported sequence
+now leaves zero marketplaces, zero plugins and no stale lockfile. Guards proven
+falsifiable by reintroducing the defect in both paths. ([`6edc65a`](https://github.com/caylent-solutions/kanon/commit/6edc65a9c5cbe09fc057c370e867abaaf63136f7))
+
+### Unknown
+
+* Merge pull request #121 from caylent-solutions/release-3.4.1
+
+Release 3.4.1 ([`a7f5c31`](https://github.com/caylent-solutions/kanon/commit/a7f5c3113867f270c25e0a7e74a2c27bd68567fa))
+
+
 ## v3.4.0 (2026-08-21)
 
+### Chore
+
+* chore(release): 3.4.0 ([`b361799`](https://github.com/caylent-solutions/kanon/commit/b36179978257a41a2a633de80393ac6a33735dd2))
+
 ### Feature
 
 * feat: multi project installs, safer file delivery, and faster validation (#117)
@@ -1241,6 +1535,12 @@ asserting what its name says. It now sets `purge_all = False` explicitly.
 
 Co-authored-by: Ryan Gross <ryan.gross@caylent.com> ([`f22fe03`](https://github.com/caylent-solutions/kanon/commit/f22fe03f77e3cabfe10822242ed689a8f11e7b73))
 
+### Unknown
+
+* Merge pull request #119 from caylent-solutions/release-3.4.0
+
+Release 3.4.0 ([`cc2e38d`](https://github.com/caylent-solutions/kanon/commit/cc2e38d528fd779ba770b451a8efc114c6c003ef))
+
 
 ## v3.3.3 (2026-08-06)
 

{kanon_cli-3.4.0 → kanon_cli-3.4.2}/CONTRIBUTING.md

@@ -209,6 +209,27 @@ make test-scenarios
 
 A coverage meta test (`tests/scenarios/test_scenario_coverage_meta.py`) fails CI if any in-scope scenario in `docs/integration-testing.md` lacks a matching pytest test. To add a new scenario: add the `### XX-NN: <title>` heading + bash block to `docs/integration-testing.md`, then add a `@pytest.mark.scenario` test under `tests/scenarios/test_<category>.py` that references the scenario ID in its function name or docstring.
 
+### Native Windows acceptance
+
+Run `make test-windows` on native Windows with Git for Windows and symlink
+privileges. The target uses the locked toolchain and executes the native
+contracts plus portable lock/worker unit tests. The dedicated test root avoids
+the existing POSIX process-group harness; it does not skip failing tests in
+that harness or claim that the full suite runs on Windows. Native tests are
+explicitly selected from `tests/native/windows_contracts.py`, so POSIX test
+collection never substitutes mocks for native acceptance.
+
+Worker contracts use a disposable interpreter with the trusted test callbacks
+installed through its site configuration. Workers start in Python isolated
+mode, so neither the current workspace nor `PYTHONPATH` supplies their imports.
+Native regressions cover hostile workspace modules and two workers writing to
+the same append-only log before either worker exits.
+
+The lifecycle fixture enables Git long paths for its child processes and uses
+local disposable repositories. Windows 11 validation and the `windows-latest`
+CI job complement the existing Linux tiers and macOS checks. Authentication and
+the complete vendored repo command surface require separate acceptance.
+
 ### Test Requirements
 
 - **Unit Tests**: Must maintain at least `COVERAGE_MIN` (default 93%) coverage

{kanon_cli-3.4.0 → kanon_cli-3.4.2}/Makefile

@@ -132,3 +132,7 @@ check-completion-snapshots: ## Verify the completion fixtures match generated ou
 		exit 1; \
 	fi; \
 	echo "completion fixtures match generated output"
+
+.PHONY: test-windows
+test-windows: ## Run native Windows contracts and portable utility regressions
+	uv run --locked pytest --confcutdir=tests/native tests/native/windows_contracts.py tests/unit/test_concurrency.py tests/unit/test_spawn.py tests/unit/test_worker.py tests/unit/test_windows_lock_api.py -q

{kanon_cli-3.4.0 → kanon_cli-3.4.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: kanon-cli
-Version: 3.4.0
+Version: 3.4.2
 Summary: Kanon (Kanon Package Manager) CLI tool
 Project-URL: Homepage, https://github.com/caylent-solutions/kanon
 Project-URL: Issues, https://github.com/caylent-solutions/kanon/issues
@@ -113,16 +113,29 @@ via declarative manifests.
 
 ## Platform support
 
-Kanon runs on macOS and Linux. **Windows is not currently supported
-(planned).** Native Windows support is on the roadmap but not yet
-available; in the meantime, run kanon under WSL2 (Windows Subsystem for
-Linux), where the Linux instructions throughout this documentation apply
-unchanged.
-
-The shell-completion docs describe a cross-platform PowerShell Core
-(`pwsh`) completer that also runs on macOS and Linux; see
-[docs/shell-completion.md](docs/shell-completion.md). PowerShell Core
-support is not a claim of native Windows support.
+Kanon runs on macOS and Linux. Native Windows support is experimental.
+The native Windows acceptance job exercises workspace exclusion and timeout,
+detached workers, error logs, directory symlinks, configuration ACL checks, and
+an isolated local-catalog CLI lifecycle. It does not certify the entire vendored
+repo command surface, enterprise VDI policies, or Git OAuth authentication.
+WSL2 remains the established Windows option for the Linux workflows.
+
+Native Windows requires Git for Windows with `core.longpaths=true`, and either
+Windows Developer Mode or the Create symbolic links privilege. Symlinks are
+required; Kanon does not replace them with copies. The `.kanon` file must allow
+writes only to its owner, SYSTEM, or Administrators; inherited grants to other
+users must be removed in Windows Security settings. Unsupported ACL forms are
+rejected rather than treated as secure.
+
+See [Windows setup](docs/git-auth-setup.md#windows-experimental) and
+[PowerShell completion](docs/shell-completion.md). Long paths should also be
+enabled in Windows policy; keep `KANON_HOME` short (for example `C:\kanon`). Git for Windows can still
+reject long `GIT_DIR` paths even with `core.longpaths=true`. The store and Kanon installation must be on the same drive: the vendored repo
+engine creates relative links to its installed hooks and cannot calculate those
+links across drive letters.
+
+Network-share workspaces and
+non-NTFS filesystems have not been validated.
 
 ---
 
@@ -1392,6 +1405,22 @@ permitted root: the consumer project root, the resolved
 [docs/security-model.md](docs/security-model.md) and
 [docs/configuration.md](docs/configuration.md#absolute-manifest-destinations).
 
+A `<linkfile>` delivering into the consuming project reaches the store through
+`<project-root>/.packages` -- a gitignored symlink `kanon install` maintains
+beside `.kanon` -- so the symlink it writes names a target relative to the
+project root:
+
+```text
+.claude/rules -> ../.packages/my-standards/rules
+```
+
+That target is a function of the manifest alone. It is byte-identical whether
+you install from a plain clone or from a git worktree nested inside one, and it
+stays valid when the checkout moves. Do not commit the `.packages` anchor
+itself: it points into your project's private directory in `KANON_HOME`, and
+every developer's `kanon install` creates their own. Installing or cleaning
+another project leaves this project's delivered content unchanged.
+
 ---
 
 ## SSH Authentication Setup
@@ -1536,8 +1565,7 @@ version bumps.
 - [Integration Testing](docs/integration-testing.md) -- End-to-end CLI test
   plan
 - [kanon repo reference](docs/repo/README.md) -- Manifest format, `.repo/`
-  layout, hooks, smart sync, Python support (Windows is not currently
-  supported; see [Platform support](#platform-support) and use WSL2)
+  layout, hooks, smart sync, Python support (native Windows is experimental; see [Platform support](#platform-support))
 - [Contributing](CONTRIBUTING.md) -- How to create and maintain Kanon
   packages and marketplaces
 - [Privacy & Telemetry](docs/privacy.md) -- What usage telemetry kanon

{kanon_cli-3.4.0 → kanon_cli-3.4.2}/README.md

@@ -91,16 +91,29 @@ via declarative manifests.
 
 ## Platform support
 
-Kanon runs on macOS and Linux. **Windows is not currently supported
-(planned).** Native Windows support is on the roadmap but not yet
-available; in the meantime, run kanon under WSL2 (Windows Subsystem for
-Linux), where the Linux instructions throughout this documentation apply
-unchanged.
-
-The shell-completion docs describe a cross-platform PowerShell Core
-(`pwsh`) completer that also runs on macOS and Linux; see
-[docs/shell-completion.md](docs/shell-completion.md). PowerShell Core
-support is not a claim of native Windows support.
+Kanon runs on macOS and Linux. Native Windows support is experimental.
+The native Windows acceptance job exercises workspace exclusion and timeout,
+detached workers, error logs, directory symlinks, configuration ACL checks, and
+an isolated local-catalog CLI lifecycle. It does not certify the entire vendored
+repo command surface, enterprise VDI policies, or Git OAuth authentication.
+WSL2 remains the established Windows option for the Linux workflows.
+
+Native Windows requires Git for Windows with `core.longpaths=true`, and either
+Windows Developer Mode or the Create symbolic links privilege. Symlinks are
+required; Kanon does not replace them with copies. The `.kanon` file must allow
+writes only to its owner, SYSTEM, or Administrators; inherited grants to other
+users must be removed in Windows Security settings. Unsupported ACL forms are
+rejected rather than treated as secure.
+
+See [Windows setup](docs/git-auth-setup.md#windows-experimental) and
+[PowerShell completion](docs/shell-completion.md). Long paths should also be
+enabled in Windows policy; keep `KANON_HOME` short (for example `C:\kanon`). Git for Windows can still
+reject long `GIT_DIR` paths even with `core.longpaths=true`. The store and Kanon installation must be on the same drive: the vendored repo
+engine creates relative links to its installed hooks and cannot calculate those
+links across drive letters.
+
+Network-share workspaces and
+non-NTFS filesystems have not been validated.
 
 ---
 
@@ -1370,6 +1383,22 @@ permitted root: the consumer project root, the resolved
 [docs/security-model.md](docs/security-model.md) and
 [docs/configuration.md](docs/configuration.md#absolute-manifest-destinations).
 
+A `<linkfile>` delivering into the consuming project reaches the store through
+`<project-root>/.packages` -- a gitignored symlink `kanon install` maintains
+beside `.kanon` -- so the symlink it writes names a target relative to the
+project root:
+
+```text
+.claude/rules -> ../.packages/my-standards/rules
+```
+
+That target is a function of the manifest alone. It is byte-identical whether
+you install from a plain clone or from a git worktree nested inside one, and it
+stays valid when the checkout moves. Do not commit the `.packages` anchor
+itself: it points into your project's private directory in `KANON_HOME`, and
+every developer's `kanon install` creates their own. Installing or cleaning
+another project leaves this project's delivered content unchanged.
+
 ---
 
 ## SSH Authentication Setup
@@ -1514,8 +1543,7 @@ version bumps.
 - [Integration Testing](docs/integration-testing.md) -- End-to-end CLI test
   plan
 - [kanon repo reference](docs/repo/README.md) -- Manifest format, `.repo/`
-  layout, hooks, smart sync, Python support (Windows is not currently
-  supported; see [Platform support](#platform-support) and use WSL2)
+  layout, hooks, smart sync, Python support (native Windows is experimental; see [Platform support](#platform-support))
 - [Contributing](CONTRIBUTING.md) -- How to create and maintain Kanon
   packages and marketplaces
 - [Privacy & Telemetry](docs/privacy.md) -- What usage telemetry kanon

{kanon_cli-3.4.0 → kanon_cli-3.4.2}/docs/architecture.md

@@ -104,8 +104,21 @@ Key paths:
   mutation. A stale lock left by a killed process is harmless; the next
   invocation reopens and re-acquires it.
 - **`.packages/`** -- aggregated symlinks pointing into the per-source
-  `.packages/*` entries. This is the only directory operators need to
-  reference in downstream tooling.
+  `.packages/*` entries. This legacy index uses last-install-wins semantics
+  across projects; use the consumer anchor for project-specific content.
+- **`<project-root>/.packages`** -- the anchor: a symlink beside `.kanon`
+  pointing at `.kanon-data/sources/<project_address>/.packages/` in the store.
+  It holds no content of its own. Each project has a private aggregation directory, so another project's
+  install or clean cannot repoint its delivered content. The legacy shared
+  `<store>/.packages/` index remains available to existing downstream tooling.
+  `kanon install` adds the anchor to the project's `.gitignore`. A
+  `<linkfile>` delivering into the consuming project names a target relative to
+  the project root and reaches the store through this anchor, so the target it
+  writes is identical whatever the checkout's depth on disk. Computed against
+  the store directly, the target would instead record that depth: an install run
+  inside a git worktree sits three directories deeper than the clone containing
+  it and would write a three-level-longer target -- correct there, dangling in
+  every ordinary clone. `kanon clean` removes the anchor it created.
 - **`<KANON_HOME>/store/.gitignore`** -- `kanon install` writes this
   safety net (containing `*`) ONLY when the shared `KANON_HOME` store sits
   inside a git working tree, so the fetched-artifact cache is never committed.

{kanon_cli-3.4.0 → kanon_cli-3.4.2}/docs/git-auth-setup.md

@@ -235,17 +235,33 @@ To clear a stale credential on Linux:
    git ls-remote https://git.example.com/<repo>.git
    ```
 
-## Windows (not currently supported -- use WSL2)
-
-Windows is **not currently supported (planned)**: native Windows support is
-on the roadmap but not yet available. In the meantime, run kanon under WSL2
-(Windows Subsystem for Linux) and follow the [Linux](#linux) git-auth
-instructions above -- inside a WSL2 distribution, kanon and git behave
-exactly as they do on Linux, including credential helpers, `ssh-agent`, and
-`url.insteadOf` rewrites.
-
-See the README [Platform support](../README.md#platform-support) note for
-the project-wide statement of supported platforms.
+## Windows (experimental)
+
+Native Windows requires Git for Windows on `PATH`, `core.longpaths=true`, and
+Windows Developer Mode or the Create symbolic links privilege. Enable long
+paths in Windows policy as well. Keep `KANON_HOME` short (for example
+`C:\kanon`): Git for Windows still rejects some long `GIT_DIR` paths even
+with `core.longpaths=true`. Kanon creates directory symlinks and
+fails with an actionable error when Windows denies that privilege.
+
+The store and Kanon installation must be on the same drive: the vendored repo
+engine creates relative links to its installed hooks and cannot calculate those
+links across drive letters.
+
+Kanon checks the `.kanon` file's Windows DACL. Write grants must be limited to
+the file owner, SYSTEM and Administrators (Owner Rights grants are also
+accepted). An inherited write grant to Everyone or Users is rejected. Use the
+file's Security settings to remove those grants; POSIX `chmod` does not secure
+a Windows ACL. Unknown access-control entry types are rejected conservatively.
+
+Git authentication remains Git's responsibility. Configure Git Credential
+Manager for your host, then verify access with `git ls-remote` before running
+Kanon. The native acceptance fixtures use local repositories; they do not
+validate OAuth, corporate credential policies, SSH agents, network shares, or
+the full vendored repo command surface.
+
+WSL2 continues to use the [Linux](#linux) instructions. See
+[Platform support](../README.md#platform-support) for the tested scope.
 
 ## Per-host configuration patterns