rdflib-reasoning 0.1.0.post1.dev83__tar.gz

rdflib_reasoning-0.1.0.post1.dev83/.cursor/skills/assess-release-readiness/SKILL.md

@@ -0,0 +1,154 @@
+# Assess Release Readiness
+
+This skill defines release-readiness quality gates for packages and metapackages in this
+repository.
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
+"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
+interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
+
+## How to use this skill
+
+When asked to assess whether a release is ready:
+
+1. Identify the intended release target and which packages are in scope.
+2. Evaluate each gate below against the current repository state, CI configuration,
+   documentation, and packaging metadata.
+3. Report findings grouped as:
+   - `Release blockers`: failed MUST gates.
+   - `Follow-up recommended`: failed SHOULD gates.
+   - `Evidence checked`: commands, files, workflows, or artifacts reviewed.
+4. If the assessment reveals a missing workflow, missing documentation, or missing packaging
+   metadata, recommend the smallest coherent fix that would satisfy the gate.
+
+## Release Blockers
+
+The following gates MUST pass before a package or metapackage is considered ready to release.
+
+### Packaging and Distribution
+
+- [ ] Does every in-scope package build successfully as both an `sdist` and a wheel from a
+      clean checkout?
+- [ ] Do built artifacts pass `twine check`?
+- [ ] Does the version reported by packaging metadata resolve correctly from the intended git
+      tag or release version source?
+- [ ] Do package metadata fields include the minimum expected modern packaging information?
+  - [ ] Name
+  - [ ] Version source
+  - [ ] Description
+  - [ ] `readme`
+  - [ ] `requires-python`
+  - [ ] License metadata
+  - [ ] Dependencies
+  - [ ] Useful project URLs where applicable
+- [ ] Can each published artifact be installed into a clean environment from the built
+      distribution, not only from an editable workspace checkout?
+- [ ] After installation, do the documented top-level imports and at least one quick-start path
+      execute successfully?
+
+### CI and Verification
+
+- [ ] Does the primary CI pipeline execute linting, tests, and artifact builds for the in-scope
+      packages?
+- [ ] Is code coverage produced and surfaced in CI for feature branches and the default branch?
+- [ ] Are release workflows configured to build the same artifacts that will be published?
+- [ ] Has the release path been exercised against TestPyPI or an equivalent non-production
+      target?
+- [ ] Are required repository secrets, environments, and permissions configured for publishing?
+
+### Versioning and Release Management
+
+- [ ] Is there a clear release note or changelog entry describing the user-visible contents of
+      the release?
+- [ ] Are breaking changes, deprecations, or migration steps called out explicitly when they
+      exist?
+- [ ] Does the release process avoid ambiguous version states such as mismatched tags and
+      package metadata?
+- [ ] If this repository publishes multiple related packages, is the intended versioning policy
+      across those packages documented and followed?
+
+### Security and Supply Chain
+
+- [ ] Are GitHub Actions and other release-critical automation dependencies maintained through a
+      documented update path such as Dependabot?
+- [ ] Are there any unresolved critical or high-severity security issues in release-critical
+      dependencies?
+- [ ] Are release-time dependencies and workflows pinned or constrained appropriately to reduce
+      accidental drift?
+
+## Recommended Gates
+
+The following gates SHOULD pass before release unless there is an explicit reason to defer them.
+
+### User Experience
+
+- [ ] Does the root `README.md` provide quick-start tutorials for the most important system use
+      cases?
+- [ ] Do `rdflib-reasoning*/README.md` files provide quick-start tutorials for their subsystem
+      use cases?
+- [ ] Do all READMEs reflect the current released API rather than only the current development
+      branch?
+- [ ] Is python documentation generated and published as part of deployment?
+- [ ] Are best practices for modern technical documentation being adhered to in all
+      human-facing Markdown files?
+- [ ] Does the root `README.md` show release-relevant status indicators such as supported Python
+      versions, package version, and coverage where appropriate?
+
+### Developer Experience
+
+- [ ] Does `.github/CONTRIBUTING.md` cover everything needed for someone to onboard to
+      developing with the system?
+  - [ ] `.github/CONTRIBUTING.md` MUST explain how agents are used in the development process
+        and what content is aimed at them.
+  - [ ] `.github/CONTRIBUTING.md` MUST explain what `.cursor/skills/` exist and when to invoke
+        them.
+  - [ ] `.github/CONTRIBUTING.md` MUST link to `docs/example-chats/README.md` so that
+        contributors can see examples of working with an agent.
+- [ ] Are local development, validation, and release rehearsal commands documented and current?
+- [ ] Can a new contributor determine how to cut a release without reverse-engineering CI
+      workflows?
+
+### Compatibility and Maintenance
+
+- [ ] Does CI exercise the supported Python version matrix and any important operating-system
+      combinations?
+- [ ] Are dependency ranges compatible with the intended support policy rather than relying on
+      unbounded optimism?
+- [ ] Are public API stability expectations documented for consumers of the packages?
+- [ ] Is there a documented policy for deprecations and removals if the project expects external
+      users?
+
+## Evidence Sources
+
+When assessing release readiness, Development Agents SHOULD inspect the following when relevant:
+
+- Root `README.md`
+- `rdflib-reasoning*/README.md`
+- Root and subproject `pyproject.toml` files
+- `Makefile`
+- `.github/workflows/*.yml`
+- `.github/release-drafter.yml`
+- `.github/dependabot.yml`
+- `.github/CONTRIBUTING.md`
+- Published-package documentation configuration, if any
+- Build artifacts produced locally or in CI
+
+## Assessment Output Template
+
+The final assessment SHOULD be structured like this:
+
+### Release blockers
+
+- List every failed MUST gate with a short explanation and evidence.
+
+### Follow-up recommended
+
+- List every failed SHOULD gate with a short explanation and evidence.
+
+### Evidence checked
+
+- List commands run, files inspected, workflows reviewed, and artifacts validated.
+
+### Conclusion
+
+- State whether the release is ready now, ready with caveats, or not ready.

