DEV Community: Christian Serrano

Caivra Repo Gallery v0.1.1: A Free Open-Source GitHub Repository Explorer

Christian Serrano — Fri, 06 Nov 2026 10:53:41 +0000

Caivra Repo Gallery v0.1.1: a lightweight, open-source GitHub repository explorer

I built Caivra Repo Gallery at Caivra Tech LLC to make it easier to explore public GitHub repositories without signing up for another service.

It's a free, MIT-licensed static web application. You can use it directly in the browser, and the public source is available for review.

Live app: https://caivra-tech.github.io/caivra-repo-gallery/
Source and release: https://github.com/caivra-tech/caivra-repo-gallery/releases/tag/v0.1.1
Open-source projects showcase: https://caivra-tech.github.io/caivra-repo-gallery/open-source/

What the Gallery does

Enter a GitHub organization or username to load public repositories. You can search by name, description, language, or topic; filter by programming language; include or exclude forks; sort the loaded results; and load additional repository pages.

The URL retains your chosen owner and filters so you can share a specific view with someone else.

It has no visitor login, database, API key entry, or paid subscription. The browser fetches public repository information from GitHub's API.

What changed with v0.1.1

The most important functional correction concerns paginated language filters. A shared URL can select a language before any matching repositories have been loaded. The Gallery now preserves that selection as subsequent API pages arrive, instead of losing the selected filter.

The release also includes regression tests for that behavior, GitHub Actions pinned to immutable revisions, release-assurance documentation, branch protection, and private vulnerability reporting.

Before the formal release, validation included 27 passing Node tests and eight browser scenarios across real production pages and controlled API fixtures. The browser checks covered desktop and mobile-emulated layouts, account lookup, multi-page filtering, sorting, fork controls, invalid input, rate-limit recovery, and the showcase page.

Boundaries worth knowing

The Gallery uses GitHub's unauthenticated public API, so normal anonymous rate limits apply. Search, filtering, and sorting affect repositories already loaded into the page, not all GitHub repositories. Mobile checks were done with Chromium emulation rather than physical devices.

This is a small developer utility, not an AI search engine, GitHub analytics platform, or replacement for GitHub itself.

The v0.1.1 tag identifies the first formal GitHub Release. Its private, unpublished package test manifest still reports 0.1.0; the release notes document that distinction.

Feedback welcome

If you maintain GitHub projects, I'd be interested to hear which exploration and discovery workflows would be most useful next. Issues and technical contributions are welcome in the repository.

Try the Gallery: https://caivra-tech.github.io/caivra-repo-gallery/

Review the MIT-licensed code: https://github.com/caivra-tech/caivra-repo-gallery

Disclosure: This announcement was prepared with AI writing assistance and checked against the public release notes and validation results.

GitHub Reminders Without a Database: Where the Reliability Guarantees Stop

Christian Serrano — Tue, 03 Nov 2026 00:23:17 +0000

Many developer tools start with a simple need and grow into an unnecessary service: another database, another scheduler, another account, and a recurring bill.

At Caivra Tech LLC we built GitHub Reminders, a free, MIT-licensed GitHub Action for reminders in issue and pull-request discussions. It uses GitHub comments for persistence and GitHub Actions for scheduled delivery rather than introducing a hosted backend.

This article explains the implementation trade-off—and why we explicitly do not promise exactly-once reminders.

Project and installation instructions: https://github.com/caivra-tech/GitHub-reminders

How it works

A collaborator leaves a command in an issue or PR:

/remind in 7 days Revisit this before deleting the branch
/remind in 3 hours Check CI again
/reminders

The configured issue_comment workflow processes the command. A successful creation produces a bot confirmation with a versioned hidden marker containing reminder metadata. Later, a scheduled workflow scans due reminders and attempts delivery by commenting back on the original conversation.

issue/PR comment
  → command parser
  → bot confirmation + versioned marker
  → periodic Actions scan
  → due reminder check
  → GitHub mention to creator

No external database or separate user service is required. Metadata remains in repository comments, so do not place sensitive information or secrets inside reminder text.

The workflow requests these GitHub token permissions:

permissions:
  contents: read
  issues: write
  pull-requests: write

For installation, use the actual versioned example workflow and installation guide. The published maintenance release is v1.0.1; users needing stronger supply-chain pinning can review and pin its release commit 2b98349b0dadd9014e997bcf54197de7755e4001.

The interesting part: persistent state is not a durable queue

