Contributing

Repository layout

Path	What’s in it
packages/core	The finding schema, rules, knowledge base, scan, config reader and report writer
packages/cli	The lintsure command
packages/mcp	The MCP server
fixtures/sample-app	A small app with one planted problem per rule
fixtures/clean-app	Near misses that must not be flagged
fixtures/config-app	A lintsure.config.yaml used by the config test

Develop

npm install
npm test            # build all packages, then run the tests
npm run scan:sample # run the CLI on the sample app

Add a rule

Rules live in packages/core/src/rules/index.ts. A rule needs:

• id, title, severity
• status: gap or partial. Never met; only the Checker sets Met.
• controls: every framework control it maps to
• fix and note, in plain words
• extensions: which files it reads
• test(line) for a line rule, or fileTest(lines) for a file rule. Both must be pure.
• mappedBy and reviewedAt, so an auditor review can be tracked

Then:

1. Plant one example of the problem in fixtures/sample-app.
2. Add a near miss to fixtures/clean-app that looks similar but is fine.
3. Link the rule from at least one obligation in packages/core/src/knowledge/.
4. Run npm test.

What the tests check

• The same input gives the same report.
• Every rule fires on its planted example.
• No rule fires on the clean app.
• Every rule fills every required field and can’t return Met.
• Knowledge points only at rules that exist, and every rule is linked from some obligation.
• The config file is read correctly.
• The engine contains no network code.

Writing about frameworks

The knowledge base must be in our own words. Don’t paste text from laws, standards or guides. ISO/IEC and AICPA texts are licensed: reference control and criterion IDs only.

License and sign-off

Apache-2.0. Sign off each commit with git commit -s to certify the Developer Certificate of Origin.