@critiq/rules 0.0.1 → 0.0.2

package/LICENSE

@@ -0,0 +1,201 @@
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!) The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

package/README.md

@@ -1,169 +1,237 @@
-# @critiq/rules
+<p align="center">
+  <img src="https://raw.githubusercontent.com/critiq-dev/critiq-rules/main/docs/assets/banner-rules-simple-transparent.png" alt="critiq.dev" style="max-height:400px" />
+</p>
 
-`@critiq/rules` is the default public OSS catalog used by `critiq check`.
+<h1 align="center">Critiq OSS Rules</h1>
+<p align="center">
+  <strong>Open source static analysis rules for deterministic code review.<br/>High-signal rules for security, correctness, performance, and code quality.</strong>
+</p>
+<p align="center">
+  <a href="https://www.npmjs.com/package/@critiq/rules"><img src="https://img.shields.io/npm/v/%40critiq%2Frules" alt="npm version" /></a>
+  <a href="https://github.com/critiq-dev/critiq-rules/tree/main/libs/rules/catalog"><img src="https://img.shields.io/badge/source-GitHub-181717?logo=github" alt="Source" /></a>
+  <a href="https://github.com/critiq-dev/critiq-rules/blob/main/libs/rules/catalog/LICENSE"><img src="https://img.shields.io/badge/license-Apache%202.0-blue.svg" alt="License" /></a>
+</p>
 
-It ships:
 
-- `catalog.yaml`
-- rule YAML files under `rules/`
-- preset membership for `recommended`, `strict`, `security`, and `experimental`
 
-The current catalog is still TypeScript-heavy, but the shared security baseline
-also runs across Go and Python. Some rules are pure AST matches, and others
-depend on adapter facts such as control-flow, async, structural, and data-flow
-observations. A smaller set now depends on check-runner project heuristics for
-cross-file auth, coupling, and testing checks.
+Think of Critiq as an extra code reviewer that scans your project for bugs, security issues, performance problems, and risky changes before they turn into production incidents. Instead of only checking style, it focuses on the kinds of problems that usually slip through review and cause real trouble later. You run it locally or in CI, and it gives you deterministic findings you can act on before merging code.
 
-## What Gets Checked
 
-Representative examples of patterns the catalog flags today:
+It does this by parsing your code, matching it against a curated catalog of explicit rules, and reporting findings with concrete evidence tied to the code that triggered them. That means the output is based on repeatable checks for things like unsafe SQL, missing authorization, repeated IO in loops, and untested critical logic changes, not vague heuristics or style-only linting.
 
-```ts
-console.log('hello');
-console.error(error);
-debugger;
-```
+<p align="center">
+  <img
+    src="https://raw.githubusercontent.com/critiq-dev/critiq-core/main/docs/assets/languages.png"
+    alt="TypeScript, JavaScript, Node.js, Go, Java, Python, PHP, Ruby, and Rust support"
+  />
+</p>
+`@critiq/rules` is the default open source rule catalog for Critiq. It ships `catalog.yaml`, preset membership, and rule YAML files for high-signal checks across TypeScript, JavaScript, Node.js, Go, Java, Python, PHP, Ruby and Rust.
 
-```ts
-async function load() {
-  fetch('/users');
-}
+Use it with [`@critiq/cli`](https://www.npmjs.com/package/@critiq/cli):
 
-async function callApi() {
-  return fetch('/users');
-}
+```bash
+npm install -D @critiq/cli @critiq/rules
+npx critiq check .
 ```
 
-```ts
-function read(req: { body: any }) {
-  const payload = req.body;
-  return payload.user.profile.city;
-}
+Run against a diff:
 
-function maybe(flag: boolean) {
-  const user = flag ? { name: 'Ada' } : null;
-  return user.name;
-}
+```bash
+npx critiq check . --base origin/main --head HEAD
 ```
 
