Ase Code Analyze

@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md @${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md

$ARGUMENTS

1. Only output the following and then STOP the entire flow (do not perform any further steps):

2. In this STEP 2, investigate on the code. If the code base is large, you MUST use the Agent tool (not inline work) to create multiple sub-agents to split the investigation task into appropriate chunks.

   Tenets:

   • Quiet Operation:

     During investigation in this STEP 2, do not output anything else, especially do not give any further explanations or information.

   • Practical Relevance Only:

     Focus on practically relevant cases and especially do not investigate theoretical or fictive cases.

   • Problem Focus Only:

     Still focus on the problem only and do not already investigate any possible solution or apply any change.

   • Lens Focus:

     Focus on performance and efficiency only - and do not investigate logic, semantics, control flow, or security problems.

     Analysis Hints (not exhaustive, just indicators):

     • high algorithmic complexity
     • needless resource allocations/copies
     • redundant recomputation
     • many I/O and query round-trips
     • concurrency bottlenecks
     • mismatched data structures
     • N+1 query patterns (1 parent query, N child queries)
     • missing caching/memoization of stable results
     • blocking/synchronous calls on hot paths
     • unbounded growth (memory leaks, ever-growing collections)
     • inefficient string building/concatenation in loops
     • premature or repeated serialization/parsing
     • lack of batching/pagination for bulk operations
     • excessive logging or instrumentation overhead
     • chatty network protocols (no connection pooling/keep-alive)
     • lock contention and overly coarse-grained locking
     • eager/over-fetching of data that is never used
     • missing database indexes
     • repeated regex (re)compilation in hot paths
     • busy-waiting/polling instead of event-driven waits
     • transferring uncompressed or overly verbose payloads
     • missing short-circuit evaluation in expensive conditions
     • recomputing invariants inside loops (loop-invariant code)
     • suboptimal batch sizes (too small = overhead, too large = latency)
     • inefficient algorithms for sorting/searching already-ordered data
     • redundant validation/sanitization of trusted internal data
     • missing connection/resource reuse (open-close per operation)
     • [...]

     Focus on security only - and do not investigate logic, semantics, performance, or efficiency problems.

     Analysis Hints (not exhaustive, just indicators):

     • unsafe data deserialization
     • missing input data validation/sanitization
     • broken authentication/authorization
     • sensitive-data exposure
     • path traversal
     • unsafe cryptography
     • hard-coded secrets
     • vulnerable dependencies
     • injection flaws
     • cross-site scripting (XSS) and output-encoding gaps
     • cross-site request forgery (CSRF) and missing anti-forgery tokens
     • insecure direct object references (IDOR)
     • server-side request forgery (SSRF)
     • insecure or missing transport encryption (TLS)
     • weak session management (fixation, predictable tokens)
     • missing rate limiting/anti-automation controls
     • overly permissive CORS or file permissions
     • verbose error messages leaking internals
     • unsafe randomness for security-sensitive values
     • mass assignment / over-binding of request parameters
     • security misconfiguration (default credentials, debug modes, exposed admin endpoints)
     • missing or misconfigured security headers (CSP, HSTS, X-Frame-Options)
     • improper certificate/hostname validation (TLS verification disabled)
     • insufficient logging and monitoring of security events
     • race conditions / TOCTOU (time-of-check to time-of-use) flaws
     • integer overflow/underflow and buffer overflows
     • use-after-free and memory-safety violations
     • privilege escalation through improper privilege dropping
     • insecure file upload handling (unrestricted type/size, executable storage)
     • unsafe handling of untrusted regular expressions (ReDoS)
     • caching of sensitive data in shared or client-side caches
     • secrets or sensitive data leaking into logs, traces, or telemetry
     • insecure default-deny failures (fail-open instead of fail-closed)
     • missing integrity verification (unsigned updates, no subresource integrity)
     • excessive data exposure in API responses (returning more fields than needed)
     • improper resource cleanup leading to exhaustion (connection/file-descriptor leaks)
     • business-logic flaws (bypassable workflows, negative quantities, replay)
     • [...]

     Focus on problems in the logic and semantics and the related control flow only - and do not investigate performance, efficiency, or security problems.

     Analysis Hints (not exhaustive, just indicators):

     • incorrect conditionals and boolean logic
     • off-by-one and boundary errors
     • operator misuse
     • mishandled edge cases
     • broken or missing error handling
     • incorrect async/await/promise handling
     • control-flow defects (unreachable code, missing breaks, wrong early returns)
     • state-mutation bugs
     • incorrect default values
     • null/undefined mishandling
     • type-coercion bugs
     • faulty parsing or merge/override semantics
     • race conditions and unsynchronized shared state
     • resource leaks (unclosed files, handles, connections)
     • inverted or swapped function arguments
     • incorrect loop termination or accumulator initialization
     • shadowed or reassigned variables changing intent
     • incomplete switch/case or enum coverage
     • silent exception swallowing
     • floating-point comparison and rounding errors
     • integer overflow/underflow or truncating division
     • sign and modulo errors with negative operands
     • reference vs. value semantics (aliasing, shared mutable defaults)
     • incorrect short-circuit evaluation or operator precedence
     • logical vs. bitwise operator confusion
     • negation mistakes in compound predicates
     • wrong comparison operator (== instead of ===, < vs. <=, etc)
     • inverted condition or swapped if/else branches
     • dead or duplicated conditional branches
     • fall-through where a break or return was intended
     • missing or misplaced base case in recursion (non-termination)
     • mutation of a collection while iterating over it
     • incorrect index, key, or bounds when accessing collections
     • empty-collection or single-element edge cases unhandled
     • wrong order of operations in initialization or teardown
     • missing cleanup on early return, break, or exception path
     • double-free, use-after-free, or double-close of resources
     • incorrect time-zone, date arithmetic, or unit conversions
     • stale cache or memoization not invalidated on change
     • incorrect deep vs. shallow copy semantics
     • partial or non-atomic updates leaving inconsistent state
     • ignored or unchecked return values and status codes
     • error code vs. exception path mismatch
     • catching too broad an exception masking real failures
     • re-throwing without preserving the original cause
     • incorrect equality, hashing, or ordering for custom types
     • regex anchoring, greediness, or escaping mistakes
     • string encoding, normalization, or case-folding errors
     • missing await causing unhandled or dropped promises
     • incorrect promise concurrency (all vs. allSettled, races)
     • callback invoked zero times, twice, or out of order
     • unguarded re-entrancy or recursive lock acquisition
     • incorrect guard ordering allowing invalid states through
     • assumptions about iteration order of maps/sets/objects
     • [...]

   You MUST not output anything in this STEP 2.

3. Before reporting, apply the severity floor selected via (default LOW): define the ordinal rank LOW=1, MEDIUM=2, HIGH=3. Keep a detected problem if and only if its is ACCEPTED or rank(severity) is greater than or equal to rank(<getopt-option-severity/>); silently drop all other problems (they are neither reported nor persisted). With the default floor LOW, all problems are kept. ACCEPTED problems are never dropped.

   Then renumber the surviving problems contiguously as P<n/> with = 1, 2, ... in the original ordering. If all problems are dropped, skip the per-problem report but still purge any stale persisted problems with a single ase_kv_batch call to the ase MCP server with transactional set to true and a commands parameter array holding exactly one { command: "clear", prefix: "ase-issue-" } entry, and still emit the final hint below.

   In this STEP 3, for EVERY surviving problem, immediately report it with the following output , based on concise bullet points.

   PROBLEM (Severity: ): P:

   ⊙ EVIDENCE: ⊖ TRADEOFF:

   PROBLEM (Severity: ): P:

   Hints:

   • For the final results, do not output anything else, especially do not give any further explanations or information.

   • Uniquely identify the problems with P<n/> where is 1, 2, ...

   • In , use ultra brief but still as precise as possible problem descriptions.

   • In , highlight code as <code/> and key aspects as .

   • In , add inline references to the related code positions in the form of either (<filename/>:<line-number/>), (<filename/>:<line-number/>-<line-number/>) or (<filename/>#<function-or-method/>).

   • In , classify the problem with a of LOW, MEDIUM, HIGH, or ACCEPTED, ranked by the estimated impact of the problem. Use ACCEPTED when the problem is a deliberate, justified trade-off that should remain on record but is never dropped by the severity floor (see STEP 3).

   • For ultra-compress the to a concise, short, single sentence. Keep one inline reference to the code position which is most relevant to the problem.

   • Additionally, persist all reported problems in a single ase_kv_batch call to the ase MCP server with transactional set to true. The commands parameter array of this call starts with one { command: "clear", prefix: "ase-issue-" } entry (which removes only the previously persisted ase-issue-* keys, leaving any unrelated keys in the shared store intact), followed by one { command: "set", key: "ase-issue-P<n/>", val: "<title/>: <description/>" } entry per reported problem.

   Finally, output the following to give a final hint:

   You MUST not output anything else in this STEP 3, especially not any further explanations.