Skip to content

4X4.md

Latest commit

 

History

History
105 lines (74 loc) · 7.82 KB

4X4.md

File metadata and controls

105 lines (74 loc) · 7.82 KB
client Hypercart / Neochrome
repo https://github.com/Hypercart-Dev-Tools/WP-Code-Check.git
last_edit 2026-03-23
week_of 2026-03-23
source_pr_number n/a
sprint planning-refresh

Pro-tip: Ask your VS Code AI to self populate the metadata above.

4x4 Dashboard - Strategic Goals & Weekly Checklist

A simple, actionable framework to prioritize and track engineering tasks. Focus on alignment, transparency, continuous improvement, and increasing clarity for everyone. This document does not replace your project management tools. It is meant to be a simple, actionable checklist to help you focus on the most important tasks for the week.

About the Current Project

WP Code Check is a zero-dependency static analysis toolkit for WordPress performance, security, and reliability issues. Current engineering focus is stabilizing the search backend, reducing false positives in noisy direct-pattern rules, restoring fixture parity, and creating a measured path for an optional Semgrep backend without destabilizing the Bash scanner.

1. Strategic Backlog

Maximum of 4 items. Focus on long-term goals and impactful improvements. Update/Reminder: If these are new projects without a clear scope, consider using the Project Scope Outline below.

    • Unify search backends under one wrapper layer - Replace timeout-wrapped raw file-discovery calls and helper fallbacks with a single API for file discovery, line matches, and context extraction.
    • Restore fixture and scorecard trust - Audit failing fixtures, align expected counts with intended semantics, and make regression output credible before larger rule migrations.
    • Pilot Semgrep on the highest-noise direct rules - Start with unsanitized-superglobal-read, unsanitized-superglobal-isset-bypass, wpdb-query-no-prepare, and file-get-contents-url using side-by-side scorecards.
    • Continue rule quality cleanup in Bash - Keep reducing false positives where the current engine is already close, especially heuristics and context-sensitive detectors that do not map cleanly to Semgrep.

2. Current Week

Active tasks for the week. Maximum of 4 items.

Tip: If your team frequently handles urgent issues, consider reserving 1-2 slots for hotfixes. Otherwise, use all 4 slots for planned work.

  • Refresh planning source of truth - Updated the Semgrep migration plan to match the current codebase, deprecated BACKLOG.md, and moved active planning into this 4X4.
  • Add file-discovery wrapper spike - Draft cached_file_search() or equivalent and replace one or two high-value call sites such as AJAX_FILES and TERMS_FILES to prove the interface. Benefit: fewer one-off search code paths, easier maintenance, and a lower chance that one slow check behaves differently from the rest.
  • Add observability for slow checks - Implement per-check timeout warnings and a small top-N slow-check summary so long scans stop looking stuck. Benefit: users can see what is slow, what timed out, and whether the scanner is still making progress instead of guessing that it froze.
  • Audit fixture mismatches and shortlist Semgrep pilots - Re-run failing fixtures, classify false positives vs desired behavior, and finalize the first four Semgrep scorecard candidates. Benefit: more trustworthy test results, clearer migration decisions, and less risk of moving a noisy or inaccurate rule to a new backend.

3. Previous Week

Review completed, deferred, or blocked tasks from the prior week.

  • Added Path B observability for aggregated magic-string patterns - phase timing and quality counters are now visible in text and JSON output.
  • Fixed stale-registry fallback behavior - eliminated one apparent hang path in the pattern loader and guarded empty search patterns.
  • Fixed high-noise direct-pattern false positives - reduced php-shell-exec-functions, spo-002-superglobals, and php-dynamic-include noise with targeted scanner and pattern fixes.
  • Cleared all deferred items from CR self-service feedback review — added admin-only hook whitelist for spo-004 (downgrade to INFO) and strengthened N+1 loop detection with brace-depth lexical containment in find_meta_in_loop_line().
  • Round 2 FP reduction pass on CR self-service scan — tightened limit-multiplier-from-count pattern (24 → 0 FPs), added skip_if_context_matches to suppress non-GET rest-no-pagination endpoints (16 → 8), and cross-rule dedup for superglobal rules (eliminated 23 duplicates). Total findings: 99 → 31.
  • Phase 0b observability remains incomplete - heartbeat output and slow-check rollups are still deferred and need a focused pass.

4. Recent Lessons Learned

Capture insights to improve processes and avoid repeating mistakes.

  1. Small search-path inconsistencies create outsized noise - most recent false positives came from runner behavior and shell quoting, not from the pattern ideas themselves.
  2. Timeout protection is necessary but not sufficient - a timed-out check that silently passes prevents hangs, but it also hides diagnostic value unless we surface warnings and timing data.
  3. Planning drift happens fast in a monolithic script - line-number-based roadmap docs stale quickly, so strategic docs need periodic refreshes tied to current code references.
  4. Not every noisy rule is a Semgrep problem first - if a Bash rule is already close after a targeted fix, it should drop in Semgrep priority behind noisier or structurally simpler candidates.

Bonus: Project Scope Outline

Note: This section is a work-in-progress and is being developed as a natural extension of the 4x4 methodology. It is not yet a core part of the framework but is included here as a supplementary tool for teams who want to add more context to their planning.

1. Goals

Keep WP Code Check fast, explainable, and operationally reliable while improving detection quality on high-value WordPress performance and security checks.

2. Assumptions

  • The current Bash scanner remains the default engine through any Semgrep pilot.
  • Search backend stabilization should land incrementally rather than via a large rewrite.
  • Fixture parity work is required before scorecards will be trusted for migration decisions.
  • The highest-value weekly work is small and verifiable: one wrapper spike, one observability pass, one fixture audit pass.

3. Potential Risks

  • Semgrep rules may look cleaner on paper but still miss WordPress-specific context that the Bash pipeline currently encodes.
  • Wrapper changes can improve maintainability while accidentally changing output parity if they are not backed by fixture comparisons.
  • Monolithic-script edits can create regression risk in unrelated checks unless changes stay narrow and verified.
  • Planning can split across too many docs unless this file stays the active weekly view.

4. Long-Term Maintainability

Long-term sustainability depends on shrinking the amount of bespoke search behavior in check-performance.sh, keeping rule logic externalized where possible, maintaining trustworthy fixtures, and promoting only the rules to Semgrep that clearly beat the Bash implementation on quality and runtime.

How to Use This Template

For detailed guidance on the 4x4 framework, see the README.

Quick tips:

  • Update this document weekly (move "Current Week" to "Previous Week" and plan your new week)
  • Limit each section to 4 items maximum to maintain focus
  • Capture lessons learned immediately while they're fresh
  • Link to detailed tasks in your project management tools (GitHub, Jira, etc.)

License

This work is licensed under the Creative Commons Attribution 4.0 International (CC BY 4.0) License. To view a copy of this license, visit https://creativecommons.org/licenses/by/4.0/.

Copyright © 2026 Hypercart DBA Neochrome, Inc. | 4x4Clarity.com