-```ts
-function lookup(cacheMap: Map<string, string>, key: string) {
-  return cacheMap.get(key);
-}
+## Catalog At A Glance
+
+Today the catalog includes `112` rules across `10` categories, with `recommended`, `strict`, `security`, and `experimental` presets.
+
+| Category | Rules | What it looks after |
+| --- | ---: | --- |
+| Security | 70 | Injection, auth and session gaps, unsafe transport, sensitive data exposure, unsafe file and HTML handling |
+| Correctness | 15 | Async bugs, null access, control-flow mistakes, missing fallbacks, race conditions |
+| Performance | 10 | Repeated IO, wasted async sequencing, hot-path loops, large retained objects, render churn |
+| Quality | 10 | Error handling gaps, oversized functions, coupling, duplicated logic, and weak test coverage |
+| Logging | 2 | Console usage and unsafe logging patterns |
+| Config | 1 | Configuration access boundaries |
+| Next | 1 | Server and client boundary leaks |
+| Random | 1 | Unsafe randomness in core logic |
+| React | 1 | Cascaded effect fetch patterns |
+| Runtime | 1 | Debug-only statements left in shipped code |
+
+## High-Value Rules In This Catalog
+
+| Rule title | Description |
+| --- | --- |
+| `Hardcoded API keys or credentials` | Source files should not embed credential-like string literals. |
+| `Avoid raw or interpolated SQL`  | Database query sinks must not receive request-driven or dynamically interpolated SQL text. |
+| `Path traversal via user input` | File access calls must not use request-controlled paths directly. |
+| `Protect deserialization trust boundaries` | Deserializers should not consume untrusted payloads directly across a trust boundary. |
+| `Server-side request forgery` | Outbound requests should not use attacker-controlled targets or private hosts. |
+| `Open redirect via request-controlled target` | Redirect and navigation sinks should not use request-controlled destinations without validation. |
+| `Missing authorization before sensitive action` | Sensitive backend actions should be guarded by an authorization or permission check. |
+| `Use authenticated encryption for secrets and tokens`  | Session, cookie, and token encryption should provide integrity protection in the same helper. |
+| `Missing await on async call` | Async functions should not drop direct async calls without awaiting them. |
+| `Repeated IO call inside loop` | Database or network calls inside loops can multiply latency and load. |
+| `Logic change without corresponding test updates` | Diffs that change critical logic should usually update the matching tests in the same change. |
+| `Avoid server/client boundary leaks in Next.js` | Server components should not use browser-only APIs or client-only hooks without an explicit client boundary. |
+
+## Rule Methodology
+
+Critiq keeps the OSS catalog intentionally high-signal.
+
+- We add rules that change code review outcomes: security flaws, correctness bugs, performance regressions, and maintainability issues with real operational cost.
+- We prefer rules that are deterministic, explainable, and backed by fixtures instead of vague heuristics.
+- We avoid generic style rules that compilers and standard linters already handle well.
+- Every rule should produce an actionable finding with evidence, not restate general guidance.
+
+## More Rules In This Catalog
+
+The catalog also includes these `100` additional rules beyond the highlights above.
 
-function parseIdentity(req: { headers: Record<string, string | undefined> }) {
-  const token = req.headers.authorization;
-  return decode(token ?? '');
-}
-```
+### Security
 
