Skip to content

publication-audit.md

Latest commit

 

History

History
182 lines (131 loc) · 9 KB

publication-audit.md

File metadata and controls

182 lines (131 loc) · 9 KB
Raw

Public-release privacy, sensitivity, and licensing audit

Audit date: August 15, 2026
Release candidate: VCRS 0.1.0 public preview
Scope: the original repository-standard kit supplied for publication and the final VCRS package

Decision

Recommended for public release as a new repository with no imported private Git history.

The review found no direct disclosure of:

  • a personal name, private username, personal email address, or user-specific home-directory path;
  • a private company, client, employer, domain, repository, or product name;
  • credentials, private keys, access tokens, connection strings, or embedded URL passwords;
  • private infrastructure identifiers or public IPv4 addresses;
  • client records, operational logs, screenshots of private systems, or production data.

The original package also contained no .git directory, so it did not carry private commit authorship, branches, remotes, deleted files, or historical secrets into this publication package.

Public references to OpenAI Codex, GitHub, Ponytail, Codebase Memory MCP, Model Context Protocol, and other engineering resources are intentional research, compatibility, or acknowledgment references. They are not private-project disclosures.

Origin-specific context found and removed

The first internal draft contained a domain-specific pilot label and several operational examples tied to one managed-service workflow. They did not expose a person, company, client, credential, host, or repository, but they could reveal the package's project of origin or distract public adopters. The publication edition replaces them with neutral examples while preserving the reusable engineering guidance.

What was examined

Identity and organization exposure

The review searched text, filenames, paths, configuration, prompts, tests, and archive contents for:

  • names, handles, domains, and repository identifiers connected to the originating work;
  • client, company, product, and internal-project terminology;
  • email addresses;
  • macOS, Linux, and Windows user-home paths;
  • internal hostnames and address-like values;
  • production schedules, environment names, and deployment identifiers tied to one private implementation.

No direct identifying reference was found. The public edition uses synthetic examples and neutral roles such as project-maintainers.

Secrets and credentials

The automated and manual review covered:

  • private-key markers;
  • common GitHub, OpenAI, AWS, Google, and Slack token formats;
  • credentials embedded in URLs;
  • password, secret, token, and connection-string assignments;
  • .env, certificate, key-store, database, log, and archive artifacts;
  • image metadata that could contain creator, software, location, or path information.

The included tests construct fake sensitive strings from fragments at runtime. They contain no usable credential and are designed to prove that the scanner detects unsafe patterns.

Files and metadata

The package was reviewed for:

  • editor files, caches, bytecode, logs, local databases, and temporary output;
  • nested archives and accidentally bundled release packages;
  • PNG textual or EXIF metadata;
  • broken relative links and stale paths;
  • inconsistent project names, versions, and standard identifiers;
  • unresolved public placeholders;
  • invalid JSON, TOML, SVG, or Python files;
  • duplicate issue forms and unsafe GitHub workflow permissions.

The GitHub social-preview image is 1280 × 640 pixels, below 1 MB, and contains no detected textual or EXIF metadata chunks.

Licensing and attribution

The package consists of original VCRS documentation, prompts, templates, tests, visual assets, and validation scripts. No third-party source code is intentionally vendored.

The public release includes:

  • Apache License 2.0;
  • NOTICE;
  • THIRD_PARTY_NOTICES.md;
  • ACKNOWLEDGEMENTS.md;
  • contribution licensing language;
  • an independent-project and trademark disclaimer;
  • a dated source register.

This is a publication-readiness review, not legal advice or a trademark clearance.

Public-release changes

