Metadata-Version: 2.4
Name: cf-bootstrap-source-local
Version: 0.1.2
Summary: Offline deterministic Stonecastle local repository artifact resolver.
Author: Cogniflow Maintainers
License: GPL-3
Requires-Python: >=3.11
Requires-Dist: cf-bootstrap-source-pypi==0.1.18
Requires-Dist: packaging<27,>=24
Requires-Dist: rdflib<8,>=7
Description-Content-Type: text/markdown

# Local repository artifact resolver

`cf-bootstrap-source-local` converts a Stonecastle source checkout into a verified, offline installation bundle. It is the artifact-source implementation used by Local Repository Mode.

## Installation role

The resolver validates the direct first-party project inventory and semantic-navigation index, loads the selected installation profile, reads its canonical `hasCapabilityRequest` relations from local TriG, and discovers matching service operations from indexed service semantics. This discovery is deliberately local because it runs before Fuseki or the production semantic graph exists.

For the selected providers it computes the first-party dependency closure, validates bounded external wheels, builds non-editable wheels, packages declared native artifacts, and publishes an immutable `artifact-set.json` with source, index, profile, catalog, selection, artifact, and native-authority digests. Bootstrap and post-handoff phases are resolved separately so only required components enter each transaction.

## Protocol and boundaries

The console script implements `cf.bootstrap.artifact-resolver.v1` as one-request/one-response JSON lines. Principal inputs are a canonical bootstrap plan, phase, checkout path, artifact output root, and explicit external wheelhouse. Outputs are a canonical artifact-resolution result, provider map, selection evidence, and wheelhouse.

The resolver never installs into the target, creates the instance environment, starts services, contacts a SPARQL endpoint, or mutates the checkout. Network access is not used for first-party resolution; external dependencies must already be present in the bounded wheelhouse. Target application belongs to `cf-bootstrap-instance`, while orchestration belongs to `cf-bootstrap-orchestrator`.