-```ts
-const query = `SELECT * FROM users WHERE email = '${email}'`;
-element.innerHTML = req.body.html;
-document.write(userMarkup);
-execFile(req.query.command, []);
-JSON.parse(req.body.payload);
-```
+| Rule title | Description |
+| --- | --- |
+| `Eval or dynamic code execution` | Eval-like helpers, `vm` execution APIs, and string-evaluated timers should not execute dynamic code. |
+| `Command execution using untrusted input` | Process execution helpers must not receive request-controlled executables or shell-interpreted arguments. |
+| `Avoid unsafe DOM HTML insertion sinks` | `outerHTML`, `document.write*`, and `insertAdjacentHTML` should only receive fixed or explicitly sanitized HTML. |
+| `` Avoid unsafe `dangerouslySetInnerHTML` `` | React `dangerouslySetInnerHTML` should only render fixed or explicitly sanitized HTML. |
+| `` Avoid unsafe `innerHTML` assignment `` | `innerHTML` assignments should only use fixed or explicitly sanitized HTML. |
+| `Missing ownership validation` | Resource identifiers from request input should be checked against the caller before sensitive actions run. |
+| `Authorization enforced only on frontend` | Backend routes should enforce authorization directly instead of relying on frontend gating alone. |
+| `Token or session not validated` | Session and token values from external input should be verified before authentication or identity use. |
+| `Harden auth-bearing cookies` | Auth and session cookies should set HttpOnly, Secure, and SameSite. |
+| `Remove sensitive claims from JWT payloads` | JWT payloads should avoid embedding PII or secrets unless absolutely required. |
+| `Avoid browser token storage` | Access and session tokens should not be stored in long-lived browser storage. |
+| `TLS verification disabled` | Transport clients should not disable certificate verification. |
+| `Insecure HTTP transport` | Outbound transport should not use plain HTTP for sensitive requests. |
+| `Require modern TLS minimum versions` | Transport clients should not explicitly allow SSLv3, TLS 1.0, or TLS 1.1. |
+| `Sensitive data egress to third-party processors` | Sensitive values should not be sent to external processors or outbound SDKs without minimization or redaction. |
+| `Avoid sensitive data in logs and telemetry` | Sensitive fields should not be sent to logging, tracing, or analytics sinks. |
+| `Avoid binding to all interfaces` | Network-facing services should not explicitly bind to every interface unless public exposure is intentional and protected. |
+| `Avoid weak hash algorithms` | Cryptographic hashing should use modern, collision-resistant algorithms. |
+| `Avoid weak cipher algorithms and modes` | Cryptographic ciphers should use modern authenticated modes and approved algorithms. |
+| `Avoid predictable token generation` | Tokens, reset links, and session secrets should be generated from cryptographically strong randomness. |
+| `Use enough entropy for secrets and tokens` | Secret-bearing tokens and secrets should use at least 16 bytes of cryptographic entropy. |
+| `Avoid weak key-generation strength` | Key-generation helpers should use current minimum strengths for RSA, AES, and HMAC keys. |
+| `Validate untrusted input before parser construction` | Untrusted input should be validated before it is used to construct sensitive parsers or runtime objects. |
+| `Missing request timeout or retry protection` | External calls should define timeout, cancellation, or retry behavior before they enter security-sensitive flows. |
+| `Review Datadog RUM user interaction capture` | Datadog Browser RUM should not enable broad user interaction capture without a privacy review. |
+| `Avoid request-driven DynamoDB queries` | DynamoDB query and scan inputs should not be built directly from request input. |
+| `Avoid hardcoded auth secrets` | JWT, session, and strategy secrets should not be embedded directly in source code. |
+| `Constrain module-loading trust boundaries` | `require()` and dynamic `import()` should not resolve modules from untrusted input. |
+| `Do not reflect request origin into CORS policy` | `Access-Control-Allow-Origin` should not be set from request-controlled input. |
+| `Do not allow every origin in CORS policy` | CORS should not fall back to wildcard or implicit allow-all origin settings. |
+| `` Set `Secure` on Express session cookies `` | Express session and cookie-session configs should not disable the `Secure` flag. |
+| `` Set `HttpOnly` on Express session cookies `` | Express session and cookie-session configs should not disable the `HttpOnly` flag. |
+| `Avoid legacy Argon2 password hash modes` | Password hashing should not use `argon2i` or `argon2d` when safer modern modes are available. |
+| `Use secure WebSocket transport` | WebSocket clients should not connect over cleartext `ws://` when sensitive application data is involved. |
+| `Add a JWT revocation hook` | Express JWT middleware should check revocation state when bearer tokens can be invalidated early. |
+| `Keep Handlebars escaping enabled at template trust boundaries` | Server-side Handlebars compilation should not disable HTML escaping with `noEscape: true`. |
+| `Avoid ad hoc HTML sanitization` | Hand-rolled HTML escaping and sanitization should be replaced with vetted sanitizers or safe rendering paths. |
+| `` Verify `message` event origins `` | `message` handlers should validate `event.origin` before trusting cross-window data. |
+| `Avoid request-driven model queries` | Express handlers should not pass raw request objects into NoSQL filters, query helpers, or aggregation pipelines. |
+| `Use constant-time secret comparison` | Secrets and tokens should not be compared with ordinary equality operators. |
+| `Do not persist upload filenames directly` | Upload handlers should not store attacker-controlled filenames without generating or validating a safe local name. |
+| `Constrain local file generation paths` | Local file writes should not derive their destination path from request or upload input. |
+| `Avoid attacker-controlled filesystem read paths` | Direct filesystem read APIs should not consume request- or upload-controlled filenames. |
+| `Avoid permissive file modes` | Files that can carry user or security data should not be created with world-accessible modes. |
+| `` Avoid wildcard `postMessage` targets `` | `postMessage` calls should not use `*` as the target origin when they carry application data. |
+| `Avoid raw HTML with request input` | Request-derived values should not be interpolated into raw HTML strings. |
+| `Avoid sensitive data in thrown errors` | Exceptions and rejection payloads should not include raw secrets or personal data. |
+| `Avoid writing sensitive data to files` | Data exports and local file writes should not persist raw secrets or personal fields. |
+| `Avoid leaking sensitive or diagnostic state` | Logs, stdout or stderr, and direct response sinks should not expose sensitive fields or internal diagnostic detail. |
+| `Do not derive anti-framing headers from request input` | Framing and CSP headers should not be set from request-controlled values. |
+| `Avoid request-controlled format strings` | Logging and formatting helpers should not take request input as the format string itself. |
+| `` Constrain `res.sendFile` to a trusted root `` | `res.sendFile()` should not resolve filenames or options from request input without a trusted root. |
+| `` Constrain `res.render()` trust boundaries `` | Express view names should not cross into server-side rendering from untrusted input. |
+| `Avoid exposed directory listings` | Directory listing middleware should not be enabled on public paths without a deliberate review. |
+| `Override Express session defaults` | Express session middleware should not rely on default session naming and configuration. |
+| `Override Express cookie defaults` | Express session cookie settings should not omit explicit lifetime, scope, and transport attributes. |
+| `Avoid permissive Express session cookie scope` | Express session cookies should not explicitly opt into cross-site or wildcard-style scope. |
+| `Serve static assets before session middleware` | Static assets should be mounted before session middleware when they do not need session state. |
+| `Apply Helmet to Express apps` | Express apps should use Helmet or equivalent header hardening middleware. |
+| `Reduce Express fingerprinting` | Express apps should disable `x-powered-by` or equivalent fingerprinting headers. |
+| `Do not expose debug routes or middleware in production` | Debug handlers, stack-showing middleware, and diagnostic endpoints should stay behind explicit development-only guards. |
+| `Avoid unsafe raw HTTP response output` | Raw response writers should not echo request data into HTML-capable responses without trusted escaping or sanitization. |
 
