chore: untrack node_modules, repair the lockfile, and add the first CI

[DealAppSeo]

The headline: a clean clone of this repo could not install

npm ci failed at the root and in packages/contracts — both lockfiles were out of sync with their package.json, and the root lockfile predated the workspaces entirely (0 references to packages/).

Committing node_modules was the workaround. That is why 4,526 of 4,617 tracked files — 98% of the repo — were vendored dependencies.

This is the first thing an external reviewer does, so it is the first thing to fix.

What changed

.gitignore	did not exist at all — the root cause
node_modules	untracked (4,526 files). Files stay on disk, history is not rewritten. Both package-lock.json files retained — they are the reproducible record
package-lock.json	regenerated. npm ci now exits 0 and the lock finally knows about the workspaces
.github/workflows/ci.yml	first CI in the repo

Verified, not assumed:

• npm ci at root → RC 0 (was EUSAGE, could not install)
• tracked files → 4,617 → 91
• both lockfiles → still tracked
• packages/contracts sources (contracts/, test/, abis/, ERC8004SPEC.md) → untouched

What I found and deliberately did not fix

The contract tests fail 26 of 61:

Event "NewFeedback" with argument count 11 not found in the contract ABI

This pre-dates this change, and I verified that rather than claiming it — restoring the original committed node_modules from origin/main and re-running produces the identical 35 pass / 26 fail with the same error. The lockfile regeneration did not cause it. packages/contracts is owned elsewhere, so it is surfaced here and left alone.

Separately, hardhat.config.ts rejects its own config (HHE15) when SEPOLIA_RPC_URL / MAINNET_RPC_URL are unset — before a single test runs. A reviewer cloning this repo sees a red suite that looks like broken contracts and is actually unset env. CI sets public read-only endpoints so an ENV failure can never be mistaken for a TEST failure.

The CI is deliberately not all-green

Four of five packages have no tests. A single green tick across the repo would claim coverage that does not exist.

• install — blocking. It is the thing that was actually broken. Also guards that node_modules is never committed again.
• contracts — reports its true tally, does not gate, warns only if failures exceed the 26 baseline.
• coverage-map — prints per-package test presence so "none" is visible rather than implied.

An unwired safeguard is worse than an absent one: it converts a known gap into false coverage. Same is true of a package that silently has no tests.

Review note

The diff is ~4,500 files because that is how many vendored files were tracked. The reviewable surface is three files: .gitignore, .github/workflows/ci.yml, and package-lock.json.

🤖 Generated with Claude Code

[DealAppSeo]

Diagnosis: the 26 failing tests are correct. The contract broke ERC-8004 conformance.

Chasing Event "NewFeedback" with argument count 11 not found in the contract ABI to its root. The tests are right and the implementation is wrong — this is a spec divergence, not a stale test.

Three sources, two signatures

source	args	ends with
ERC8004SPEC.md:224 (canonical)	11	bytes32 feedbackHash
abis/ReputationRegistry.json (checked-in)	11	bytes32 feedbackHash
contracts/ReputationRegistryUpgradeable.sol:15	12	bytes32 feedbackHash, bytes x402PaymentProof

The Solidity source appends a 12th parameter — bytes x402PaymentProof — that appears in neither the spec nor the published ABI. The spec (line 224) is explicit:

event NewFeedback(uint256 indexed agentId, address indexed clientAddress, uint64 feedbackIndex,
  int128 value, uint8 valueDecimals, string indexed indexedTag1, string tag1, string tag2,
  string endpoint, string feedbackURI, bytes32 feedbackHash)

Why this is a conformance break, not a cosmetic mismatch

Adding a parameter changes the event signature, which changes topic0 (truncated; recompute with keccak256 of the signature strings above):

canonical (spec + abis/):  0x6a4a617435...
deployed  (.sol source):   0x58819acf68...

Different topics. Any ERC-8004-compliant indexer filtering on the canonical topic0 sees zero feedback events from this contract. The spec's own stated goal for this event — "exposes reputation signals to any smart contract, enabling on-chain composability" — does not hold as deployed. Third-party consumers silently observe an empty registry rather than an error.

Scope

All 26 failures are in the ReputationRegistry suite of test/core.ts (61 tests total: 35 pass, 26 fail). Every one traces to this single signature divergence — it is one defect, not 26.

Pre-existing. Verified by restoring the original committed node_modules from origin/main and re-running: identical 35/26 with the same error. The lockfile repair in this PR did not cause it.

Options — owner's call, not touched here

1. Move the extension out. Keep NewFeedback byte-exact to spec; emit NewFeedbackPaymentProof(uint256 indexed agentId, address indexed clientAddress, uint64 feedbackIndex, bytes x402PaymentProof) alongside it. Restores conformance, keeps the x402 data, preserves indexed correlation. Cleanest of the three.
2. Dual-emit the canonical event plus the extended one. Conformant but pays double log gas on every feedback.
3. Accept the divergence and document it as a deliberate non-standard extension — which means dropping the ERC-8004 composability claim for this event.

I have not modified anything under packages/contracts. This is diagnosis only, so the decision sits with whoever owns the spec.