This design makes adoption lightweight, but it does not magically make GitHub Actions a real-time scheduler or durable messaging platform.

The provided example coordinates triggers through a named concurrency group with queue: max and cancel-in-progress: false. This serializes runs of that workflow. It has a bounded pending queue of up to 100 runs. If that capacity is reached, incoming runs can be cancelled with no bot acknowledgment.

A scheduled job can also run late or be skipped. That means the delivery contract is best-effort and duplicate-resistant, not guaranteed at-least-once or exactly-once.

An important operational rule follows:

A command left in a comment is not proof the command was processed. Check for the bot's acknowledgment and inspect Actions history if one is absent. Reposting before reconciling may cause duplicate reminders.

A two-write failure worth studying

Delivery crosses two separate GitHub API operations:

Post the reminder comment.
Update the original reminder's marker to record delivery.

Those writes are not atomic.

Suppose step 1 succeeds and step 2 fails. If a later scan runs, a trusted delivery marker can help detect the previously posted reminder and repair the source marker without intentionally posting another delivery.

But what if the API call for step 1 times out after the comment may have been committed? A client cannot infer whether it happened from the timeout alone. That is an unknown outcome. GitHub's comments API supplies no transaction that spans delivery and source-state update.

This is why good error handling isn't just a try/catch block. It requires acknowledging that an effect may have happened even if confirmation was lost.

Security and scope boundaries

The project limits command-based cancellation to the reminder's creator, stores versioned metadata, and neutralizes @ symbols in delivered reminder text to avoid surprising third-party pings.

These protections do not mean every privileged workflow sharing a GitHub Actions identity can be independently distinguished. A second differently named reminder workflow is not a supported coordination pattern; two independent scans may evade the intended serialization. The architecture and limitations are documented in the repository.

The action is appropriate for convenient, approximate reminders in a developer workflow. It is not appropriate for safety-critical alerts, contractual deadline guarantees, or workflows that require durable exactly-once command processing.

How to inspect or contribute

The public code is licensed under MIT. We welcome focused review of idempotency, trust boundaries, event queues, and timeout recovery. The goal is to make the trade-offs transparent, not to describe a best-effort GitHub reminder as a guaranteed messaging system.

Disclosure: This technical explainer was prepared with AI writing assistance and reviewed against the project's public README, installation guide, and architecture documentation. It describes documented design and limitations; it is not an independently executed benchmark or a fresh live scheduled-delivery certification.

An AI Agent Was Authorized. Then the Permission Changed. What Happens Next?

Christian Serrano — Sat, 31 Oct 2026 04:35:39 +0000

An AI agent can be authorized at planning time—and still be unsafe at execution time

Imagine an autonomous agent receives permission to perform an action. It collects evidence, plans its steps, and prepares an external write.

Before that write occurs, something changes: a permission is revoked, the target resource changes, or the evidence used to admit the action is no longer applicable.

Should the original approval still be enough?

My technical preprint, Authority-Bound Execution for Agentic Systems: A Formal Architecture for Provenance-Validated Admission, Revocation Fencing, and Recoverable Effects (CC-RP-001, v0.5), investigates this problem as one of authority, provenance, time, and recoverability.

Read the paper: Zenodo DOI: 10.5281/zenodo.23823408

Author: Christian Serrano, Caivra Tech LLC

Preprint version: v0.5, October 30, 2026

Status: Public theoretical research preprint, not independently peer reviewed.

Why a valid approval can become insufficient

An action can appear authorized when planned yet be inadmissible when executed.

For example:

A security review approves a change for one repository revision, but the underlying code changes afterward.
A capability is granted with a limited scope, but the proposed effect targets a resource outside that scope.
A delegated permission is revoked while a job is waiting in a queue.
A network operation times out after the remote system may already have committed the effect.

Each example requires more than asking whether an AI's initial request was plausible. It requires checking which authority applies to which exact action, based on which evidence, at what point in the workflow, and how outcomes are recovered.

The paper proposes an architectural vocabulary for reasoning about these boundaries.

1. Provenance-validated admission

A provenance record is not automatically evidence that a proposed operation is admissible.

Suppose a test result was produced for revision A. An agent now wants to mutate revision B. The fact that a test passed is real historical evidence—but whether it applies to the new target is a separate question.

The proposed approach treats admission as dependent on evidence that is:

Authentic: Who or what produced it?
Applicable: Does it refer to this operation, resource, revision, and context?
Fresh enough: Has a relevant dependency changed since it was produced?
Within scope: Does the evidence support this requested decision, rather than a broader claim?

A model-generated explanation cannot resolve these questions by assertion alone. Admission must be tied to the relevant authoritative mechanisms.

2. Revocation fencing near consequential effects

A common timing problem appears when authorization is checked upstream, but execution happens later.

Conceptually:

Agent proposes action
        |
Resolve applicable authority
        |
Validate evidence and admission conditions
        |
Prepare candidate operation
        |
Check revocation/freshness at the effect boundary
        |
Commit permitted effect OR refuse/hold

The important idea is that an earlier permission check should not automatically survive a material authority change.

A design intended to enforce this property needs a reliable relationship between the authoritative revocation state and the consequential effect boundary. Otherwise, a race between a revocation and an operation can leave the system acting on stale authority.

The manuscript explores a proposed fencing approach and related conditional safety properties. The challenge is to show, under explicit assumptions, that a relevant revocation cannot be bypassed by queued work, alternate execution routes, or stale authorizations.

3. Recoverable effects and unknown outcomes

Now consider a different failure.

An agent asks a remote service to create a resource. The request times out. The agent cannot tell whether the remote operation committed.

Blindly repeating the request may create duplicates. Assuming it failed may be wrong. Assuming it succeeded may also be wrong.

Recoverable execution needs to distinguish:

An effect that is known not to have happened.
An effect that is known to have happened.
An effect whose outcome remains unknown.

That third state matters. The research discusses durable reconciliation of uncertain outcomes rather than treating every timeout as a safe opportunity to retry.

Depending on the external service, a practical strategy may involve stable operation identifiers, idempotency support, state queries, or controlled recovery workflows. No single mechanism works universally across all APIs.

4. Authority is not the same as trust, evidence, or execution

The paper emphasizes boundaries that are often collapsed in agent discussions:

Intent: What a caller or agent wants.
Authority: Who can permit the consequential action.
Admission: Whether the specific candidate satisfies applicable conditions.
Capability: What bounded operation has actually been granted.
Execution: What effect was attempted.
Evidence: What can be substantiated about that attempt.
Reconciliation: How uncertain or partial outcomes are resolved.

Keeping these concepts distinct helps reveal where systems otherwise confuse a caller's claim with a governing decision or a successful tool call with an approved final state.

A research agenda—not a declaration of proof

The preprint proposes an architecture, conditional safety propositions, and a falsifiable evaluation plan.

It does not report completed machine-checked proofs, controlled comparative benchmarks, independent peer review, or production validation. The proposed properties still need rigorous implementations, explicit threat models, failure-injection tests, and comparative evaluation.

Useful negative tests include:

Revocation committed immediately before effect-time checks.
Revocation racing with execution.
Replayed or duplicated requests.
Evidence that is genuine but stale or inapplicable.
Alternate entry points that bypass expected checks.
Remote timeouts after a possibly committed effect.
Process restart during unresolved reconciliation.

A design should be assessed by the failures it can rule out under specified assumptions—not just by successful demonstration paths.

Why publish this work?

Agent tooling is rapidly increasing the number of systems capable of making consequential external changes. The difficult engineering problem is not simply generating better decisions; it is preserving valid decision authority across the full path from proposal to effect and recovery.

This preprint contributes a proposed framework and an explicit set of questions that can be examined, challenged, and experimentally tested.

Read and cite

Paper: Authority-Bound Execution for Agentic Systems: A Formal Architecture for Provenance-Validated Admission, Revocation Fencing, and Recoverable Effects

Identifier: CC-RP-001

Version: v0.5

Published: October 30, 2026

Citation: Serrano, C. (2026). Authority-Bound Execution for Agentic Systems: A Formal Architecture for Provenance-Validated Admission, Revocation Fencing, and Recoverable Effects (Version 0.5). Zenodo. https://doi.org/10.5281/zenodo.23823408

Research integrity note: This is an independent explanatory article about a theoretical preprint, not an announcement of completed verification or deployment. The Zenodo version DOI identifies the authoritative archival manuscript. The related CEOS repository is contextual material, not the source repository for this distinct CaivraCore preprint.

Who Authorizes the AI Agent? A Systems Architecture for Governed Autonomous Software Engineering

Christian Serrano — Sat, 31 Oct 2026 04:35:13 +0000

When an AI agent can act, who decides what it is allowed to change?