-## Rule Register
+### Correctness
 
-Each entry lists the shipped rule id, its preset membership, and the main
-pattern it checks.
+| Rule title | Description |
+| --- | --- |
+| `Always-true or always-false condition` | Flow-control conditions should not resolve to a constant boolean value. |
+| `Implicit undefined return in function` | Functions that return a value on some paths must not fall through implicitly. |
+| `Unhandled promise rejection or async error` | Promise chains started in a function should terminate with explicit rejection handling. |
+| `Incorrect boolean logic (AND/OR misuse)` | Comparison chains on the same value must use the boolean operator that matches the intended logic. |
+| `Blocking call inside async flow` | Async functions should not call synchronous blocking APIs on the hot path. |
+| `Missing default case in switch or conditional dispatch` | Dispatch constructs should include an explicit default or final else path. |
+| `Missing timeout on external call` | External HTTP calls should declare timeout or cancellation behavior. |
+| `Possible null or undefined dereference` | Nullable values should be guarded before property access or invocation. |
+| `Nested property access without existence check` | Deep property chains derived from external input should verify intermediate values before access. |
+| `Unchecked map or dictionary key access` | Lookups should verify key presence before reading from maps or keyed objects. |
+| `Optional value used without fallback` | Optional values should be normalized before arithmetic, concatenation, or other direct use. |
+| `Off-by-one error in loop boundaries` | Index-based loops should not skip the first element or iterate one step past the collection boundary. |
+| `Race condition on shared state` | Async functions that mutate shared state after an await boundary should be reviewed for races. |
+| `Unreachable code after return or throw` | Statements after terminal exits should be removed or moved before the exit. |
 
-### Logging And Runtime
+### Performance
 
-- `ts.logging.no-console-log` (`recommended`, `strict`): direct `console.log(...)` calls.
-- `ts.logging.no-console-error` (`recommended`, `strict`): direct `console.error(...)` calls.
-- `ts.runtime.no-debugger-statement` (`recommended`, `strict`): `debugger;` statements in committed code.
+| Rule title | Description |
+| --- | --- |
+| `Sequential async calls that could run in parallel` | Independent awaited calls in the same block should not serialize unnecessarily. |
+| `Repeated expensive computation` | Repeating the same expensive computation in one block should usually be cached. |
+| `Inefficient data structure usage` | Linear membership checks or key projections should be reviewed for more suitable lookup structures. |
+| `Nested loops in hot path (O(n²) risk)` | Nested loops in the same function should be reviewed for quadratic work on larger inputs. |
+| `Missing batching of operations` | Repeated one-by-one operations inside loops should prefer available batch-style helpers. |
+| `Large payload processing without streaming` | Whole-payload reads of likely large content should be reviewed for streaming alternatives. |
+| `Potential memory leak from unbounded growth` | Shared collections that only grow should be reviewed for eviction or lifecycle boundaries. |
+| `Unnecessarily retained large object` | Large payloads assigned into shared state should be reviewed for shorter lifetimes. |
+| `Unnecessary re-renders from state misuse` | React state setters invoked directly during render should be reviewed for rerender loops. |
 
