If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/thebookisclosed/ViVe shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 1y ago

• 3 active contributors
• GPL-3.0 licensed
• ⚠ Stale — last commit 1y ago
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 93% of recent commits
• ⚠ GPL-3.0 is copyleft — check downstream compatibility
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live thebookisclosed/ViVe repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/thebookisclosed/ViVe.

What it runs against: a local clone of thebookisclosed/ViVe — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in thebookisclosed/ViVe | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 455 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of thebookisclosed/ViVe. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/thebookisclosed/ViVe.git
#   cd ViVe
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of thebookisclosed/ViVe and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "thebookisclosed/ViVe(\\.git)?\\b" \\
  && ok "origin remote is thebookisclosed/ViVe" \\
  || miss "origin remote is not thebookisclosed/ViVe (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-3.0" \\
  || miss "license drift — was GPL-3.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 455 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~425d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/thebookisclosed/ViVe"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

ViVe is a C# library and console tool that wraps Windows 10+ feature control APIs (available since build 2004) to enable A/B testing and feature experimentation through NTDLL exports. It abstracts the complexity of RtlQueryFeatureConfiguration and related NTDLL calls, handling struct marshaling and boot persistence, while ViVeTool provides a ready-to-use CLI for power users to manage feature flags without writing code. Dual-layer monorepo: ViVe/ contains the core library (FeatureManager.cs as main API, NativeMethods.Ntdll.cs wrapping raw NTDLL calls, NativeStructs.cs and NativeEnums.cs defining marshaling shapes), while ViVeTool/ wraps the library in a CLI app (Program.cs entry point, ArgumentBlock.cs for command parsing, FeatureNaming.cs for human-readable feature lookup via Extra/FeatureDictionary.pfs).

Windows system developers, power users, and tool authors who need to programmatically query or modify Windows feature experiments; developers building their own Windows customization tools who want to avoid direct NTDLL P/Invoke boilerplate.

The project appears actively maintained with a single dedicated maintainer (thebookisclosed) and reasonable GitHub presence (60+ files, complete documentation). However, test coverage is not visible in the file list, and CI/CD setup is minimal (only basic issue templates present). It is production-ready for its narrow, well-defined use case but lacks the test harness and automation typical of mature libraries.

Single-maintainer project with no visible test suite or continuous integration—changes risk silent regressions in P/Invoke bindings to NTDLL. Tight coupling to specific Windows versions (requires build 18963+) means forward/backward compatibility breaks silently if NTDLL signatures change. No visible dependency management beyond .NET Framework, which is low-risk but also limits external validation.

No recent commit history or open PRs are visible in the provided data, suggesting the project is stable but not actively evolving. The presence of UpdateCheck.cs in ViVeTool hints at auto-update capability, indicating the maintainer considers distribution a priority.

Clone the repo: git clone https://github.com/thebookisclosed/ViVe.git. Open ViVe.sln in Visual Studio or build with: msbuild ViVe.sln. No NuGet dependencies are listed in packages.config, so restore is minimal: nuget restore ViVe.sln (if needed).

Daily commands: Build: msbuild ViVe.sln /p:Configuration=Release. Run CLI: ViVeTool.exe /help or ViVeTool.exe /list-features (inferred from README screenshot and Program.cs structure). Run as library: instantiate FeatureManager in your C# project and reference ViVe.dll.

• ViVe/FeatureManager.cs: Core public API; all feature management (query, enable, disable, reset) flows through this class.
• ViVe/NativeMethods.Ntdll.cs: P/Invoke bindings to Windows NTDLL exports (RtlQueryFeatureConfiguration, RtlSetFeatureConfigurations, etc.); any API signature drift here breaks the library.
• ViVe/NativeStructs.cs: Marshaling definitions for RTL_FEATURE_* structs; incorrect layout here causes memory corruption or silent failures.
• ViVeTool/Program.cs: CLI entry point demonstrating how to call FeatureManager; shows intended usage patterns.
• Extra/FeatureDictionary.pfs: Binary feature name database used by FeatureNaming.cs to provide human-readable feature names; maintainability risk if format is undocumented.

Adding new feature queries: extend NativeMethods.Ntdll.cs with new P/Invoke signatures, update NativeStructs.cs with marshaling types if needed, then add convenience methods to FeatureManager.cs. Improving CLI: modify ViVeTool/Program.cs argument parsing and ViVeTool/ArgumentBlock.cs to add new commands. Adding feature definitions: update Extra/FeatureDictionary.pfs (binary format) or contribute parsing logic to FeatureNaming.cs. Tests: none visible; create ViVe.Tests/ project with xUnit or MSTest.

