{
  "markdown": "# Project Parva\n\n[![CI](https://github.com/dantwoashim/Project_Parva/actions/workflows/ci.yml/badge.svg)](https://github.com/dantwoashim/Project_Parva/actions/workflows/ci.yml)\n[![Public verification](https://github.com/dantwoashim/Project_Parva/actions/workflows/public-verification.yml/badge.svg)](https://github.com/dantwoashim/Project_Parva/actions/workflows/public-verification.yml)\n![Benchmark](public-benchmark/results/benchmark.svg)\n\n[Website](https://prabinghimire1.com.np) |\n[API documentation](https://api.prabinghimire1.com.np/docs) |\n[Quickstart](docs/QUICKSTART.md) |\n[Public benchmark](public-benchmark/README.md) |\n[Licensing](docs/COMMERCIAL_LICENSING.md)\n\nProject Parva is an open-source Nepali date/time API and conformance project.\n\nIt covers BS to AD, AD to BS, Nepali date validation, holidays, working days,\nNepal fiscal year logic, BS month metadata, Panchanga computation, proof\nreceipts, local verification, SDKs, MCP tools, and public regression fixtures.\n\nThe project exists because Nepali date bugs often hide until a boundary is hit:\na frontend calendar table disagrees with backend data, a payroll month has the\nwrong number of days, a datepicker accepts an invalid BS date, or a future BS\ndate changes after someone already used it in a workflow.\n\nParva treats those cases as conformance problems, not just conversion problems.\nIt records source and method provenance, separates exact evidence from\nreview-needed evidence, and gives developers a way to test what their Nepali\ncalendar API or Nepali date converter is actually doing.\n\nThree public claims define the project:\n\n- A documented market review dated `2026-08-05` found no second Nepal-focused\n  API combining BS conversion, location-aware astronomical Panchanga, Nepal\n  business rules, future-BS research, replay artifacts, and public conformance.\n- The future-BS engine reaches `72/72` exact month predictions in chronological\n  rolling validation over the official `2078-2083 BS` window, with each target\n  year trained only on earlier years.\n- The public benchmark and conformance suites ship with fixtures, runners,\n  named-tool results, and per-case output.\n\n## Start Here\n\n- Quickstart: [docs/QUICKSTART.md](docs/QUICKSTART.md)\n- OpenAPI snapshot: [docs/api-docs/openapi.json](docs/api-docs/openapi.json)\n- API versioning: [docs/API_VERSIONING_AND_DEPRECATION.md](docs/API_VERSIONING_AND_DEPRECATION.md)\n- Proof mode: [docs/PROOF_MODE.md](docs/PROOF_MODE.md)\n- Panchanga engine: [docs/PANCHANGA_ENGINE.md](docs/PANCHANGA_ENGINE.md)\n- Agent tooling guide: [docs/AGENT_TOOLING_GUIDE.md](docs/AGENT_TOOLING_GUIDE.md)\n- Architecture: [docs/architecture/ARCHITECTURE.md](docs/architecture/ARCHITECTURE.md)\n- Migration status: [docs/architecture/MIGRATION_STATUS.md](docs/architecture/MIGRATION_STATUS.md)\n- Artifact policy: [artifacts/POLICY.md](artifacts/POLICY.md)\n- Safe claims: [docs/SAFE_CLAIMS.md](docs/SAFE_CLAIMS.md)\n- Public benchmark: [public-benchmark/README.md](public-benchmark/README.md)\n- Real-tool comparison: [public-benchmark/results/competitor-comparison.md](public-benchmark/results/competitor-comparison.md)\n- Licensing: [docs/COMMERCIAL_LICENSING.md](docs/COMMERCIAL_LICENSING.md)\n- Public conformance index: [docs/benchmarks/NEPALI_DATE_CONFORMANCE_INDEX.md](docs/benchmarks/NEPALI_DATE_CONFORMANCE_INDEX.md)\n- Public failure classes: [docs/benchmarks/PUBLIC_NEPALI_DATE_FAILURE_CLASSES.md](docs/benchmarks/PUBLIC_NEPALI_DATE_FAILURE_CLASSES.md)\n- Nepal compliance profile: [docs/conformance/nepal-compliance-profile.md](docs/conformance/nepal-compliance-profile.md)\n- Yarsa source-drift case study: [docs/case-studies/yarsa-calendar-source-drift.md](docs/case-studies/yarsa-calendar-source-drift.md)\n- External reviewer packet: [docs/external/REVIEWER_PACKET.md](docs/external/REVIEWER_PACKET.md)\n\nLive public evaluation surfaces:\n\n- Website: [https://prabinghimire1.com.np](https://prabinghimire1.com.np)\n- API docs: [https://api.prabinghimire1.com.np/docs](https://api.prabinghimire1.com.np/docs)\n- OpenAPI: [https://api.prabinghimire1.com.np/openapi.json](https://api.prabinghimire1.com.np/openapi.json)\n\nThe hosted API is a public evaluation deployment. First requests may be slower when the instance wakes up.\n\n## Why This Exists\n\nMost Nepali date bugs are small on paper and expensive in context.\n\nMany systems carry hardcoded Bikram Sambat month tables. A backend CSV, a\nfrontend Nepali datepicker bundle, and a reporting job can each have their own\ncopy. They may all look reasonable until one month differs by a day.\n\nThat one day can move:\n\n- a payroll period,\n- a fiscal-year boundary,\n- a certificate or DOB validation,\n- an invoice/report date,\n- an attendance or leave record,\n- a future BS date that should have stayed review-needed.\n\nSoftware agents add another failure mode: if the tool does not expose source,\nconfidence, and boundary data, the model will often answer as if the date is\nsettled. Parva is built to make those boundaries visible.\n\nThe project turns public Nepali date failures into fixtures and checks where\nthe evidence is exact enough. When the evidence is partial, it stays marked for\nreview instead of becoming a fake assertion.\n\n## Free Nepali Date Risk Audit\n\nIf you maintain Nepal-facing payroll, ERP, accounting, attendance, school,\ncooperative, public-service, government-form, or datepicker software, you can\nsend one small workflow or sample output.\n\nNo integration required. No dependency required. No sales call required. No\nauthority claim.\n\nGood inputs:\n\n- 10 sample BS/AD date outputs\n- one payroll, fiscal-year, invoice, attendance, report, certificate, or DOB workflow\n- one public repo, issue, Nepali datepicker, or library case\n- one real edge case your team has seen in production or testing\n\nChecks:\n\n- BS/AD conversion boundaries\n- invalid BS dates\n- month lengths\n- frontend/backend calendar source drift\n- fiscal and payroll month boundaries\n- holiday and working-day assumptions\n- future BS dates that should be marked review-needed\n\nYou get:\n\n- a short technical report\n- pass, warning, and review-needed findings\n- suggested regression tests\n- source and provenance notes\n- authority-boundary notes\n\nRequest one:\n\n- GitHub: [dantwoashim](https://github.com/dantwoashim)\n- Email: <twodan033@gmail.com>\n\nFast conformance path:\n\n```powershell\npy -3.11 tools\\conformance_runner\\run.py --suite public-nepali-date-issues\npy -3.11 tools\\conformance_runner\\run.py --profile nepal-compliance\npy -3.11 tools\\conformance_runner\\run.py --suite public-nepali-date-issues --write-report reports\\conformance\\public-issue-suite-summary.json\n```\n\n## What Parva Does\n\n| Area | What it provides |\n| --- | --- |\n| Nepali date API | BS to AD, AD to BS, today, validation, month metadata, supported-range metadata |\n| Civil proof mode | Replay-verifiable membranes for conversion, validation, holidays, working days, fiscal years, and BS months |\n| Panchanga engine | Method-docketed sunrise, tithi, nakshatra, yoga, karana, paksha, vara, ephemeris metadata, and proof receipts |\n| Payroll/date-risk audit | CSV/API-oriented decision-support checks for invalid dates, holidays, non-working days, fiscal boundaries, and review-required cases |\n| Local verification | Shared proof fixtures and a buildable `@project-parva/local-kernel` npm package for offline replay checks |\n| SDKs | Python and JavaScript clients with proof modes and conservative verification helpers |\n| Agent/MCP | Read-only, public-safe agent tool wrappers and MCP adapter surfaces that preserve boundaries and review gates |\n| Benchmark | Public Nepali Time Reliability Benchmark for deterministic date reasoning, source awareness, and review behavior |\n| Governance | Source/method dockets, public claims checker, route maturity, OpenAPI drift checks, and reproducible public verification |\n| Research boundary | Future-BS research kept separate from public authority claims, with compatibility shims only where older imports need them |\n\n## Public Conformance Work\n\nParva tracks public Nepali date issues and turns them into fixtures or runnable\nchecks when the evidence is exact enough. The suite separates verified public\nissues, reported issues, partial evidence, business workflow evidence, and\nfuture-date review cases.\n\nProject Parva's benchmark work contributed a standalone calendar source\nconsistency guard to `yarsa/nepal-compliance`.\n\nThat check compared duplicated frontend/backend BS month tables. It did not add\na Parva dependency, change upstream runtime behavior, or prove production\nimpact.\n\nRun the public issue conformance suite:\n\n```powershell\npy -3.11 tools\\conformance_runner\\run.py --suite public-nepali-date-issues\npy -3.11 tools\\conformance_runner\\run.py --profile nepal-compliance\npy -3.11 tools\\conformance_runner\\run.py --suite public-nepali-date-issues --write-report reports\\conformance\\public-issue-suite-summary.json\npy -3.11 -m pytest tests/conformance -q\n```\n\nConformance docs:\n\n- [Public conformance index](docs/benchmarks/NEPALI_DATE_CONFORMANCE_INDEX.md)\n- [Failure classes from public issues](docs/benchmarks/PUBLIC_NEPALI_DATE_FAILURE_CLASSES.md)\n- [Generated artifact: public issue summary](reports/conformance/public-issue-suite-summary.md)\n- [Nepal compliance profile](docs/conformance/nepal-compliance-profile.md)\n- [Yarsa source-drift case study](docs/case-studies/yarsa-calendar-source-drift.md)\n- [Conformance Milestone 001](docs/releases/CONFORMANCE_MILESTONE_001.md)\n\nThese fixtures are public regression and review artifacts. They are not\ncalendar publication, legal guidance, tax guidance, payroll approval, banking\nguidance, or ritual authority.\n\n## Who This Helps\n\n- Date library maintainers who want regression cases from real public issues.\n- ERP, payroll, accounting, school, cooperative, and attendance teams that need\n  safer BS/AD boundaries.\n- Reviewers of public-service or government-form workflows where invalid BS\n  dates should not slip through.\n- Developers building a Nepali calendar API, Bikram Sambat API, or Nepali\n  datepicker regression suite.\n- Software-agent and MCP tool builders who need deterministic answers with\n  proof receipts instead of guessed dates.\n- Auditors and maintainers who need source notes, not broad claims.\n\n## Quickstart\n\nBase URL:\n\n```text\nhttps://api.prabinghimire1.com.np/v3/api\n```\n\nAD to BS:\n\n```bash\ncurl \"https://api.prabinghimire1.com.np/v3/api/calendar/convert?date=2025-04-14\"\n```\n\nBS to AD:\n\n```bash\ncurl -X POST \"https://api.prabinghimire1.com.np/v3/api/calendar/bs-to-gregorian\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"year\":2082,\"month\":1,\"day\":1}'\n```\n\nValidate a BS date:\n\n```bash\ncurl \"https://api.prabinghimire1.com.np/v3/api/calendar/validate-bs-date?year=2082&month=1&day=32\"\n```\n\nHoliday membership:\n\n```bash\ncurl \"https://api.prabinghimire1.com.np/v3/api/compliance/holiday?bs_date=2082-01-01\"\n```\n\nWorking-day decision support:\n\n```bash\ncurl -X POST \"https://api.prabinghimire1.com.np/v3/api/compliance/evaluate-date\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"profile_id\":\"nepal_private_company_default\",\"bs_date\":\"2082-01-01\",\"decision_intent\":\"general\"}'\n```\n\nFiscal year:\n\n```bash\ncurl \"https://api.prabinghimire1.com.np/v3/api/enterprise/fiscal-year/2082\"\n```\n\nBS month metadata:\n\n```bash\ncurl \"https://api.prabinghimire1.com.np/v3/api/enterprise/bs-months/2082?mode=compare\"\n```\n\nPanchanga summary:\n\n```bash\ncurl \"https://api.prabinghimire1.com.np/v3/api/calendar/panchanga?date=2025-04-14\"\n```\n\n## Proof Mode\n\nStable civil routes and Panchanga can return proof receipts:\n\n```bash\ncurl \"https://api.prabinghimire1.com.np/v3/api/calendar/convert?date=2025-04-14&proof=replay\"\n```\n\n```bash\ncurl \"https://api.prabinghimire1.com.np/v3/api/calendar/panchanga?date=2025-04-14&proof=replay&lat=27.7172&lon=85.324&tz=Asia/Kathmandu\"\n```\n\nA proof response includes a membrane capsule, identity hash, witness hash, field provenance, boundary vector, source or method docket references, policy trace, and replay instructions. The verifier must replay operation semantics or validate pinned proof content; hash presence alone is not enough.\n\nProof-supported civil operations:\n\n- `convert_bs_to_ad`\n- `ad_to_bs`\n- `validate_bs_date`\n- `holiday`\n- `working_day`\n- `fiscal_year`\n- `bs_months`\n\nPanchanga proof currently covers method-docketed `panchanga_summary` with pinned fixture replay and explicit ephemeris metadata.\n\n## Panchanga Engine\n\nParva computes Panchanga signals as method-backed astronomical outputs, not as a final almanac, publication, or ritual decision source.\n\nThe proof-carrying Panchanga layer records:\n\n- date, latitude, longitude, timezone\n- ephemeris provider and provider kind\n- fixture or kernel hash when applicable\n- ayanamsa and sidereal mode\n- sunrise attribution rule\n- method dockets for sunrise, tithi, nakshatra, yoga, karana, and related calculations\n- field provenance and boundary vector\n- `computed_not_official`, `not_panchanga_authority`, and `not_ritual_final_authority`\n\nJPL support is explicit and bounded. The repo exposes a JPL DE440-family provider interface and kernel-hash disclosure path. Large JPL kernels are not bundled. If no kernel is configured, Parva must not silently claim JPL-backed output.\n\nSee [docs/PANCHANGA_ENGINE.md](docs/PANCHANGA_ENGINE.md), [docs/spec/PARVA_EPHEMERIS_PROVIDER_v1.md](docs/spec/PARVA_EPHEMERIS_PROVIDER_v1.md), and [docs/spec/PARVA_PANCHANGA_PROOF_v1.md](docs/spec/PARVA_PANCHANGA_PROOF_v1.md).\n\n## Payroll and Date-Risk Audit\n\nParva includes a proof-carrying payroll/date-risk workflow for decision support. It checks rows for:\n\n- invalid BS dates\n- BS/AD mismatches\n- holiday conflicts\n- non-working-day conflicts\n- fiscal-year boundary issues\n- unsupported or review-required ranges\n- source or method authority weakness\n\nThe workflow can emit row-level proof packs and a Timepack-style aggregate report. It is a precheck/audit aid, not legal, tax, payroll, banking, or compliance authority.\n\n## Local and Offline Verification\n\nGenerate shared proof fixtures:\n\n```bash\npy -3.11 scripts/release/generate_proof_fixtures.py\n```\n\nRun backend fixture replay:\n\n```bash\npy -3.11 -m pytest tests/integration/test_shared_proof_fixtures.py -q\n```\n\nRun the local kernel:\n\n```bash\ncd packages/parva-local-kernel\nnpm install\nnpm test\n```\n\nThe local kernel is a buildable npm package: `@project-parva/local-kernel`. It verifies shared civil fixtures, Panchanga fixtures, proof packs, and Timepack-shaped artifacts without calling the live API.\n\n## SDKs\n\nPython:\n\n```python\nfrom parva import ParvaClient\n\nclient = ParvaClient()\npayload = client.ad_to_bs(\"2025-04-14\", proof=\"replay\")\nprint(payload[\"proof\"][\"identity_hash\"])\n```\n\nJavaScript:\n\n```js\nimport { ParvaClient } from \"@project-parva/parva-js\";\n\nconst client = new ParvaClient();\nconst payload = await client.getPanchanga({\n  date: \"2025-04-14\",\n  proof: \"replay\",\n  lat: 27.7172,\n  lon: 85.324,\n  tz: \"Asia/Kathmandu\",\n});\nconsole.log(payload.proof.identity_hash);\n```\n\nPackages in this repository are prepared for public-beta dry runs. This README does not claim PyPI publication, npm publication, registry acceptance, external certification, or customer adoption.\n\n## Agent and MCP Usage\n\nParva is useful for software agents because it gives deterministic temporal tools instead of asking models to guess Nepali dates.\n\nAgent-safe surfaces must preserve:\n\n- source or method status\n- confidence and boundary vector\n- `review_required`\n- `not_authority`\n- field provenance\n- proof links or receipts where available\n\nPackages:\n\n- agent tools: [packages/parva-agent-tools](packages/parva-agent-tools)\n- MCP server: [packages/parva-mcp-server](packages/parva-mcp-server)\n- Agent guide: [docs/AGENT_TOOLING_GUIDE.md](docs/AGENT_TOOLING_GUIDE.md)\n\n## Future BS Research Forecast\n\nParva publishes a deterministic research snapshot for `2084-2200 BS` through three read-only endpoints:\n\n```text\nGET /v4/api/future-bs/capabilities\nGET /v4/api/future-bs/methodology\nGET /v4/api/future-bs/forecast/{bs_year}\n```\n\nThe selected pipeline combines sidereal solar-ingress solving, Nepal civil-time assignment, separate broad-reference and official-authority towers, past-only civil-rule learning, source-aware month-start reconciliation, complete-year constraints, prediction sets, and boundary-risk labels. The forecast response includes all twelve month lengths, normalized model support, agreement, boundary distance, risk flags, method versions, and validation scope.\n\nThe official `2078-2083 BS` window reaches `72/72` exact month matches under chronological rolling validation, with each target year trained only on earlier years. It remains a small development-window result rather than broad independent accuracy proof. Broad validation remains below the project's 528 verified-month evidence threshold. Every forecast carries `computed_prediction_not_official`, `review_required=true`, and an authoritative-publication override.\n\nThe v7 forecast is now locked by a public source commit, snapshot digest, 117 per-year commitments, and a Merkle root. Later official calendars are scored only from hashed source artifacts reviewed by two people; historical source recovery remains a separate provenance lane.\n\n- Public API contract: [docs/future_bs/API.md](docs/future_bs/API.md)\n- Selected method: [docs/future_bs/METHODOLOGY.md](docs/future_bs/METHODOLOGY.md)\n- Frozen v7 forecast: [docs/future_bs/V7_FORECAST_FREEZE.md](docs/future_bs/V7_FORECAST_FREEZE.md)\n- Official-source acquisition: [docs/future_bs/OFFICIAL_CALENDAR_ACQUISITION_PROTOCOL.md](docs/future_bs/OFFICIAL_CALENDAR_ACQUISITION_PROTOCOL.md)\n- BS 2082 boundary diagnosis: [docs/future_bs/2082_BOUNDARY_DIAGNOSIS.md](docs/future_bs/2082_BOUNDARY_DIAGNOSIS.md)\n- Research boundary: [docs/future_bs/RESEARCH_BOUNDARY.md](docs/future_bs/RESEARCH_BOUNDARY.md)\n\n## Architecture Overview\n\nCurrent code is split by responsibility:\n\n- public API/runtime code lives under `backend/app` lanes such as `calendar`, `panchanga`, `sources`, `membranes`, `rules`, `timegraph`, `trust`, and `services`\n- Future-BS research and model-risk work lives under `backend/app/research/future_bs`\n- `backend/app/future_bs` is a compatibility namespace, not the canonical implementation location\n- backend runtime tests live under `tests/backend_runtime`\n- local-kernel tests live under `tests/local_kernel`\n- tracked MoHA public holiday source PDFs live under `data/source_archive/moha` with `data/source_archive/moha/manifest.json`\n- generated or release-sensitive artifacts follow [artifacts/POLICY.md](artifacts/POLICY.md)\n\n```text\npublic route / SDK / MCP tool\n  -> canonical query\n  -> source or method coverage resolution\n  -> policy decision trace\n  -> field-level provenance\n  -> boundary vector\n  -> membrane capsule\n  -> proof pack / Timepack\n  -> backend replay verifier and local-kernel verifier\n```\n\nCore architecture files:\n\n- Architecture map: [docs/architecture/ARCHITECTURE.md](docs/architecture/ARCHITECTURE.md)\n- Migration status: [docs/architecture/MIGRATION_STATUS.md](docs/architecture/MIGRATION_STATUS.md)\n- Membranes and replay: [backend/app/membranes](backend/app/membranes)\n- Source coverage: [backend/app/sources/coverage.py](backend/app/sources/coverage.py)\n- Panchanga proof: [backend/app/panchanga](backend/app/panchanga)\n- Future-BS research boundary: [backend/app/research/future_bs](backend/app/research/future_bs)\n- Local kernel: [packages/parva-local-kernel](packages/parva-local-kernel)\n- Public verification: [scripts/release/verify_public.py](scripts/release/verify_public.py)\n- Semantic depth gate: [scripts/release/check_ceiling_depth_semantics.py](scripts/release/check_ceiling_depth_semantics.py)\n\n## Public Verification\n\nRun:\n\n```bash\npy -3.11 scripts/release/verify_public.py\n```\n\nFocused checks:\n\n```bash\npy -3.11 scripts/release/check_public_claims.py\npy -3.11 scripts/check_path_leaks.py\npy -3.11 scripts/check_future_bs_public_leakage.py\npy -3.11 scripts/release/check_public_openapi_drift.py\npy -3.11 scripts/release/check_ceiling_depth_semantics.py\n```\n\nFrontend:\n\n```bash\ncd frontend\nnpm test -- --run\nnpm run build\n```\n\n## Safe Claims\n\nSafe claims when the relevant verification commands pass:\n\n- Parva provides source-aware Nepali temporal APIs.\n- Parva supports proof receipts for stable civil temporal operations.\n- Parva supports method-docketed Panchanga computation with explicit non-authority boundaries.\n- Parva can run local/offline verification against committed proof fixtures.\n- Parva can help software agents avoid guessing Nepali dates.\n- Parva can support payroll/date-risk prechecks and vendor conformance review.\n\n## Forbidden Claims\n\nDo not claim:\n\n- government approval or public-office endorsement\n- legal, tax, payroll, or banking decision authority\n- religious or ritual final authority\n- settled authority for unsupported future BS dates\n- final Panchanga or ritual authority\n- external certification\n- PyPI/npm publication unless the package is actually published\n- MCP registry acceptance unless accepted by a registry\n- customers, adoption, or design partners unless real evidence exists\n- unqualified Future-BS certainty or authority claims\n\n## Project Status\n\nThe public reproducibility gate is the source of truth for release readiness:\n\n```bash\npy -3.11 scripts/release/verify_public.py\n```\n\nThe civil temporal core has replay-verifiable proof support and local fixtures. Panchanga has a proof-carrying method-docketed path with fixture replay and a bounded JPL provider interface. Future-BS publishes a curated research snapshot while raw model workflows remain controlled.\n\nThe external ceiling is not complete. There are no real external witnesses, institutional signatures, official approval, third-party certification, or customer/adoption proof in this repository.\n\n## License and Source Availability\n\nProject Parva is licensed under `AGPL-3.0-or-later`. Network deployments must\nset `PARVA_SOURCE_URL` to the corresponding source repository or source archive\nfor the deployed version. The application exposes `/source` as a redirect to\nthat configured location and adds a `rel=\"source\"` link to HTTP responses.\n\nCommercial embedding licenses are also available for proprietary products at\nNPR 100,000-300,000 per vendor per year, based on named product scope. See\n[docs/COMMERCIAL_LICENSING.md](docs/COMMERCIAL_LICENSING.md).\n\nDeployment details are documented in [docs/DEPLOYMENT.md](docs/DEPLOYMENT.md).\n\n## Roadmap\n\nNear-term:\n\n- broaden local-kernel replay beyond current fixtures\n- expand Panchanga proof fixtures and provider coverage\n- deepen proof-pack and Timepack CLI workflows\n- harden payroll/date-risk audit reports for external review\n- add more proof-aware UI surfaces\n- expand benchmark and conformance cases\n- collect bounded external technical review without overclaiming authority\n\n## Contributing\n\nContributions should preserve Parva's core rules:\n\n- no low-authority data may become high-authority output\n- no proof verifier may only check object shape or hash presence\n- proof-supported operations need replay tests and tamper tests\n- public docs must not overclaim authority\n- future-sensitive outputs must remain review-aware\n\nBefore opening a pull request, run:\n\n```bash\npy -3.11 -m pytest -q -m \"not private_source and not wide_corpus and not research_artifact\" --maxfail=20\npy -3.11 scripts/release/check_public_claims.py\npy -3.11 scripts/release/check_ceiling_depth_semantics.py\n```\n\nUse Python 3.11 and Node 20 for reproducible verification.\n",
  "bytes": 23483,
  "sha": "f8fc81402cdcad7b4778105a1e898f7782d8c3cec90e1511a6f38a15627a5955",
  "repo_slug": "dantwoashim/project_parva",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/mcp_io_github_dantwoashim_project_parva_175a1a34/readme"
}