-### Correctness
+### Quality
 
-- `ts.correctness.constant-condition` (`recommended`, `strict`): flow-control tests that resolve to a constant boolean.
-- `ts.correctness.missing-await-on-async-call` (`recommended`, `strict`): direct async work dropped inside async functions without `await`.
-- `ts.correctness.implicit-undefined-return` (`recommended`, `strict`): functions that return a value on some paths but fall through on others.
-- `ts.correctness.unhandled-async-error` (`recommended`, `strict`, `security`): promise chains without a terminal rejection handler.
-- `ts.correctness.incorrect-boolean-logic` (`recommended`, `strict`): same-discriminant comparison chains using the wrong boolean operator.
-- `ts.correctness.blocking-call-in-async-flow` (`recommended`, `strict`): blocking synchronous APIs inside async code paths.
-- `ts.correctness.missing-default-dispatch` (`recommended`, `strict`): `switch` or `if` dispatch chains without a default or final `else`.
-- `ts.correctness.missing-timeout-on-external-call` (`recommended`, `strict`, `security`): `fetch` or axios-style calls without timeout or cancellation configuration.
-- `ts.correctness.possible-null-dereference` (`recommended`, `strict`): nullable local aliases dereferenced or invoked without a guard.
-- `ts.correctness.nested-property-access-without-check` (`recommended`, `strict`): deep request-derived property chains without existence checks.
-- `ts.correctness.unchecked-map-key-access` (`recommended`, `strict`): dictionary-like `Map#get(...)` or keyed-object reads without a presence check.
-- `ts.correctness.optional-value-without-fallback` (`recommended`, `strict`): optional aliases used directly in expressions without `??`, `||`, or a guard.
-- `ts.correctness.off-by-one-loop-boundary` (`recommended`, `strict`): index-based loops that skip the first element or iterate past `.length`.
-- `ts.correctness.shared-state-race` (`experimental`): shared or outer-scope state mutated after an `await` boundary.
-- `ts.correctness.unreachable-statement` (`recommended`, `strict`): statements after `return` or `throw`.
-
-### Quality, Config, And Determinism
-
-- `ts.quality.swallowed-error` (`recommended`, `strict`): `catch` blocks that drop errors silently.
-- `ts.quality.function-too-large-or-complex` (`strict`): oversized or high-complexity functions.
-- `ts.quality.duplicate-code-block` (`strict`): large near-identical function bodies duplicated across files.
-- `ts.quality.deep-nesting` (`strict`): deeply nested control flow.
-- `ts.quality.missing-error-context` (`strict`): `catch` paths that log or rethrow without preserving the original error.
-- `ts.quality.tight-module-coupling` (`strict`): direct local import cycles between modules.
-- `ts.quality.hardcoded-configuration-values` (`recommended`, `strict`): top-level config-like identifiers or properties bound to literals.
-- `ts.quality.magic-numbers-or-strings` (`strict`): non-trivial literals embedded directly in logic.
-- `ts.quality.missing-tests-for-critical-logic` (`strict`): critical auth or payment-like logic without a matching test file.
-- `ts.quality.logic-change-without-test-updates` (`strict`): changed critical logic in a diff without a changed matching test file.
-- `ts.config.no-process-env-outside-config` (`strict`): `process.env.*` access outside config modules.
-- `ts.random.no-math-random-in-core` (`strict`): `Math.random()` under `**/core/**`.
+| Rule title | Description |
+| --- | --- |
+| `Errors swallowed silently` | Catch blocks must log, reject, or rethrow failures instead of dropping them silently. |
+| `Function too large or too complex` | Oversized or overly complex functions should be split into smaller units. |
+| `Duplicate code block` | Large duplicated function bodies across files make behavior harder to maintain safely. |
+| `Deep nesting reducing readability` | Deeply nested control flow should be flattened where practical. |
+| `Missing error context or logging` | Catch blocks should include the caught error when they log or rethrow. |
+| `Tight coupling between modules` | Direct import cycles between modules increase coupling and make change boundaries harder to maintain. |
+| `Hardcoded configuration values` | Config-like values should usually come from configuration sources rather than source literals. |
+| `Magic numbers or magic strings` | Non-trivial literals in logic should be named to explain their meaning. |
+| `Missing tests for critical logic` | Critical auth, payment, or similar business logic should have a matching test file. |
 
