michael-cahal-wsc-beta 0.1.0-beta.1

package/CHANGELOG.md

@@ -0,0 +1,44 @@
+# Changelog
+
+All notable changes to this repository should be recorded here.
+
+This project uses task-scoped entries while the beta is being assembled. Each entry should name the task ID, summarize user-visible behavior, and call out any unresolved decisions or compatibility notes.
+
+## Unreleased
+
+### Added
+
+- T15: Added README documentation, usage examples, and changelog conventions.
+- T16: Added package-content verification to CI, tightened the package allowlist,
+  and documented release-readiness checks.
+- T17: Added beta release notes, publication blockers, and tag/publish plan for
+  `0.1.0-beta.1`.
+- T14: Added `wsc explain` for policy-stack explanations in text and markdown.
+- T13: Added `wsc init` for local starter config and company overlay files.
+- T12: Added `wsc eval` for local deterministic evaluation with text, JSON, and markdown reports.
+- T11: Added text, JSON, and markdown reporters for evaluation results.
+- T10: Added deterministic evaluator result contract, scoring metadata, exceptions, and exit-threshold handling.
+- T09: Added deterministic lexical matcher.
+- T08: Added safe local input reading and runtime option normalization.
+- T07: Added overlay validation and commutative merge behavior.
+- T06: Added policy pack loading and validation.
+
+### Notes
+
+- The CLI remains local-only: no network calls, telemetry, remote policy fetch, hosted backend, database, or model-provider integration.
+- `wsc validate` is still planned and not implemented in the current CLI.
+- Policy/content licensing remains provisional during beta; source code is MIT
+  licensed.
+- Beta release authority and package publishing authority are assigned to the
+  human owner during beta.
+- The human owner accepted the canonical inventory for beta and approved
+  `0.1.0-beta.1` publication; release notes are recorded in
+  [docs/releases/0.1.0-beta.1.md](docs/releases/0.1.0-beta.1.md).
+
+## Changelog Conventions
+
+- Use task IDs in entries when changes are task-scoped.
+- Prefer `Added`, `Changed`, `Fixed`, `Removed`, and `Security` headings.
+- Mention command behavior, result-contract changes, fixture changes, and compatibility risks.
+- Do not describe planned features as shipped behavior.
+- Do not include certification, legal compliance, or safety approval language.

package/CONTRIBUTING.md

@@ -0,0 +1,64 @@
+# Contributing
+
+Thank you for contributing to the Western Social Contract CLI.
+This repository is currently in planning mode, and contributions should follow
+a strict task-based process.
+
+## How to contribute
+
+1. Review `AGENTS.md`, `PLANS.md`, `DECISIONS_NEEDED.md`, and the relevant task file.
+2. Create a dedicated branch named `agent/<short-task-name>`.
+3. Keep changes limited to the assigned task.
+4. Open a pull request with a clear summary, files changed, and any blockers.
+
+## Task-based workflow
+
+- Do not implement product code until the relevant planning and spec tasks are complete.
+- Do not create TypeScript source files unless a task explicitly authorizes them.
+- Preserve local-first, no telemetry, no network calls, library-first / CLI-second,
+  deterministic lexical evaluation, and review-aid-only boundaries.
+
+## Policy and governance changes
+
+Policy-sensitive changes require explicit approval and should never be guessed.
+If a decision is unresolved, add it to `DECISIONS_NEEDED.md` and continue only
+with non-blocked planning or documentation work.
+
+Do not make the following changes without approval:
+
+- final canonical principles or principle IDs
+- policy/content license decisions
+- maintainer group membership
+- official overlay status or promotion rules
+- domain-review requirements
+- compatibility claim language
+- package ownership or publishing authority
+- certification or legal claims
+
+## Branching and commits
+
+- Branches must be task-scoped.
+- Commits should use the format `<task-id>: <short imperative summary>`.
+- Keep pull requests small and focused.
+
+## Changelog entries
+
+- Add or update `CHANGELOG.md` for user-visible behavior, command changes,
+  result-contract changes, examples, release notes, and security-relevant changes.
+- Use task IDs in unreleased entries while beta tasks are being assembled.
+- Do not describe planned commands as current behavior.
+- Do not use changelog language that implies certification, legal compliance,
+  safety approval, or regulatory endorsement.
+
+## Tests and quality
+
+- When implementation exists, add tests for any new behavior.
+- Reviewers should verify that changes preserve the project’s policy and security guardrails.
+- Before marking a task complete, run the standard quality steps when available.
+- Documentation-only changes should still run formatting and any relevant
+  example validation commands.
+
+## Reporting issues
+
+If you discover a security or governance concern, report it through the
+git repository issue tracker and note it in the relevant task.

