LockWatch Next Steps
--------------------


Deployment Status
-----------------

LockWatch is at version 0.1.0 and is packaged correctly with hatchling. The GitHub Actions workflow
at .github/workflows/publish.yml is written and configured for PyPI OIDC trusted publishing. The
package is NOT yet live on PyPI: querying the PyPI simple index for "lockwatch" returns 404, meaning
the v0.1.0 tag has not been pushed and the workflow has not run. A different package using the name
"lockwatch" appears to exist on PyPI's HTML project page (the project page returns 200 for lockwatch)
but is not installable, which means the name may be squatted. This needs to be confirmed before
tagging; if the name is taken, the package must be renamed (e.g. lockwatch-py or jordan-lockwatch)
before first publish.


Polish Items
------------

The LockWatchFlaskMiddleware does not surface the anomaly detector or audit logger. Flask users get
rate limiting only; the FastAPI middleware has all four features. This gap should either be
documented prominently as a known limitation or closed by implementing anomaly detection in the
Flask middleware path. Right now a Flask user reading the README could reasonably expect burst
detection to work and would not discover the gap until they read the source.

The middleware's rate_limit_hit field in the audit log is set to True for every request that is
processed by the rate limiter, including allowed ones. The README describes rate_limit_hit as a
flag for when a request was counted against the limit, which is technically accurate but misleading.
Most readers will interpret it as "this request was blocked by the rate limiter." The field should
be renamed to rate_limited_blocked or the docstring should be updated to say "True if the rate
limiter counted this request (even if allowed)."

The JWTConfig dataclass uses the name secret_key in the README quickstart example but the actual
code field is named rsa_private_key_pem. The README example shows:
  JWTConfig(secret_key="your-secret", access_token_ttl=900)
Neither of those field names exists on JWTConfig. The actual fields are rsa_private_key_pem and
access_token_ttl_seconds. This is a documentation bug that would cause a TypeError on first use.

The middleware __init__ is not lazy: it creates a Redis connection at middleware initialization
time, which means Redis must be reachable when the FastAPI application starts. If the application
starts before Redis is ready (common in Docker Compose setups), the connection attempt silently
succeeds because redis-py connects lazily on first command, but it would be worth documenting this.

The AuditLogger.init() method should be called at application startup, but LockWatchMiddleware does
not call it automatically when audit_database_url is provided. This requires the developer to
manually call await audit_logger.init() somewhere, which is not obvious from the add_middleware
call signature. Adding an on_startup hook or calling init lazily on the first log() would be more
ergonomic.


Feature Work for Resume Impact
-------------------------------

A JWKS endpoint (/.well-known/jwks.json) would make LockWatch self-documenting for token
verification and is the natural follow-on to the RS256 choice. This would let downstream services
fetch the public key dynamically without any out-of-band configuration.

Per-route rate limiting would significantly broaden the use case. The current design applies one
global policy to all routes. Supporting route-specific policies (e.g. 5 req/min on /auth/login,
100 req/min on everything else) via a decorator or configuration map would match how teams actually
need to deploy this.

A Redis Cluster / Redlock mode for distributed rate limiting across multiple application instances
is the most commonly asked follow-up question in interviews about Redis rate limiters. Even a
documented limitation with a pointer to the Redlock algorithm would strengthen the interview story.


Operational Gaps
----------------

There is no metrics emission. LockWatch logs warnings on failures and fires webhooks on anomalies,
but there is no Prometheus counter or statsd integration for tracking rate-limit hit rates,
anomaly counts, or audit write failures over time. For a library intended for production use this
is a significant omission.

The PLAN.md mentions integrating LockWatch into Chronobot and LivestoTell as example integrations
but neither integration appears to exist yet. These would be valuable for the resume narrative
and for validating that the library works in a real multi-service context.


Recommendation
--------------

Keep and expand. The core implementation is solid and the code quality is high. The biggest
immediate action is resolving the PyPI name conflict, then tagging a release. After that, fix the
README documentation bug on JWTConfig field names, which would cause a TypeError for any first-time
user who copies the quickstart example verbatim. The Flask feature gap (no anomaly detection) should
be documented as a known limitation before the first public release.