-### Performance
+### Logging
 
-- `ts.performance.sequential-async-calls` (`recommended`, `strict`): independent awaited calls serialized in one block.
-- `ts.performance.repeated-io-in-loop` (`recommended`, `strict`): direct or one-hop local IO helpers invoked inside loops.
-- `ts.performance.repeated-expensive-computation` (`recommended`, `strict`): the same expensive computation repeated in a local block.
-- `ts.performance.inefficient-data-structure-usage` (`recommended`, `strict`): linear membership scans or key-projection checks where a better lookup structure fits.
-- `ts.performance.nested-loops-hot-path` (`strict`): loop nesting that creates quadratic hot paths.
-- `ts.performance.missing-batch-operations` (`strict`): looped one-by-one helper calls when a batch or bulk variant is available locally.
-- `ts.performance.large-payload-without-streaming` (`strict`): likely large file or response payloads loaded eagerly instead of streamed.
-- `ts.performance.unbounded-growth-memory-leak` (`strict`): shared collections that only grow and never evict.
-- `ts.performance.retained-large-object` (`experimental`): large payloads assigned into shared state and retained longer than needed.
-- `ts.performance.unnecessary-rerenders-from-state-misuse` (`experimental`): React state setters called directly during render.
+| Rule title | Description |
+| --- | --- |
+| `Avoid console.log` | Use the project logger instead of console.log. |
+| `Avoid console.error` | Route error logs through the project logger. |
 
-### Security
+### Config
+
+| Rule title | Description |
+| --- | --- |
+| `` Avoid direct `process.env` access outside config `` | Keep environment variable access inside config modules. |
+
+### Random
+
+| Rule title | Description |
+| --- | --- |
+| `` Avoid `Math.random()` in core code `` | Core code should not depend on nondeterministic random generation. |
+
+### React
+
+| Rule title | Description |
+| --- | --- |
+| `Avoid cascaded fetches inside React effects` | React effects should not serialize independent fetches that can run in parallel or move server-side. |
+
+### Runtime
+
+| Rule title | Description |
+| --- | --- |
+| `` Remove `debugger;` `` | Remove debugger statements before committing source files. |
+
+## License
 
