hns-lsel-applier

Applies approved self-evolution proposals as validated git commits with allowlist gating and auto-revert verification.

1.2k|222|Updated Sep 16, 2025
One-click install
npx skills add https://github.com/modu-ai/moai-adk --skill hns-lsel-applier
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: hns-lsel-applier
Source: https://github.com/modu-ai/moai-adk/tree/main/.claude/skills/hns-lsel-applier
Command: npx skills add https://github.com/modu-ai/moai-adk --skill hns-lsel-applier

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

The Local Self-Evolution Loop's PROPOSE-to-APPLY seam was dead in production: the frozen Go applier never ran and its write-flag stays disabled. This Skill closes that gap by safely playing back already-approved decision.json records into the repository, writing only to designated evolvable surfaces while hard-rejecting any change targeting frozen doctrine files.

Core Features & Use Cases

  • Frozen-allowlist enforcement: Validates every proposal target against a frozen allowlist, refusing writes to protected paths (including path-traversal and divergent-patch bypass attempts) and logging each refusal.
  • Execution-meta forced gate: Mechanically refuses changes to applier/curator skill bodies, hooks, or hook-registration settings unless the decision carries a synchronous-approval marker from the orchestrator's user gate.
  • Playback with audit trail: Applies the approved diff.patch via git apply, appends an apply-ledger.jsonl row, and commits one lsel-<proposal-id>-tagged Conventional Commit on the feature branch.
  • Post-apply verification: Runs the proposal's verify_command with a timeout-retry-once policy, auto-reverts on a second failure, and requires a mandatory lint/format/type/test gate as an independent check.
  • Use Case: After the curator approves a proposal to update a memory feedback file, invoke this Skill to validate the target, apply the patch, commit it with an lsel tag, and verify the change — automatically reverting if verification fails twice.

Quick Start

Ask the agent to drive an LSEL APPLY pass for the approved proposal in .moai/state/lsel/proposals, validating it against the frozen allowlist and committing it through lsel-apply.sh.

Frequently Asked Questions about hns-lsel-applier

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I apply an approved LSEL proposal to my repository?

Run lsel-apply.sh with the path to an approved decision.json file. The hook validates the target against the frozen allowlist, applies the diff.patch via git apply, appends an apply-ledger.jsonl row, and commits the change as an lsel-<proposal-id>-tagged Conventional Commit.

How does the frozen allowlist protect files from self-evolution changes?

The allowlist at .claude/lsel/frozen-allowlist.json contains regex patterns for protected paths. Any decision.json whose target or patch paths match is refused with a reject-log entry and non-zero exit, including path-traversal attempts and patches that diverge from the declared target.

What happens when a proposal targets an execution-meta file?

Changes to applier or curator skill bodies, apply hooks, the allowlist itself, or hook-registration settings require a synchronous_approval marker with decision approved in the decision.json. Without that marker the hook refuses the change and logs an execution-meta rejection.

Does the verify stage automatically revert failed applies?

Yes. verify.sh runs the proposal's verify_command with a timeout-retry-once policy. If the second attempt also fails, it auto-fires git revert on the lsel-tagged commit, marks the ledger row verified:false, and flags the proposal's feedback file.

Why is the /moai gate required after a successful verify_command?

A proposer-authored verify_command is circular because the proposer can write a check its own change satisfies. The mandatory gate runs lint, format, type-check, and the full test suite as an independent check, and a gate failure means the apply is treated as unverified.

Can this Skill unfreeze the original Go applier or edit frozen doctrine?

No. The write-flag at internal/harness/applier.go:22 stays false by design, and the bypass is a parallel user-owned applier. Frozen templates, rules, CLAUDE.md, and retained agents are byte-for-byte untouched and hard-rejected by the allowlist.