An AI model can propose a patch, choose a tool, or recommend a deployment. That does not mean it should possess the final authority to change a repository, infrastructure environment, or canonical system state.

This is the central engineering question explored in my technical research preprint, CEOS Infrastructure as a Governed Transactional Assurance Substrate for Autonomous Software Engineering (CEOS-RP-001, v1.0).

Read the versioned research preprint: Zenodo DOI: 10.5281/zenodo.22991325

Author: Christian Serrano, Caivra Tech LLC

Publication date: September 26, 2026

Status: Technical research preprint; not independently peer reviewed.

The problem is bigger than a model's reasoning quality

Consider an agent that discovers an issue, generates a fix, runs tests, and proposes applying the change.

A useful result may still be unauthorized. Tests can pass against the wrong revision. Permissions can expire between planning and dispatch. An external API can time out after performing the requested effect. A merged commit can be mistaken for evidence that a system was deployed.

The agent's confidence is not an authority decision. A passing check is not a capability grant. A request to mutate state is not proof that the requested transition is admissible.

These are systems-engineering distinctions, not merely prompt-design considerations.

The architectural proposal: separate reasoning from authority

CEOS studies an architecture in which probabilistic intelligence participates in engineering while deterministic mechanisms govern consequential effects.

At a conceptual level:

Propose: An agent produces a candidate action and supporting rationale.
Resolve authority: A designated authority owner determines whether the proposed action is within the applicable scope.
Bind scope and state: Capabilities, exact target state, freshness constraints, and preconditions are made explicit.
Admit and execute: Only a permitted transition reaches the controlled effect boundary.
Validate and record: Results are checked against the intended transition and retained with provenance.
Reconcile uncertainty: If a timeout or partial failure leaves the external outcome unknown, the system does not simply assume success or retry without considering duplicate effects.

This is a research model, not a claim that every aspect of the full design is already enforced in a production system.

Several distinctions matter

1. Intent is not authorization

A user request, agent plan, or tool invocation can describe a desired outcome without supplying the authority to perform it. Authority should be resolved by the relevant governing mechanism, rather than inferred from the language of the request.

2. Evidence is not authority

A successful build, a green CI pipeline, and a clean code review are important evidence. They do not independently authorize merge, release, migration, or deployment. These remain separate decisions.

3. A candidate is not canonical state

A model-generated proposal should remain a candidate until the governing process admits it. Historical execution evidence must remain distinguishable from current live truth.

4. Time is part of correctness

Approval may have been valid when a plan was formed but no longer applicable when a consequential action is dispatched. A system that relies on stale permission or state assumptions can violate its own intended controls.

5. Unknown outcomes need reconciliation

Suppose an API call times out. Did the operation fail, or did the operation succeed while the acknowledgment was lost? Blind retries can duplicate effects. A transactional design needs an explicit strategy to classify and reconcile such ambiguity.

The testable research question

The research asks whether integrated enforcement of exact mutation, exact state, current authority, bounded capability, dispatch freshness, evidence, validation, and canonical disposition can improve assurance—or reduce the burden of integrating assurance mechanisms—relative to a correctly configured composite of existing technologies.

That is a falsifiable hypothesis, not an empirically demonstrated competitive advantage.

The paper outlines a formal systems architecture, security model, candidate invariants, and an adversarial evaluation program. Further work is needed to test the design and compare it with established approaches.

For engineers building autonomous workflows

A practical design review can start with questions like:

Which component owns the final decision to permit an effect?
Can a caller bypass that component through a different entry point?
What happens if permissions change after planning?
How does the system know it is acting on the exact intended revision?
What happens after a timeout where the external outcome is unknown?
Can logs distinguish a proposed change, an admitted change, and an observed effect?

These questions apply to coding agents, infrastructure automation, CI/CD orchestration, and other systems where model output has real consequences.

Read, cite, and review the research

Paper: CEOS Infrastructure as a Governed Transactional Assurance Substrate for Autonomous Software Engineering

Subtitle: Formal Systems Architecture, Security Model, and Falsifiable Research Program

Version: 1.0

Citation: Serrano, C. (2026). CEOS Infrastructure as a Governed Transactional Assurance Substrate for Autonomous Software Engineering (Version 1.0). Zenodo. https://doi.org/10.5281/zenodo.22991325

Research integrity note: This article is an accessible summary of a technical preprint, not a report of independent peer review, completed comparative benchmarks, or established production deployment. The linked versioned preprint is the authoritative research artifact.