-- `security.no-sql-interpolation` (`recommended`, `strict`, `security`): raw or interpolated SQL text passed into query sinks.
-- `ts.security.no-dynamic-execution` (`recommended`, `strict`, `security`): `eval`, `Function`, `vm`, or string-evaluated timer execution.
-- `security.no-request-path-file-read` (`recommended`, `strict`, `security`): file reads using request-controlled paths.
-- `ts.security.non-literal-fs-filename` (`recommended`, `strict`, `security`): direct filesystem reads using request- or upload-controlled filenames.
-- `ts.security.file-generation` (`recommended`, `strict`, `security`): local file writes whose destination path is derived from external input.
-- `ts.security.external-file-upload` (`recommended`, `strict`, `security`): upload handlers that persist attacker-controlled filenames directly.
-- `security.no-command-execution-with-request-input` (`recommended`, `strict`, `security`): process execution helpers given request-controlled executables or shell-interpreted arguments.
-- `ts.security.dangerous-insert-html` (`recommended`, `strict`, `security`): unsafe `outerHTML`, `document.write*`, or `insertAdjacentHTML` use with non-literal, non-sanitized HTML.
-- `ts.security.dangerously-set-inner-html` (`recommended`, `strict`, `security`): React `dangerouslySetInnerHTML` given non-literal, non-sanitized HTML.
-- `ts.security.no-innerhtml-assignment` (`recommended`, `strict`, `security`): `innerHTML` assignment without fixed or explicitly sanitized HTML.
-- `security.no-hardcoded-credentials` (`recommended`, `strict`, `security`): credential-like literals embedded in source.
-- `ts.security.handlebars-no-escape` (`recommended`, `strict`, `security`): `Handlebars.compile(..., { noEscape: true })`.
-- `ts.security.missing-authorization-before-sensitive-action` (`strict`, `security`): backend-like sensitive handlers without a local authorization guard.
-- `ts.security.missing-ownership-validation` (`strict`, `security`): auth-gated handlers acting on caller-supplied resource ids without an ownership check.
-- `ts.security.frontend-only-authorization` (`experimental`): frontend-auth-gated literal route calls whose matching backend route lacks authorization.
-- `ts.security.token-or-session-not-validated` (`recommended`, `strict`, `security`): token or session values from external input used without same-function validation.
-- `security.tls-verification-disabled` (`recommended`, `strict`, `security`): transport clients configured to skip certificate verification.
-- `security.insecure-http-transport` (`recommended`, `strict`, `security`): outbound requests sent over plain HTTP to non-local endpoints.
-- `security.weak-hash-algorithm` (`recommended`, `strict`, `security`): MD5, SHA-1, or similar weak hashing primitives used in security-sensitive flows.
-- `ts.security.weak-cipher-or-mode` (`recommended`, `strict`, `security`): weak or obsolete cipher selections such as ECB mode, DES-family ciphers, RC4, Blowfish, or RSA no-padding.
-- `ts.security.predictable-token-generation` (`recommended`, `strict`, `security`): auth-like tokens, invite codes, or reset helpers derived from `Math.random`, timestamps, or other predictable sources.
-- `ts.security.insufficiently-random-values` (`recommended`, `strict`, `security`): secret-like values generated from cryptographic APIs with less than 16 bytes of entropy.
-- `ts.security.weak-key-strength` (`recommended`, `strict`, `security`): explicit RSA, AES, or HMAC key-generation settings below modern minimum sizes.
-- `ts.security.missing-integrity-check` (`recommended`, `strict`, `security`): token or secret encryption helpers using non-AEAD modes or predictable IVs without same-function integrity protection.
-- `ts.security.insecure-password-hash-configuration` (`recommended`, `strict`, `security`): legacy or obsolete password-hash configuration such as insecure Argon2 mode selections.
-- `ts.security.unvalidated-external-input` (`strict`, `security`): request-derived values used to construct `RegExp` or `URL` without validation.
-- `security.unsafe-deserialization` (`recommended`, `strict`, `security`): `JSON.parse`, `yaml.load`, `qs.parse`, or similar deserializers fed external input.
-- `ts.security.missing-request-timeout-or-retry` (`strict`, `security`): external calls with neither timeout or cancellation nor retry protection.
-- `ts.security.unsanitized-http-response` (`recommended`, `strict`, `security`): raw `res.send`, `res.write`, or `res.end` output of request-derived HTML without trusted escaping or sanitization.
-- `ts.security.permissive-file-permissions` (`recommended`, `strict`, `security`): world-accessible file or directory modes on creation helpers or `chmod`.
-- `ts.security.user-controlled-sendfile` (`recommended`, `strict`, `security`): `res.sendFile()` paths or options driven by external input without a trusted root.
-- `ts.security.exposed-directory-listing` (`recommended`, `strict`, `security`): explicit directory-listing middleware such as `serveIndex`.
-
-## Notes
-
-- `recommended` is the baseline OSS preset.
-- `strict` adds higher-noise or more opinionated rules.
-- `security` is the security-focused slice of the catalog.
-- `experimental` holds narrower heuristics that are shipped but not enabled by
-  default.
-
-For executable examples, see the sandbox scenarios under
-[`critiq-sandbox/scenarios`](</Users/aavanzyl/Documents/personal/critiq/critiq-sandbox/scenarios>).
+`@critiq/rules` is licensed under [Apache 2.0](https://www.apache.org/licenses/LICENSE-2.0). See the package [LICENSE](https://github.com/critiq-dev/critiq-rules/blob/main/libs/rules/catalog/LICENSE).

package/package.json

@@ -1,8 +1,9 @@
 {
   "name": "@critiq/rules",
-  "version": "0.0.1",
+  "version": "0.0.2",
   "private": false,
   "description": "Public OSS Critiq rule catalog with catalog metadata, shipped rule YAML files, and preset membership.",
+  "license": "Apache-2.0",
   "type": "commonjs",
   "main": "./src/index.js",
   "types": "./src/index.d.ts",