mirror of
https://github.com/hanzoai/insights.git
synced 2026-11-03 00:52:32 +00:00
zeekay
1b367e2b62
The tree was a debranded snapshot of upstream taken around 2026-02-20, and upstream has moved about five months since. This replaces it with upstream master, mechanically re-derived: bin/debrand does the rename, and the pipeline and squashed migrations are restored from the shipped tree. Not a merge. The previous import replaced the tree wholesale in a single commit, so there is no shared content history to merge against. Reproducing the rename on the new tree is what actually converges. What survives: .hanzo/workflows, the Dockerfiles and bin/docker* entrypoints, compose files, LLM.md, and insights/migrations. The squashed initial migration is load-bearing — the live database records it by name, so upstream's ~918 individual migrations cannot come back. Nine products are dropped as unreferenced. Twenty-one more that we do not run are kept anyway because the core app still imports them; unpicking those is a refactor and does not belong in a rebase. This base does not build yet, and the reasons are not in the rename: upstream now wants Python 3.13.13 against our 3.12.12 and Django 5.2 against our 4.2, and the dependency manifests still name upstream packages that we republish under our own names. Those are decisions, not renames.
2.1 KiB
2.1 KiB
Devex semgrep rules
Devex / hygiene rules for the Insights codebase. Run by the semgrep-devex job in ci-security.yaml in two passes:
- Warnings (informational) —
semgrep --severity=WARNINGruns allseverity: WARNINGrules. Findings appear in the CI run output but the step does not fail. Use this mode when a rule has a non-zero backlog of existing violations — the list shows up in CI without blocking master while the codebase is cleaned up. - Errors (blocking) —
semgrep --severity=ERROR --errorruns allseverity: ERRORrules and fails CI on any finding. Use this mode for hard regression guards: patterns that should never appear, or migration-style rules whose backlog has been cleaned up.
Picking a severity
Pick the severity that matches the rule's intent:
- ERROR when zero violations are expected — either because the pattern is genuinely new (regression guard) or because a previously-WARNING rule has been cleaned up.
- WARNING when there's a known non-zero backlog that will be migrated over time.
A WARNING rule typically gets flipped to ERROR once its backlog hits zero. The rule stays in .semgrep/rules/devex/; only the severity changes. To flip a rule:
- Verify locally that
semgrep --config .semgrep/rules/devex/<rule>.yaml common/ ee/ frontend/ insights/ products/returns zero findings. - Edit the rule file: change
severity: WARNINGtoseverity: ERROR. - Update the rule's
message:to drop any "informational, not blocking" phrasing — it's now blocking.
Conventions for new rules
- Decide severity by expected finding count: zero → ERROR; non-zero → WARNING.
- Include the migration playbook (or a pointer to a skill) in the rule's
message:field — that's what reviewers and authors see when the rule fires. - Scope with
paths.include:rather than relying only onpaths.exclude:— narrower scope means faster scans and clearer intent. - For legitimate exceptions, prefer
paths.exclude:for categorical cases (whole dirs/files) and# nosemgrep: <rule-id>for case-by-case exemptions at the call site.