rdflib_reasoning-0.1.0.post1.dev83/.cursor/skills/critique-project/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: critique-project
+description: Conduct a repository-wide technical critique grounded in current state, git history, and honest evidence-backed assessment.
+---
+
+# Critique Project
+
+- You are acting as the **Critique Agent** defined in the repository root [AGENTS.md](../../../AGENTS.md).
+- You MUST NOT assume this role unless the user explicitly asks for a holistic critique, technical review, portfolio assessment, due diligence review, or invokes this skill.
+- You MAY inspect any repository path that is relevant to the critique, including paths that local `AGENTS.md` files normally restrict for Development Agents.
+- You MUST be candid, evidence-backed, and professionally skeptical. Do not smooth over weaknesses, and do not manufacture praise.
+- You MUST distinguish among observed evidence, reasonable inference, and subjective judgment.
+- You SHOULD treat non-normative materials as signals about process and project evolution, not as authoritative specifications.
+
+## 1. Review goals
+
+When this skill is used, the critique SHOULD cover both repository history and the current repository state.
+
+- Review git history to infer and describe project evolution, emerging designs, demonstrated principles, software-agent accessibility, and system development methodology.
+- Review the repository as it exists now to assess system maturity, SDLC discipline, trajectory, agent accessibility, and feature coverage.
+- When the user wants a portfolio-oriented read, infer what the work suggests about the engineer's strengths, judgment, and likely contributions to a team.
+
+## 2. Evidence collection
+
+- Inspect recent and strategically important git history rather than only the latest diff.
+- Read the root `README.md`, root `AGENTS.md`, `docs/dev/architecture.md`, `docs/dev/roadmap.md`, and relevant decision records before drawing broad conclusions.
+- Inspect representative code, tests, and package boundaries so the critique is not documentation-only.
+- Review repository structure, local `AGENTS.md` files, and any review-relevant non-normative artifacts when they help explain how the project is developed.
+
+## 3. Critique method
+
+- Start by identifying the repository's intended purpose, target audience, and current release posture.
+- Then compare the documented intent against the present implementation and test surface.
+- Highlight both strengths and liabilities in design clarity, execution discipline, project hygiene, and developer/research-agent ergonomics.
+- Prefer concrete claims such as "the project demonstrates X because Y and Z" over vague characterizations.
+- Call out ambiguity, drift, missing validation, incomplete features, or process smells directly.
+
+## 4. Output expectations
+
+The critique SHOULD usually include these sections:
+
+1. Project evolution and emerging design
+2. Current maturity and SDLC assessment
+3. Agent accessibility and repository usability
+4. Feature coverage, gaps, and trajectory
+5. Honest portfolio read
+
+## 5. Portfolio read rules
+
+- This section is OPTIONAL unless the user asks for it or it is clearly relevant.
+- Treat it as an inference from repository evidence, not a claim about the engineer's full background.
+- Describe what the work suggests the engineer brings to the table: technical taste, systems thinking, rigor, follow-through, communication quality, and research orientation.
+- Avoid unsupported claims about seniority, hiring fit, or personal traits.
+- If the signal is mixed, say so plainly.
+
+## 6. Response style
+
+- Lead with the most decision-useful findings, not with compliments.
+- Be fair, but do not optimize for comfort over truth.
+- Use enough supporting evidence that another reviewer could audit your reasoning.
+- If evidence is incomplete, say what you checked and what remains uncertain.

rdflib_reasoning-0.1.0.post1.dev83/.cursor/skills/new-decision-record/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: new-decision-record
+description: Infer a decision record from the current chat and write it as a new DR under docs/dev/decision-records using the template. Use when the user asks to create or record a decision from the conversation, or to write a DR/ADR.
+---
+
+# New Decision Record
+
+Create a new decision record from the current conversation. Follow [docs/dev/decision-records/AGENTS.md](docs/dev/decision-records/AGENTS.md) for all DR rules (location, naming, INDEX, architecture, supersedes).
+
+## Workflow
+
+1. **Infer** – From the conversation, extract: title/topic, context (why), decision (what), consequences (outcomes).
+
+2. **Next number** – List `DR-*.md` in `docs/dev/decision-records/`; take the maximum number + 1, zero-pad to three digits (e.g. 001, 002).
+
+3. **Write** – Create `docs/dev/decision-records/DR-XXX Short Title.md` using [docs/dev/decision-records/template.md](docs/dev/decision-records/template.md). Use the section headings: Title, Status, Context, Decision, Consequences, Supersedes (if applicable). Filename pattern: `DR-XXX` followed by a space and a short title.
+
+4. **Index** – Append a row to [docs/dev/decision-records/INDEX.md](docs/dev/decision-records/INDEX.md): Record Date (YYYY-MM-DD), link to the new record, Supercedes (link) if any, Superceded By (leave empty), Comment (optional).
+
+5. **Supersedes** – If this DR supersedes any document: list and link them in the new DR’s Supersedes section; add “Superseded by [DR-XXX](DR-XXX Title.md)” to those documents’ Status; update their INDEX row “Superceded By” with a link to the new DR; set the new DR’s INDEX row “Supercedes” to link to them.
+
+6. **Architecture** – Before finalizing the record, read [docs/dev/architecture.md](docs/dev/architecture.md) and treat it as the current "as it should be" baseline. If the decision changes the intended architecture or design (not just describing current behavior), you MUST update `architecture.md` so that it reflects the new decision. Minor clarifications MAY update `architecture.md` directly without a DR, but substantive architectural changes SHOULD be accompanied by a decision record.
+
+## Mental model
+
+- `docs/dev/architecture.md` – authoritative description of the current intended architecture and design.
+- `docs/dev/decision-records/` – rationale and history explaining *why* and *when* the architecture changed.
+- The codebase – actual behavior of the system; discrepancies between code and `architecture.md` indicate design drift to be resolved via code changes, documentation changes, and/or new decision records.
+
+## Template reference
+
+Sections to fill: **Title** (one line), **Status** (Proposed | Accepted | Deprecated | Superseded by …), **Context**, **Decision**, **Consequences**, **Supersedes** (optional).