The publication edition adds or updates:

  • the neutral project identity Vibe Coding Repository Standard (VCRS);
  • an approachable visual README and white paper;
  • getting-started, FAQ, glossary, privacy-audit, and discovery guidance;
  • license, security, support, conduct, governance, citation, roadmap, and contribution files;
  • GitHub issue forms, pull-request evidence, Dependabot configuration, and a read-only quality workflow;
  • a dependency-free public-repository validator;
  • a configurable publication scanner with a private deny-term input;
  • a deterministic release builder that places a SHA-256 file manifest inside the ZIP;
  • a 1280 × 640 social preview, SVG hero, and SVG project logo;
  • consistent 0.1.0 public-preview and VCRS-1 identifiers.

The existing technical handbook, profiles, prompts, machine-profile references, starter template, validator, and tests remain included under standard/.

Repeat the audit

Run the complete public-package checks from the repository root:

python -m unittest discover -s tests/quality -p 'test_*.py' -v
python scripts/quality/validate_public_repository.py --root . --strict
python scripts/quality/audit_publication.py --root . --strict
python -m unittest discover \
  -s standard/template/tests/standards \
  -p 'test_*.py' \
  -v
python standard/template/scripts/maintenance/validate_repository_standard.py \
  --root standard/template

For the final release candidate, create a private newline-delimited file outside the repository containing names, domains, usernames, and project identifiers that must never appear. Then run:

python scripts/quality/audit_publication.py \
  --root . \
  --strict \
  --deny-term-file ../private-publication-deny-terms.txt

Do not commit the deny-term file. Its contents may themselves be sensitive.

Build the deterministic release archive only after the checks pass:

python scripts/release/build_release.py \
  --root . \
  --output-dir ../release

Release validation record

The 0.1.0 release candidate was validated on August 15, 2026 (August 16 UTC) with the following results:

  • public repository validator: 0 errors, 0 warnings;
  • publication audit with an external origin-specific deny-term file: 0 errors, 0 warnings;
  • public quality suite: 16 tests passed;
  • starter-template validator suite: 7 tests passed;
  • independent parsing: 10 Python, 2 JSON, 6 TOML, 12 YAML/CFF, 3 SVG, and 64 Markdown files passed;
  • Markdown fence and relative-link validation: passed;
  • normalized non-URL comparison against the reviewed Ponytail and Codebase Memory MCP source files: 0 exact eight-word matches;
  • deterministic archive and embedded-manifest tests: passed;
  • clean-room validation after extracting the release ZIP: passed;
  • archive hygiene: one top-level directory, one embedded file manifest, and no Git metadata, bytecode, caches, logs, or nested archives.

The adaptable starter template reports two intentional non-blocking warnings when validated directly: its repository name and governance owner are placeholders that every adopter must replace. These are adoption reminders, not public-package defects.

Important scope boundaries

No static package scan can prove that:

  • every possible secret format has been detected;
  • a secret never existed in a separate or future Git history;
  • Issues, Discussions, Actions logs, release attachments, forks, or repository settings remain clean;
  • every third-party statement is legally risk-free in every jurisdiction;
  • the project name is available as a trademark, domain, package, or repository name everywhere;
  • a future contribution will preserve the current privacy state;
  • the software standard makes an adopting application secure or production-ready.

Before publishing a repository that already has history, scan all commits, branches, tags, stashes, releases, Actions artifacts, and remote references with a dedicated secret-scanning tool. For this release, start a new public history from the sanitized package rather than pushing the private development history.

Maintainer checklist before changing visibility

  1. Run the checks above on the exact commit to be published.
  2. Review git status, the staged diff, public Git author identity, and configured remotes.
  3. Confirm that the release starts from the sanitized package with no private history.
  4. Recheck the desired repository name immediately before creation.
  5. Enable private vulnerability reporting and secret scanning where available.
  6. Keep default GitHub Actions permissions read-only and protect the default branch.
  7. Upload assets/social-preview.png through GitHub repository settings.
  8. Review every public issue, Discussion, screenshot, log, and release attachment before sharing it.

Release status

The appropriate label is 0.1.0 public preview. The package is publication-ready, but broad validation across languages, repository profiles, agent products, and real adoption cases is still required before VCRS should be described as stable.