Windows version dependency: code requires Windows 10 build 18963+ and will silently fail or crash on older versions—no version check guards are visible in FeatureManager.cs. Struct marshaling fragility: NativeStructs.cs uses [StructLayout(LayoutKind.Sequential)] with no FieldOffset guards; even a single missing field or size error corrupts memory. Binary dictionary format: Extra/FeatureDictionary.pfs has no visible schema documentation—contributors cannot modify or regenerate it without reverse-engineering FeatureNaming.cs parsing logic. Elevation requirement: feature configuration likely requires administrator privileges; no explicit elevation check visible in ViVeTool.

• P/Invoke (Platform Invoke) — Core mechanism enabling C# code to call unmanaged NTDLL functions; understanding marshaling rules and calling conventions is essential to modify NativeMethods.Ntdll.cs safely.
• Struct marshaling and LayoutKind — NativeStructs.cs relies on precise struct layout ([StructLayout(LayoutKind.Sequential)]) to match NTDLL expectations; misalignment causes silent corruption—critical to understand field packing and alignment.
• Feature experiments and A/B testing (Windows RTL level) — The library targets Windows 10's feature control system (RtlQueryFeatureConfiguration API) used internally for experimentation; understanding why NTDLL exposes this API clarifies the design.
• Boot persistence and Last-Known-Good (LKG) registry hives — FeatureManager.cs implements LKG management and boot persistence mentioned in README—these involve reading/writing HKLM registry and understanding Windows boot phases; necessary for implementing reset/recovery features correctly.
• Command-line argument parsing and subcommand dispatch — ViVeTool's ArgumentBlock.cs implements CLI UX; understanding argument parsing patterns helps extend the tool with new commands or improve help text.

• microsoft/terminal — Large Windows native project also using P/Invoke and feature experiments; reference for production-quality NTDLL bindings and testing patterns.
• ntpsec/ntpsec — Example of managing Windows API compatibility across versions; relevant for handling version checks and graceful degradation.
• files-community/Files — Modern C# Windows app that likely uses feature flags and configuration APIs; reference for CLI argument parsing and user-facing feature control UX.
• microsoft/winget-cli — Windows package manager using modern C# tooling and P/Invoke; reference for CLI design and dependency management in Windows native projects.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for FeatureManager.cs core functionality

ViVe/FeatureManager.cs is the primary public API class but has no corresponding test file in the repository. Given this library wraps native Windows APIs with complex struct handling, unit tests would validate struct marshaling, error handling (FeaturePropertyOverflowException.cs), and the reimplemented boot persistence/LKG management logic before users encounter issues.

• [ ] Create ViVe.Tests project with MSTest or xUnit framework
• [ ] Add tests for FeatureManager initialization and native method calls
• [ ] Add tests for FeaturePropertyOverflowException scenarios
• [ ] Add tests for boot persistence and LKG management methods
• [ ] Update ViVe.sln to include new test project
• [ ] Document test running instructions in README.md

Add GitHub Actions workflow for multi-build validation (.NET Framework versions)

The repo contains both ViVe/ViVe.csproj and ViVeTool/ViVeTool.csproj but has no CI pipeline visible. There's no guarantee pull requests compile successfully across targeted .NET Framework versions before merging. A build workflow would catch regressions early and validate Windows 10 build 18963+ API compatibility requirements.

• [ ] Create .github/workflows/build.yml workflow file
• [ ] Configure matrix builds for .NET Framework 4.x versions used in AssemblyInfo.cs files
• [ ] Add steps to build ViVe.sln and run solution verification
• [ ] Add steps to validate NativeMethods.Ntdll.cs P/Invoke declarations compile
• [ ] Configure workflow to run on pull requests and main branch pushes
• [ ] Add build status badge to README.md

Document NativeMethods.Ntdll.cs P/Invoke signatures and add XML comments

ViVe/NativeMethods.Ntdll.cs contains raw NTDLL export bindings that are undocumented and critical for library function. New contributors and users cannot understand which Windows API each method wraps, what parameters mean, or compatibility requirements. XML documentation would enable IntelliSense and serve as internal reference for the feature control mechanism.

• [ ] Review ViVe/NativeMethods.Ntdll.cs and identify all P/Invoke declarations
• [ ] Add XML documentation comments (///) for each NTDLL method with Windows API names
• [ ] Document parameter purposes and RTL_FEATURE_USAGE_SUBSCRIPTION_TRIGGER enum values in NativeEnums.cs
• [ ] Document struct marshaling requirements in NativeStructs.cs
• [ ] Generate and verify documentation renders correctly in Visual Studio IntelliSense
• [ ] Add comment referencing Windows 10 build 18963+ API availability requirement

• Add unit tests for FeatureManager.cs methods (QueryFeature, SetFeatureConfiguration, ResetFeature, etc.) covering success and error cases—none visible in file list. Use MSTest or xUnit.
• Document the binary format of Extra/FeatureDictionary.pfs in a new CONTRIBUTING.md file so contributors can regenerate or validate the feature name database without guessing FeatureNaming.cs parsing logic.
• Add explicit Windows version detection and helpful error messages in FeatureManager constructor—currently no guard against pre-build-18963 systems, leading to cryptic NTDLL errors.

ViVe is a native Windows API wrapper library with moderate security posture. Primary risks stem from direct NTDLL P/Invoke calls requiring strict input validation, and potential issues in the ViVeTool CLI argument parsing. The codebase lacks visible security vulnerabilities in common categories (hardcoded secrets, injection flaws, misconfigurations), but the nature of system-level API interaction demands careful review of native method calls and parameter validation. No critical vulnerabilities identified, but medium-severity issues around input validation and privilege escalation potential should be addressed. Dependencies require audit but were not provided for analysis.

• Medium · Potential for Privilege Escalation via Native API Calls — ViVe/NativeMethods.Ntdll.cs, ViVe/FeatureManager.cs. The codebase interacts directly with NTDLL exports for Windows feature control management. Direct native API calls (P/Invoke) to NTDLL bypass managed code security boundaries and require careful handling. If input validation is insufficient in FeatureManager.cs or NativeMethods calls, this could lead to privilege escalation or system instability. Fix: Ensure all parameters passed to native NTDLL functions are thoroughly validated and sanitized. Implement strict input bounds checking, type validation, and consider using safe wrapper patterns. Add comprehensive error handling for native calls.
• Medium · Insufficient Input Validation in Argument Parsing — ViVeTool/ArgumentBlock.cs, ViVeTool/Program.cs. ViVeTool includes ArgumentBlock.cs for command-line argument parsing. Without visible validation logic, there's risk of malformed input causing unexpected behavior or crashes. Feature names, IDs, or configuration values passed via command-line arguments could be exploited if not properly validated. Fix: Implement comprehensive input validation for all command-line arguments. Validate feature IDs (numeric bounds), feature names (allowed character sets), and configuration values against expected formats. Use allowlists for accepted operations.
• Medium · Update Check Over Potentially Insecure Channel — ViVeTool/UpdateCheck.cs. UpdateCheck.cs performs version checking functionality. If this communicates with remote servers over HTTP (non-HTTPS) or doesn't verify server certificates, it could be vulnerable to MITM attacks allowing installation of malicious updates. Fix: Ensure all update checks use HTTPS with proper certificate validation. Verify downloaded binaries using cryptographic signatures (e.g., code signing certificates). Implement pinning for critical update endpoints.
• Low · Missing Dependency Manifest — ViVeTool/packages.config. The packages.config file is present but its content was not provided for analysis. NuGet package dependencies should be reviewed for known vulnerabilities and outdated versions. Fix: Audit all NuGet dependencies for known CVEs using tools like NuGetAuditor or Dependabot. Keep dependencies updated to latest secure versions. Document and justify any legacy dependency versions.
• Low · Potential Information Disclosure via Exception Handling — ViVe/FeaturePropertyOverflowException.cs. FeaturePropertyOverflowException and other custom exceptions may expose sensitive system information if not handled carefully. Stack traces or exception messages could reveal internal structure or system configuration details. Fix: Ensure exception messages are user-friendly and don't expose system internals. Log detailed exceptions server-side only. Implement custom exception handlers that sanitize error information in user-facing output.
• Low · Code Obfuscation Presence May Indicate Security Through Obscurity — ViVe/ObfuscationHelpers.cs. The existence of ObfuscationHelpers.cs suggests the codebase uses obfuscation. While this can protect IP, it may give false sense of security and complicate vulnerability auditing. Fix: Use obfuscation as defense-in-depth, not as primary security mechanism. Conduct thorough security reviews before relying on obfuscation. Document obfuscation approach for security audits.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.