mirror of
https://github.com/hanzoai/insights.git
synced 2026-11-03 00:52:32 +00:00
zeekayandHanzo Dev
724b974e58
`ee/` is empty -- the AI agent code moved to `products/insights_ai/` --
but 58 references to `ee/hogai/**` outlived it. None of them is a
cosmetic mention. A path filter that matches nothing is a lint rule that
lints nothing and a CI job that tests nothing, and it fails silently,
which is the only reason it survived this long.
Verified against disk, then removed or repointed:
.semgrep no-init-reexports 19 grandfathered excludes for __init__.py
files that are gone. The rule's own
preamble says to drop a line when its file
goes. Every __init__.py under
products/insights_ai that re-exports is
already excluded, so no new finding
appears.
ci-dagster path filter `ee/hogai/**`, beside a
products/insights_ai/backend line that
already covers what the DAGs import
container-images-cd `^ee/hogai/session_summaries` in two
worker-trigger alternations, dropped with
its separator so the ERE stays well formed
`.github/workflows/ci-ai.yml` is deleted rather than repointed. It is
upstream's Braintrust eval pipeline: gated on `github.repository ==
'Insights/insights'` so it can never run here, needing upstream
secrets, naming eleven eval files that no longer exist, and invoking
them with pytest when the suites that replaced them do not run under
pytest. Repointing the six paths that do have successors would have
produced a job that collects nothing and reports green. Its only
dependent, `eval-summary`, goes with it.
`.agents/skills/implementing-agent-modes` is deleted for the same
reason. It documents `mode_registry`, `AgentModeDefinition`,
`mode_manager.py` and an `agent_modes/presets` directory, none of which
exists in any language in this tree -- only the vestigial `AgentMode`
enum in the schema. Two of its four paths have successors, but
repointing those would leave a skill instructing an agent to edit a
registry that is not there.
Docs keep their meaning rather than their spelling: where a successor
exists it is named, and where one does not, the dead cross-reference
goes rather than being pointed somewhere almost-right. The security note
loses a citation to a stream that no longer exists (the surviving
analogue serializes with json, so naming it would make the sentence
false), and the gateway comment loses a file:line that would now be a
lie.
Left alone: LLM.md and bin/check-imports-are-committed both name
`from ee.hogai...` deliberately, as the import that once sat in a module
the temporal graph loads eagerly. That is the story, not a reference.
The review eval fixtures quote captured upstream diffs and are history.
Co-authored-by: Hanzo Dev <[email protected]>
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.