package/GOVERNANCE.md

@@ -0,0 +1,77 @@
+# Governance
+
+## Purpose
+
+This document describes the governance principles and review process for the
+Western Social Contract CLI repository.
+
+## Governance principles
+
+The project is a policy pack and reusable library first, CLI second. It is
+maintained as a local review aid with a strict no-certification and
+no-network posture.
+
+## Maintainers
+
+The initial maintainer group is not yet finalized.
+No individual maintainer names are listed here until the human owner or
+approved governance process confirms them.
+
+### Decision authority
+
+- The human owner is the product and policy authority.
+- During the beta period, the human owner is the sole beta-release approver.
+  Every public beta release requires explicit human-owner approval.
+- Maintainers are responsible for reviewing and approving changes once
+  officially appointed.
+- Changes to canonical policy, licensing, governance, or release decisions
+  require explicit approval before merging.
+
+## Governance process
+
+1. Use task files to scope work.
+2. Create a dedicated branch for each task.
+3. Keep commits small and focused.
+4. Record unresolved policy or governance decisions in `DECISIONS_NEEDED.md`.
+5. Do not implement policy or governance changes without human owner approval.
+
+## Policy-sensitive changes
+
+The following changes require explicit escalation and approval:
+
+- canonical principle inventory and IDs
+- policy content license
+- initial maintainer group membership
+- official vs. experimental overlay promotion rules
+- domain-review requirements for sensitive areas
+- compatibility claim language
+- package ownership and npm publishing authority
+- any certification or legal claim
+- any release or publication decision
+
+## Contribution review
+
+Policy-sensitive pull requests should include:
+
+- a clear task scope,
+- relevant decision notes from `DECISIONS_NEEDED.md`,
+- documentation of unresolved blockers,
+- a human owner or maintainer signoff when required.
+
+## Release readiness
+
+Public beta release requires documented review of all legal, governance,
+security, and licensing requirements.
+
+Until the maintainer group is finalized, the human owner is the sole
+beta-release approver. Each beta release must be approved by the human owner.
+This beta-release approval requirement is per release and does not create
+standing approval for future beta versions.
+
+During the beta period, the npm package is owned by the human owner and only
+the human owner may publish `@western-social-contract/wsc`.
+
+## Updates
+
+This governance document may be updated when the maintainer group and policy
+license are finalized. Until then, use it as a provisional guardrail.

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Western Social Contract CLI contributors
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+authors OR copyright holders BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/POLICY_LICENSE.md

@@ -0,0 +1,54 @@
+# Policy Content License
+
+This repository contains two distinct categories of material:
+
+- Source code, tooling, tests, and package metadata.
+- Policy content and interpretive materials.
+
+## Source code license
+
+The source code in this repository is licensed under the MIT License.
+See `LICENSE` for full terms.
+
+## Policy content license status
+
+Policy content is provided under provisional beta terms for evaluation only.
+Final content licensing will be resolved before a stable public release.
+
+Policy content and interpretive materials may not be redistributed,
+republished, sold, or represented as an official Catholic, Church, or
+institutional policy product.
+
+This document is not a final license grant for policy content. Do not use the
+policy pack, matcher phrases, overlays, examples, fixtures, canonical
+references, or governance text as a basis for compatibility claims,
+certification claims, or commercial re-use.
+
+## Policy content scope
+
+For beta licensing purposes, policy content and interpretive materials include:
+
+- policy pack Markdown and YAML;
+- principle mappings;
+- matcher phrases and matcher metadata;
+- canonical references;
+- official and experimental overlays;
+- exception examples;
+- examples and test fixtures;
+- reporter expected-output fixtures when they encode policy behavior;
+- governance, compatibility, and policy interpretation materials.
+
+## What this means
+
+- Policy content should be treated as provisional beta material for evaluation
+  only until the license is finalized.
+- Any third party wishing to reuse, redistribute, republish, sell, or build
+  official claims from policy content should wait until this document is updated
+  with an explicit final content license.
+- Do not assume MIT applies to policy content unless this document is updated
+  to say so.
+
+## Next step
+
+A definitive stable-release policy/content license decision must be recorded in
+`DECISIONS_NEEDED.md` and reflected here before a stable public release.