Skip to content

feat: complete LP5 operations and capacity proof - #8

Merged
Sythos merged 4 commits into
mainfrom
milestone/lp5
Aug 25, 2026
Merged

feat: complete LP5 operations and capacity proof#8
Sythos merged 4 commits into
mainfrom
milestone/lp5

Conversation

@Sythos

@Sythos Sythos commented Aug 25, 2026

Copy link
Copy Markdown
Owner

Completes the LP5 local security, abuse, observability, patch-state, and bounded-capacity proof. Records AMD64-first and final ARM64 artifact evidence, updates canonical memory/deployment/milestone documents, README status, and the LP5 release manifest. Local npm test and LP5 gates passed; AMD64 run 32870823846 and final ARM64 artifact/attestation run 32866904673 are green. Production capacity and external interoperability remain out of scope.

@Sythos
Sythos merged commit 6c08d02 into main Aug 25, 2026
1 check passed
@Sythos
Sythos deleted the milestone/lp5 branch August 25, 2026 16:25

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 83031bed05

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread src/runtime/server.ts
const abuseDecision = runtime.rateLimiter.consume({
channel: abuseChannel,
tenantId: session?.tenantId ?? 'anonymous',
ipAddress: request.socket.remoteAddress ?? 'unknown',

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Resolve client IP before applying the shared limiter

When the runtime is deployed behind the documented edge/reverse proxy, request.socket.remoteAddress is the proxy address rather than the originating client. Consequently, every client shares the same IP bucket—only 120 HTTP/API requests per minute by default—so normal aggregate traffic can cause installation-wide 429 responses. Use a client identity supplied through explicitly trusted proxy configuration, or enforce the client-IP limit at the edge instead.

Useful? React with 👍 / 👎.

Comment thread src/runtime/server.ts
Comment on lines +537 to +542
const abuseChannel = abuseChannelForPath(path);
const abuseDecision = runtime.rateLimiter.consume({
channel: abuseChannel,
tenantId: session?.tenantId ?? 'anonymous',
ipAddress: request.socket.remoteAddress ?? 'unknown',
});

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Exempt operational probes from user traffic limits

Because the limiter runs before route dispatch, /health/live, /health/ready, and /metrics return 429 after their source IP consumes 120 HTTP requests in the minute (or after the shared anonymous tenant bucket is exhausted). In environments where probes or scrapes share an address with application traffic, a healthy process can therefore be marked unhealthy and its metrics become unavailable; operational endpoints should bypass user-facing limits or use independent probe limits.

Useful? React with 👍 / 👎.

Comment on lines +30 to +31
const response = await fetch(`${baseUrl}${path}`, { redirect: 'manual' });
if (response.status >= 500) throw new Error(`${path} returned ${response.status}`);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Reject unexpected statuses in capacity probes

The LP5 capacity gate treats every response below 500 as a successful timing sample, so a missing web route returning 404, an unauthorized endpoint returning 401, or a rate-limited probe returning 429 contributes zero HTTP errors and can still produce a passing report. Validate the expected status for each probe—200 for / and the configured DAV redirect status—so functional failures cannot be recorded as successful capacity evidence.

Useful? React with 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant