@modulify/validator 0.2.0 → 0.2.1

package/.yarnrc.yml

@@ -1,5 +0,0 @@
-enableGlobalCache: false
-
-nodeLinker: node-modules
-
-yarnPath: .yarn/releases/yarn-4.12.0.cjs

package/AGENTS.md

@@ -1,82 +0,0 @@
-# AGENTS.md
-
-## Goals
-- Avoid clarification loops by proposing a concrete interpretation when details are missing.
-- Default to the language of the user's initial message unless they explicitly request a different language.
-- Match the tone and formality of the user's initial message unless they explicitly ask for a change.
-- Treat a language switch in the user's message as an explicit request to respond in that language.
-- If a message is mixed-language, reply in the dominant language unless the user specifies otherwise.
-- Run `yarn lint` before handoff or commit preparation when changed files include code covered by eslint rules.
-- Run `yarn typecheck` before handoff or commit preparation when changed files can affect TypeScript types or module resolution.
-- Run `yarn test` before handoff or commit preparation when changed files can affect runtime behavior.
-- Run `yarn build` before handoff or commit preparation when changed files can affect package exports, bundling, or generated declarations.
-- Do not run the full code check pipeline for markdown-only changes unless the user explicitly asks for it.
-- Do not edit generated artifacts under `dist/` or reports under `coverage/` unless the task explicitly requires it.
-
-## Reporting
-- Keep handoff reports natural and outcome-focused: describe what was done.
-- Do not proactively list skipped optional checks unless the user explicitly asks.
-- Always mention blockers, failed required checks, or other omissions that can affect correctness, safety, or reproducibility.
-
-## Purpose
-This file defines practical instructions for working in the `modulify/validator` repository, with a focus on validation-library development, checks, and local project skills.
-
-## Repository Structure
-- This project is a single-package TypeScript library.
-- Package name: `@modulify/validator`.
-- Main source directories:
-  - `src/` - runtime implementation
-  - `src/runners/` - recursive validation runners
-  - `tests/` - vitest test suite
-  - `types/` - public type declarations and shared typing surface
-- Build output directory: `dist/`.
-- Coverage output directory: `coverage/`.
-
-## Local Environment Prerequisites
-- CI runs on Node `22.x` and `24.x`; prefer Node `22+` locally.
-- Install dependencies with:
-```bash
-yarn install
-```
-
-## Running Checks
-
-### Main Scripts
-- Lint:
-```bash
-yarn lint
-```
-- Type check:
-```bash
-yarn typecheck
-```
-- Test:
-```bash
-yarn test
-```
-- Coverage:
-```bash
-yarn test:coverage
-```
-- Build:
-```bash
-yarn build
-```
-
-### Suggested Validation Order For Code Changes
-```bash
-yarn lint
-yarn typecheck
-yarn test
-yarn build
-```
-
-## Important Project Rules
-- Commit messages follow Conventional Commits.
-- Before creating any commit, always reread `skills/commit-workflow/SKILL.md` and follow it as the source of truth for commit splitting, wording, scopes, and lockfile policy.
-- Getter/helper functions must be free of side effects. Side effects are allowed only by prior agreement and only when there are strong, explicit reasons.
-
-## Local Skills
-- `skills/commit-workflow/SKILL.md` - rules for splitting changes into commits and writing changelog-friendly Conventional Commit messages.
-- `skills/coverage-recovery/SKILL.md` - workflow for analyzing uncovered code paths and improving test coverage without adding artificial tests.
-- `skills/yarn-lock-conflict-resolution/SKILL.md` - safe procedure for resolving `yarn.lock` conflicts during merge or rebase.

package/CODE_OF_CONDUCT.md