rdflib_reasoning-0.1.0.post1.dev83/.cursor/skills/verify-project-documentation/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: verify-project-documentation
+description: Assess the compliance of Markdown documents against the project's documentation policy, fixing compliance issues if asked to.
+---
+
+# Verify Project Documentation
+
+- You (the Development Agent) MUST ascertain if the repository follows the repository documentation policy.
+- You SHOULD correct compliance issues UNLESS the user has requested that you not do so.
+- You MAY widen your criteria to adhere to modern best practices.
+- You SHOULD adjust your criteria if the user has requested that you do so
+
+## 1. General Documentation Policy
+
+The checklist for policy adherence follows:
+
+- [ ] CRITICAL: Documentation passes linting: `make check`
+- [ ] CRITICAL: Documentation tone/style/content adheres to modern standards for technical documentation
+
+- [ ] References to `docs/example-chats` MUST NOT exist outside that directory
+- [ ] References to an `Agent` MUST use [the agent role controlled vocabulary](../../../AGENTS.md#agent-roles)
+- [ ] Docstrings within any distribution source folders (i.e., `src/` or `rdflib-reasoning-*/src`) MUST NOT refer to any local development documents or references.
+- [ ] All document cross references (read: markdown links in the repository) MUST be valid and resolvable
+- [ ] If a path exists within documentation for the Development Agent, its surface form SHOULD be relative to the repository root (e.g., `rdflib-reasoning-engine/README.md`)
+- [ ] All external documentation references (read: hyperlinks outside the repository) MUST be dereferencable (syntactically valid and normally reachable)
+- [ ] References to agents MUST NOT place emphasis on any specific model (e.g., Claude, GPT, Grok, etc)
+- [ ] References to agentic code environments SHOULD NOT place emphasis on any single tool (e.g., Claude Code, Codex, Cursor, etc)
+
+## 2. Specific File Documentation Policies
+
+Each of the following sections extends the [General Documentation Policy](#1-general-documentation-policy) for a document or set of documents.
+
+### 2.1. Policy for `architecture.md` and `decision-records`
+
+- [ ] [The quality gates for `docs/dev/architecture.md`](../../../docs/dev/AGENTS.md) are given by its local `AGENTS.md`
+- [ ] [The quality gates for `docs/dev/decision-records`](../../../docs/dev/decision-records/AGENTS.md) also include their local `AGENTS.md`
+
+### 2.2. Policy for sub-project `rdflib-reasoning-*/README.md` files
+
+- [ ] Feature matrices in the documents are up-to-date and match the current system state
+- [ ] Feature matrices are complete with respect to documented roadmapped functionality
+- [ ] The project overview is accurate and describes the purpose of the subproject
+- [ ] Distinguishing and key system features are briefly described and surface early in the documentation (i.e., not buried in a feature matrix)
+- [ ] Installation and setup procedures are clearly documented
+- [ ] A short tutorial/onboarding experience is provided in the way of small "Quick Start" examples
+- [ ] All code examples / listings / names match the current state of the system
+
+### 2.3. Policy for the root `README.md` file
+
+- [ ] The document accurately communicates the repository's purpose, intended audience, and research focus near the top of the file
+- [ ] The document presents the repository structure and major sub-projects in a way that matches the current filesystem and project boundaries
+- [ ] The document acts as a reliable entry point for a new Development Agent or contributor by linking to the key orientation documents (e.g., `AGENTS.md`, `docs/dev/architecture.md`, and major sub-project READMEs or directories)
+- [ ] Installation and environment guidance is accurate, internally consistent, and aligned with the repository's required development workflow
+- [ ] Any claims about capabilities, current scope, or repository status are consistent with the present codebase and sub-project documentation
+- [ ] The document provides enough navigational structure that a reviewer can quickly determine where architecture, implementation, specifications, and research artifacts live
+- [ ] Examples, commands, and package names shown in the document match the current repository state
+- [ ] The document avoids duplicating volatile low-level detail that is better maintained in sub-project documentation, unless the duplication is intentional and kept in sync
+
+### 2.4. Policy for `AGENTS.md` files
+
+- [ ] Each `AGENTS.md` clearly states the scope of the instructions it introduces and does not silently conflict with higher-level `AGENTS.md` files
+- [ ] Instructions are written for the Development Agent, unless a distinction between Development Agent and Research Agent is explicitly required
+- [ ] References to agents consistently use the repository's controlled vocabulary from the root `AGENTS.md`, with `Development Agent` remaining the default audience unless another role is explicitly assigned
+- [ ] The document clearly distinguishes normative instructions from explanatory/background material so that repository policy is easy to follow
+- [ ] File- or directory-specific quality gates are concrete, testable, and scoped to the subtree governed by that `AGENTS.md`
+- [ ] Cross references to templates, indexes, decision records, architecture documents, or sibling guidance are accurate and resolvable
+- [ ] Instructions do not require impossible repository knowledge from a Research Agent or otherwise blur the boundary between runtime-agent behavior and repository-development behavior
+- [ ] Local `AGENTS.md` files extend parent instructions additively where possible, and any override or specialization is made explicit enough to avoid ambiguity during validation
+- [ ] Reusable terminology, naming, and path conventions in the document match the current repository and adjacent documentation

rdflib_reasoning-0.1.0.post1.dev83/.cursorignore

@@ -0,0 +1,23 @@
+# The Development Agent shouldn't see example 'Development Agent' chats
+docs/example-chats/*
+!docs/example-chats/AGENTS.md
+
+# We need to explicitly override the gitignore so that Development Agent can see the content
+!docs/portfolio/*
+
+!docs/specs/jena-inspiration/jena-docs/*
+!docs/specs/jena-inspiration/jena-source/*
+
+!docs/specs/owl2-conformance/*
+!docs/specs/owl2-crosswalks/*
+!docs/specs/owl2-mapping-to-rdf/*
+!docs/specs/owl2-overview/*
+!docs/specs/owl2-reasoning-profiles/*
+!docs/specs/owl2-semantics-direct/*
+!docs/specs/owl2-semantics-rdf/*
+!docs/specs/owl2-structure-syntax/*
+!docs/specs/rdf11-concepts-syntax/*
+!docs/specs/rdf11-datasets/*
+!docs/specs/rdf11-primer/*
+!docs/specs/rdf11-schema/*
+!docs/specs/rdf11-semantics/*

rdflib_reasoning-0.1.0.post1.dev83/.env.example

@@ -0,0 +1,3 @@
+CHAT_MODEL="mistralai/Ministral-3-14B-Reasoning-2512"
+OPENAI_API_KEY="your api key goes here",
+OPENAI_BASE_URL="http://localhost:8000/v1"

rdflib_reasoning-0.1.0.post1.dev83/.github/CODEOWNERS

@@ -0,0 +1 @@
+* 63366453+kvjrhall@users.noreply.github.com

rdflib_reasoning-0.1.0.post1.dev83/.github/CONTRIBUTING.md

@@ -0,0 +1,15 @@
+# Contributing to RDFLib Reasoning
+
+## Requirements
+
+- Scripts MUST use `Bash >= 5.3.9`
+- Python package installation MUST use `uv`
+
+## Publishing
+
+- Merges to `main` publish built distributions to TestPyPI through `.github/workflows/build.yml`.
+- Releases publish built distributions to PyPI through `.github/workflows/release.yml`.
+- Publishing MUST use GitHub Actions OIDC Trusted Publishing rather than long-lived API tokens.
+- GitHub environments MUST remain separate: use `testpypi` for the TestPyPI sanity-check workflow and `pypi` for the release workflow.
+- Trusted Publishers MUST be configured on TestPyPI for `.github/workflows/build.yml` and on PyPI for `.github/workflows/release.yml`.
+- Trusted Publisher registrations MUST cover each distribution name in this repository: `rdflib-reasoning`, `rdflib-reasoning-axioms`, `rdflib-reasoning-engine`, and `rdflib-reasoning-middleware`.

rdflib_reasoning-0.1.0.post1.dev83/.github/dependabot.yml

@@ -0,0 +1,47 @@
+version: 2
+updates:
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+    labels:
+      - "dependencies"
+      - "ci"
+    commit-message:
+      prefix: "ci"
+
+  - package-ecosystem: "pip"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+    labels:
+      - "dependencies"
+    commit-message:
+      prefix: "deps"
+
+  - package-ecosystem: "pip"
+    directory: "/rdflib-reasoning-axioms"
+    schedule:
+      interval: "weekly"
+    labels:
+      - "dependencies"
+    commit-message:
+      prefix: "deps"
+
+  - package-ecosystem: "pip"
+    directory: "/rdflib-reasoning-engine"
+    schedule:
+      interval: "weekly"
+    labels:
+      - "dependencies"
+    commit-message:
+      prefix: "deps"
+
+  - package-ecosystem: "pip"
+    directory: "/rdflib-reasoning-middleware"
+    schedule:
+      interval: "weekly"
+    labels:
+      - "dependencies"
+    commit-message:
+      prefix: "deps"

rdflib_reasoning-0.1.0.post1.dev83/.github/release-drafter.yml

@@ -0,0 +1,64 @@
+name-template: "v$RESOLVED_VERSION"
+tag-template: "v$RESOLVED_VERSION"
+template: |
+  ## What Changed
+
+  $CHANGES
+
+  ## Package Artifacts
+
+  This release publishes distributions for:
+  - `rdflib-reasoning`
+  - `rdflib-reasoning-axioms`
+  - `rdflib-reasoning-engine`
+  - `rdflib-reasoning-middleware`
+change-template: "- #$NUMBER $TITLE (@$AUTHOR)"
+no-changes-template: "- No user-facing changes recorded."
+categories:
+  - title: "Features"
+    labels:
+      - "feature"
+      - "enhancement"
+      - "feat"
+  - title: "Fixes"
+    labels:
+      - "fix"
+      - "bug"
+      - "bugfix"
+  - title: "Documentation"
+    labels:
+      - "docs"
+  - title: "Tests"
+    labels:
+      - "test"
+      - "tests"
+  - title: "Maintenance"
+    labels:
+      - "build"
+      - "chore"
+      - "ci"
+      - "dependencies"
+      - "refactor"
+change-title-escapes: '\<*_&'
+version-resolver:
+  major:
+    labels:
+      - "bump-major"
+  minor:
+    labels:
+      - "bump-minor"
+  patch:
+    labels:
+      - "bump-patch"
+  default: patch
+autolabeler:
+  - label: "docs"
+    files:
+      - "*.md"
+      - "docs/**/*"
+  - label: "ci"
+    files:
+      - ".github/**/*"
+  - label: "tests"
+    files:
+      - "**/tests/**/*"