@@ -1,128 +0,0 @@
-# Contributor Covenant Code of Conduct
-
-## Our Pledge
-
-We as members, contributors, and leaders pledge to make participation in our
-community a harassment-free experience for everyone, regardless of age, body
-size, visible or invisible disability, ethnicity, sex characteristics, gender
-identity and expression, level of experience, education, socio-economic status,
-nationality, personal appearance, race, religion, or sexual identity
-and orientation.
-
-We pledge to act and interact in ways that contribute to an open, welcoming,
-diverse, inclusive, and healthy community.
-
-## Our Standards
-
-Examples of behavior that contributes to a positive environment for our
-community include:
-
-* Demonstrating empathy and kindness toward other people
-* Being respectful of differing opinions, viewpoints, and experiences
-* Giving and gracefully accepting constructive feedback
-* Accepting responsibility and apologizing to those affected by our mistakes,
-  and learning from the experience
-* Focusing on what is best not just for us as individuals, but for the
-  overall community
-
-Examples of unacceptable behavior include:
-
-* The use of sexualized language or imagery, and sexual attention or
-  advances of any kind
-* Trolling, insulting or derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or email
-  address, without their explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
-  professional setting
-
-## Enforcement Responsibilities
-
-Community leaders are responsible for clarifying and enforcing our standards of
-acceptable behavior and will take appropriate and fair corrective action in
-response to any behavior that they deem inappropriate, threatening, offensive,
-or harmful.
-
-Community leaders have the right and responsibility to remove, edit, or reject
-comments, commits, code, wiki edits, issues, and other contributions that are
-not aligned to this Code of Conduct, and will communicate reasons for moderation
-decisions when appropriate.
-
-## Scope
-
-This Code of Conduct applies within all community spaces, and also applies when
-an individual is officially representing the community in public spaces.
-Examples of representing our community include using an official e-mail address,
-posting via an official social media account, or acting as an appointed
-representative at an online or offline event.
-
-## Enforcement
-
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported to the community leaders responsible for enforcement at
-docs: CODE_OF_CONDUCT.md.
-All complaints will be reviewed and investigated promptly and fairly.
-
-All community leaders are obligated to respect the privacy and security of the
-reporter of any incident.
-
-## Enforcement Guidelines
-
-Community leaders will follow these Community Impact Guidelines in determining
-the consequences for any action they deem in violation of this Code of Conduct:
-
-### 1. Correction
-
-**Community Impact**: Use of inappropriate language or other behavior deemed
-unprofessional or unwelcome in the community.
-
-**Consequence**: A private, written warning from community leaders, providing
-clarity around the nature of the violation and an explanation of why the
-behavior was inappropriate. A public apology may be requested.
-
-### 2. Warning
-
-**Community Impact**: A violation through a single incident or series
-of actions.
-
-**Consequence**: A warning with consequences for continued behavior. No
-interaction with the people involved, including unsolicited interaction with
-those enforcing the Code of Conduct, for a specified period of time. This
-includes avoiding interactions in community spaces as well as external channels
-like social media. Violating these terms may lead to a temporary or
-permanent ban.
-
-### 3. Temporary Ban
-
-**Community Impact**: A serious violation of community standards, including
-sustained inappropriate behavior.
-
-**Consequence**: A temporary ban from any sort of interaction or public
-communication with the community for a specified period of time. No public or
-private interaction with the people involved, including unsolicited interaction
-with those enforcing the Code of Conduct, is allowed during this period.
-Violating these terms may lead to a permanent ban.
-
-### 4. Permanent Ban
-
-**Community Impact**: Demonstrating a pattern of violation of community
-standards, including sustained inappropriate behavior,  harassment of an
-individual, or aggression toward or disparagement of classes of individuals.
-
-**Consequence**: A permanent ban from any sort of public interaction within
-the community.
-
-## Attribution
-
-This Code of Conduct is adapted from the [Contributor Covenant][homepage],
-version 2.0, available at
-https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
-
-Community Impact Guidelines were inspired by [Mozilla's code of conduct
-enforcement ladder](https://github.com/mozilla/diversity).
-
-[homepage]: https://www.contributor-covenant.org
-
-For answers to common questions about this code of conduct, see the FAQ at
-https://www.contributor-covenant.org/faq. Translations are available at
-https://www.contributor-covenant.org/translations.

package/docker/services/node/Dockerfile

@@ -1,9 +0,0 @@
-FROM node:24
-
-WORKDIR /project
-
-RUN corepack enable && corepack prepare yarn@4.12.0 --activate \
-  && test "$(yarn --version)" = "4.12.0" \
-  && mkdir -p /home/node/.cache/node \
-  && cp -a /root/.cache/node/corepack /home/node/.cache/node/corepack \
-  && chown -R node:node /home/node/.cache

package/drafts/.gitignore

@@ -1,2 +0,0 @@
-*
-!.gitignore

package/skills/commit-workflow/SKILL.md

@@ -1,93 +0,0 @@
----
-name: commit-workflow
-description: Use this skill when creating git commits in this repository. It standardizes commit splitting, Conventional Commit type selection, optional subsystem scopes, changelog-friendly phrasing, and commitlint constraints.
----
-
-# Commit Workflow
-
-## When To Use
-Use this skill when the user asks to:
-- create one or more commits;
-- split changes into separate commits;
-- choose commit messages, types, or scopes;
-- validate commit formatting before committing.
-
-## Mandatory First Step
-Before creating any commit in this repository, reread this skill from the top and treat it as the current source of truth for commit wording, scopes, splitting, and lockfile policy.
-
-## Source Of Truth
-- `AGENTS.md`
-- `.commitlintrc.json`
-
-## Required Rules
-- Commit format: Conventional Commits.
-- Message language: English by default.
-- Subject style: describe a completed historical change, not an intention.
-- Start commit subject description with an uppercase letter.
-- Keep commit subject description concise.
-- Put long details into the commit body; lists in body are allowed.
-- Use past/perfective wording; prefer passive voice when it reads naturally for changelogs.
-Examples: `Added ...`, `Removed ...`, `Refactored ...`, `Fixed ...`, `Updated ...`.
-- Allowed types: `feat`, `fix`, `build`, `ci`, `perf`, `docs`, `refactor`, `style`, `test`, `chore`.
-- This repository is a single package, so scope is optional.
-- If scope improves clarity, use a real subsystem scope such as:
-  `assertions`, `predicates`, `runners`, `types`, `build`, `tests`.
-- Do not invent synthetic scopes just to imitate release automation.
-- Breaking changes: use `!` in header or a `BREAKING CHANGE` footer.
-- Do not mix unrelated changes in one commit.
-- Always commit `yarn.lock` changes in a dedicated commit with no other files.
-- For a `yarn.lock`-only commit, use the exact header: `chore: Updated yarn.lock`.
-- Do not amend or rewrite history unless explicitly requested.
-
-## Commitlint Constraints
-- Header max length: `200`
-- Body line max length: `200`
-- Footer line max length: `200`
-- `subject-case: never`
-
-## Workflow
-1. Inspect pending changes:
-```bash
-git status --short
-git diff
-```
-2. Group files by logical intent.
-Keep code, docs, lockfile, and generated artifacts separated when they represent different changes.
-3. If `yarn.lock` changed, split it into a dedicated commit.
-4. Choose commit type and optional scope.
-5. Compose the header:
-```text
-<type>(<scope>): <Short description>
-```
-If scope is not useful, omit it:
-```text
-<type>: <Short description>
-```
-6. Stage only the target files:
-```bash
-git add <files>
-```
-7. Create the commit non-interactively:
-```bash
-git commit -m "<type>(<scope>): <Description>"
-```
-8. Verify the result:
-```bash
-git show --name-status --oneline -n 1
-```
-
-## Practical Patterns
-- Public API redesign:
-`feat!: Assertion API was redesigned around structured violations`
-- Assertion internals cleanup:
-`refactor(assertions): Assertion helpers were simplified`
-- Type-only adjustment:
-`refactor(types): Public assertion types were updated`
-- Test coverage update:
-`test: Assertion coverage was expanded`
-- Build/config change:
-`build: Vite entrypoints were updated`
-- Documentation update:
-`docs: README was updated`
-- Lockfile refresh:
-`chore: Updated yarn.lock`

package/skills/coverage-recovery/SKILL.md

@@ -1,68 +0,0 @@
----
-name: coverage-recovery
-description: Use this skill when coverage is below target or when uncovered validator, predicate, runner, or build-related paths must be analyzed and resolved with minimal artificial tests.
----
-
-# Coverage Recovery
-
-## When To Use
-Use this skill when the user asks to:
-- increase test coverage;
-- analyze uncovered lines or branches;
-- explain why specific uncovered paths remain;
-- improve confidence around assertions, predicates, runners, or validation edge cases.
-
-## Source Of Truth
-- `AGENTS.md`
-- `vitest.config.ts`
-- `package.json`
-- `coverage/` HTML reports
-
-## Principles
-- Coverage is a quality signal, not a vanity metric.
-- Start from real public API behavior.
-- Prefer fixing architecture or removing dead code over adding synthetic tests for impossible paths.
-- Defensive branches should be tested with controlled failure scenarios.
-- Keep type-level and runtime behavior aligned; run `yarn typecheck` together with coverage work when typings are touched.
-
-## Workflow
-1. Collect facts:
-```bash
-yarn test:coverage
-```
-2. Read uncovered details, not only percentages.
-Use:
-- `coverage/index.html`
-- `coverage/lcov-report/index.html` if present
-3. Classify uncovered paths:
-- `real usage gap` - missed public scenario,
-- `defensive path` - malformed input or runtime failure,
-- `dead/redundant path` - likely removable,
-- `architecture smell` - design makes real testing awkward.
-4. Resolve in this order:
-- add or adjust tests for real public API scenarios,
-- add controlled break/failure tests for defensive branches,
-- simplify or remove dead branches,
-- propose architecture refactor for smell cases.
-5. Re-run checks:
-```bash
-yarn lint
-yarn typecheck
-yarn test:coverage
-```
-
-## Controlled Failure Patterns
-- Invalid values passed into assertions or runners.
-- Rejected async assertions.
-- Unsupported object/array shapes for recursive validators.
-- Type guard mismatches between runtime checks and declared narrowing.
-- Export or build-path regressions surfaced only after refactors.
-
-## Stop Condition
-If progress stalls after reasonable attempts:
-1. Stop brute-force test additions.
-2. Report exact uncovered locations and why they are hard or non-natural.
-3. Offer concrete options:
-- accept remaining defensive uncovered paths,
-- refactor the implementation to make behavior testable,
-- remove redundant branches if behavior is impossible by construction.

package/skills/yarn-lock-conflict-resolution/SKILL.md

@@ -1,69 +0,0 @@
----
-name: yarn-lock-conflict-resolution
-description: Use this skill when resolving merge or rebase conflicts in yarn.lock. It standardizes taking yarn.lock from the target branch as source of truth, then running yarn install, and reusing the previous successful resolution as the base for repeated conflict rounds.
----
-
-# Yarn.lock Conflict Resolution
-
-## When To Use
-Use this skill when:
-- `yarn.lock` has merge or rebase conflicts;
-- conflict resolution must follow repository policy;
-- the same conflict has to be resolved multiple times during one rebase chain.
-
-## Source Of Truth Policy
-- During rebase, always take `yarn.lock` from the branch you rebase onto.
-- During merge, always take `yarn.lock` from the current target branch (`HEAD`).
-- After taking that baseline, run:
-```bash
-yarn install
-```
-
-## Required Rules
-- Do not manually edit conflict markers in `yarn.lock`.
-- Resolve by replacing the whole `yarn.lock` file from the selected baseline.
-- For repeated conflict rounds, use the previous successful `yarn.lock` resolution as the new base.
-- If the current change intentionally updated dependencies, replay that dependency intent after conflict resolution and recreate a dedicated `chore: Updated yarn.lock` commit.
-
-## Workflow
-1. Ensure the conflict exists:
-```bash
-git status --short
-```
-2. Resolve first conflict round during rebase:
-```bash
-ONTO=$(cat .git/rebase-merge/onto 2>/dev/null || cat .git/rebase-apply/onto)
-git show "$ONTO:yarn.lock" > yarn.lock
-yarn install
-git add yarn.lock
-cp yarn.lock .git/yarn-lock-resolution-base
-```
-3. Resolve first conflict round during merge:
-```bash
-git show "HEAD:yarn.lock" > yarn.lock
-yarn install
-git add yarn.lock
-cp yarn.lock .git/yarn-lock-resolution-base
-```
-4. Resolve repeated conflict rounds in the same sequence:
-```bash
-cp .git/yarn-lock-resolution-base yarn.lock
-yarn install
-git add yarn.lock
-cp yarn.lock .git/yarn-lock-resolution-base
-```
-5. Continue the operation:
-```bash
-git rebase --continue
-# or
-git merge --continue
-```
-6. Cleanup after completion:
-```bash
-rm -f .git/yarn-lock-resolution-base
-```
-
-## Validation
-- `git status --short` must not show conflict markers for `yarn.lock`.
-- `yarn.lock` must be staged before `--continue`.
-- The resolution must follow the source-of-truth policy above.