v0.4.0 Execution Log¶

Living document. Append progress at the end of each work session. For context, see ROADMAP.md and AI_INTEGRATION_STRATEGY.md.

Status Board¶

ID	Task	Status	Start	Done	Commit / PR
DOC-1	Write strategy docs (ROADMAP, AI_STRATEGY, LOG)	🟢 done	2026-04-22	2026-04-22	—
P0-1	`pyobfus --check` pre-flight mode	🟢 done	2026-04-22	2026-04-22	pending
P0-2	`pyobfus unmap` reverse mapping	🟢 done	2026-04-22	2026-04-22	pending
P0-3	Framework presets	🟢 done	2026-04-22	2026-04-22	pending
P0-4	AI-friendly CLI (`--json`, ai-hint)	🟢 done	2026-04-22	2026-04-22	pending
P0-5	`pyobfus init`	🟢 done	2026-04-22	2026-04-22	pending
BRAND-1	PyPI alias packages	🟡 partial	2026-04-22	—	availability checked
BRAND-2	GitHub topics + Dev Status → Beta	🟢 done	2026-04-22	2026-04-22	applied + pyproject
BRAND-3	README pronunciation line + keyword density	🟢 done	2026-04-22	2026-04-22	pending
P1-1	`pyobfus-mcp` server package	🟢 done	2026-04-22	2026-04-22	pending
P1-2	`llms.txt` + `llms-full.txt`	🟢 done	2026-04-22	2026-04-22	pending
P1-3	AI integration templates	🟢 done	2026-04-22	2026-04-22	pending
P1-4	PyPI metadata overhaul	🟢 done	2026-04-22	2026-04-22	bundled with BRAND
P1-5	Incremental obfuscation	🟢 done	2026-04-22	2026-04-22	pending

Legend: ⚪ pending · 🟡 in_progress · 🟢 done · 🔴 blocked

Session Log¶

2026-04-22 — Session 1: Strategic planning & docs¶

Context: Post competitive analysis. Decision to reshape v0.4.0 around adoption friction + AI-native positioning instead of the previously planned "Enhanced Key Obfuscation" feature.

Actions: - ✅ Reviewed PyPI download data (324/month, ~30% real users) - ✅ Reviewed GitHub state (0 stars, 1 external issue = spam) - ✅ Competitive review: PyArmor, CodeEnigma, Anubis, Nuitka, Cython, Oxyry, pyminifier - ✅ Surveyed AI tool discovery mechanisms (MCP, llms.txt, CLAUDE.md, .cursorrules) - ✅ Reshaped ROADMAP.md — P0/P1/P2 with effort estimates - ✅ Created AI_INTEGRATION_STRATEGY.md — naming density attack + MCP plan - ✅ Created this execution log

Decisions: - Naming: do NOT rename. Instead: alias packages + keyword density + always co-brand "pyobfus — the Python obfuscator" - Sequencing: P0 features first (Weeks 1-3), then P1 AI ecosystem (Weeks 4-6), only then marketing - Previously planned "Enhanced Key Obfuscation" moved from P1 to P3 (no user-demand signal, low AI recommend probability)

Next: Start P0-1 pyobfus --check pre-flight mode.

2026-04-22 — Session 2: P0-1 `pyobfus --check` shipped¶

Delivered: - ✅ New module pyobfus/core/preflight.py (253 stmts, 93% coverage) with PreflightChecker, Risk, PreflightReport, format_report_text - ✅ CLI integration: --check flag + --json flag in pyobfus/cli.py via new _handle_check handler - ✅ Risk categories implemented: dynamic_exec (eval/exec/compile), dynamic_attr (getattr/setattr/hasattr/delattr with literal-vs-dynamic distinction), dynamic_import (__import__, importlib.import_module), runtime_introspection (vars/locals/globals/dir/inspect), name_string_reference (__name__/__qualname__/__class__), all_export, entry_point, framework_reflection - ✅ Framework detection: FastAPI, Django, Flask, Pydantic, Click, SQLAlchemy — with priority-based preset suggestion and per-framework canonical exclude glob - ✅ AI-consumable output: ai_hint field contains the exact next command for AI/user; text formatter renders it as Next: line - ✅ Exit codes: 0 safe, 1 high-severity, 2 parse errors — scriptable and CI-friendly - ✅ Tests: 20 new in tests/test_preflight.py, all passing

Verification: - Full suite: 581 passed (was 561), total coverage stays at 90% - End-to-end smoke test on synthetic FastAPI+Pydantic project with eval() and dynamic getattr(): - Text mode: correctly renders findings + suggests --preset fastapi --dry-run - JSON mode: valid, parseable, includes severity_counts, category_counts, frameworks, suggested_preset, suggested_excludes, ai_hint, exit_code

Notes for next sessions: - The --json flag only applies to --check today. When P0-4 lands, extend it to obfuscation runs and unmap. - Framework detection is import-based (reliable + fast). Add evidence from decorators / base classes in a later pass if false-positive rate is too high. - suggested_preset refers to framework keys (fastapi/django/…) that do not yet exist as ObfuscationConfig presets — P0-3 will add them.

Next: P0-2 pyobfus unmap reverse mapping command.

2026-04-22 — Session 3: P0-2 `pyobfus unmap` shipped¶

Delivered: - ✅ New module pyobfus/core/mapping.py (101 stmts, 98% coverage) with ObfuscationMapping dataclass, forward + reverse name maps, save/load, identifier-boundary-aware unmap_text, dotted-path reverse_qualified, and duck-typed from_global_table for the cross-file orchestrator - ✅ JSON file format v1 with version, pyobfus_version, created_at, root, mode (single_file | cross_file), modules, and precomputed global reverse index - ✅ CLI: new --save-mapping PATH flag writes mapping during obfuscation (works in both single-file and cross-file paths) - ✅ CLI: new --unmap mode with --trace FILE|- (stdin supported) and --mapping FILE inputs; --json emits structured output with ai_hint field - ✅ Tests: 11 in tests/test_mapping.py (construction, I/O roundtrip, version rejection, text rewriting, qualified paths), 6 in tests/test_unmap_cli.py (end-to-end save + unmap for both single-file and directory modes, JSON output, error handling) - ✅ End-to-end smoke test: obfuscated class Calculator / def add → crash trace AttributeError: 'I0' object has no attribute 'I2' → unmapped to 'Calculator' object has no attribute 'add'

Verification: - Full suite: 601 passed (was 581), total coverage stays at 90% - Mapping module coverage: 98% - Identifier-boundary regex ensures I1 inside MyI1Thing is not falsely rewritten

Strategic notes: - This is the feature PyArmor structurally cannot offer. Their C-layer bytecode encryption is one-way; pyobfus retains a clean mapping and makes it explicit. - The ai_hint in --unmap --json output primes AI assistants to understand line numbers still refer to the obfuscated file (they don't automatically reverse) - Cross-file mode correctly pulls from orchestrator.global_table after phase2_transform — no architectural changes needed

Next: P0-3 framework presets (fastapi/django/flask/pydantic/click).

2026-04-22 — Session 4: P0-3 framework presets shipped¶

Delivered: - ✅ 6 new presets in pyobfus/config.py: preset_fastapi, preset_django, preset_flask, preset_pydantic, preset_click, preset_sqlalchemy. All built on preset_safe() (docstrings kept) and all set preserve_param_names=True. - ✅ Each preset bundles: - exclude_names for framework dispatch methods, ORM protocol, decorator-managed symbols - exclude_patterns for canonical directories that should not be touched (routers, migrations, alembic, wsgi/asgi, urls, settings, blueprints) - ✅ get_preset() dispatcher and list_presets() extended. New FRAMEWORK_PRESETS frozenset exposed as a public constant. - ✅ CLI: --preset Choice list extended with the 6 framework names; --list-presets output grew a new FRAMEWORK-AWARE section with usage examples. - ✅ CLI Pro gate: framework presets are correctly NOT gated — they fall through the pro-preset check unchanged. - ✅ Preflight module (P0-1) already emits suggested_preset: fastapi|django|… — those suggestions now resolve to real presets. No code change needed there. - ✅ Tests: 22 new in tests/test_framework_presets.py covering registration, exclusion contents, docstring preservation, CLI acceptance without Pro, --list-presets output. Updated tests/test_presets.py::test_list_presets count from 7 → 13.

Verification: - Full suite: 623 passed (was 601), total coverage stays at 90% - FastAPI preset end-to-end: def handler(user_id, limit=10) correctly keeps user_id/limit in obfuscated output - Pydantic preset end-to-end: model_dump() survives obfuscation

Strategic notes: - Preflight (P0-1) + framework presets (P0-3) now form a complete loop: pyobfus --check src/ → AI reads suggested_preset → pyobfus src/ -o dist/ --preset fastapi works out of the box. - This is the feature that answers "does it work with my framework?" with a single command, which is the #1 question PyArmor users ask.

Next: P0-4 AI-friendly CLI — extend --json to obfuscation runs, add ai-hint to error messages.

2026-04-22 — Session 5: P0-4 AI-friendly CLI shipped¶

Delivered: - ✅ --json flag now applies to the obfuscation run itself (previously only --check and --unmap) - ✅ Success payload shape: {version, status, input, output, preset, level, dry_run, stats, mapping, ai_hint} — stable schema across success/dry-run/mapped modes - ✅ Error payload shape: {version, status, error_type, message, suggestion, ai_hint, exit_code} — all three existing handlers (LimitExceededError, PyObfusError, generic Exception) now produce this when --json is set - ✅ Intermediate chatty output is suppressed via an sys.stdout swap during the obfuscation try block so the final JSON stays parseable (first char is {) - ✅ Context-aware ai_hint in success payload: - With --save-mapping PATH: points user to pyobfus --unmap for traceback debugging - Without mapping: suggests adding --save-mapping next time - With --dry-run: explains nothing was written - ✅ Two new reusable helpers: _emit_obfuscate_success_json(), _emit_error_json() - ✅ Tests: 9 new in tests/test_json_cli.py covering success + dry-run + preset + mapping + parse-error + no-prefix-text invariant, plus shape consistency for --check --json and --unmap --json

Verification: - Full suite: 632 passed (was 623), total coverage stays at 90% - End-to-end smoke: pyobfus src.py -o out.py --json emits one top-level JSON object with full stats and actionable ai_hint

Strategic notes: - All four P0 CLI modes (obfuscate, --check, --unmap, [future --init]) now share the same --json schema family (version, ai_hint, exit_code). This consistency is what the MCP server (P1-1) will wrap as tool responses without additional translation. - error_type field uses Python exception class name verbatim so an AI agent can branch on it (e.g. LimitExceededError → suggest trial).

Next: P0-5 pyobfus init — framework auto-detect + pyobfus.yaml generation.

2026-04-22 — Session 6: P0-5 `pyobfus init` shipped — P0 complete¶

Delivered: - ✅ New module pyobfus/core/init_config.py: InitResult dataclass + build_init_result() that delegates framework detection to the preflight checker (single source of truth) and composes a ready-to-use YAML - ✅ YAML rendering with explanatory comments aimed at both humans and AI assistants (provenance header, preset rationale, alternatives list, inline --check recommendation when risks are high) - ✅ Baseline exclude_patterns added on top of framework-suggested ones: test_*.py, **/tests/**, **/__pycache__/**, **/.venv/**, **/venv/**, **/build/**, **/dist/** - ✅ CLI: new --init flag; scan target defaults to CWD or accepts INPUT_PATH; --json emits structured {version, status, config_path, preset, excludes, frameworks_detected, files_scanned, high_risk_findings, written, ai_hint} - ✅ Human-mode confirmation prompt on overwrite; JSON mode overwrites silently (intended for AI agents and CI) - ✅ Config loader breakthrough: ObfuscationConfig.from_file now understands a top-level preset: key — preset applied first, remaining fields override, exclude_patterns and exclude_names merged additively. Generic ValueError raised for unknown keys instead of a cryptic TypeError from dataclass init. - ✅ Tests: 12 new in tests/test_init_config.py covering library-layer construction, YAML validity, round-trip through ObfuscationConfig.from_file, CLI human mode, CLI JSON mode, high-risk flagging, overwrite behavior

Verification: - Full suite: 643 passed (was 632), total coverage climbs to 91% - End-to-end: pyobfus --init /path/to/fastapi-project produces a yaml whose preset: fastapi loads correctly and obfuscates without additional config

Strategic notes: - The preflight/preset/init trio now forms the complete zero-config onboarding path an AI agent needs: call --check → read suggested_preset → call --init → call obfuscate. All four emit the same JSON schema family. - preset: YAML key support was a latent dependency discovered only while round-trip testing --init. Without it, the generated yaml would have been documentation-only. Fixing from_file is the largest non-obvious win of this session.

🎉 P0 Milestone: All 5 P0 features shipped in one day (2026-04-22)¶

ID	Feature	Status	Coverage	New tests
P0-1	`pyobfus --check` pre-flight	🟢	93%	20
P0-2	`pyobfus --unmap` reverse mapping	🟢	98%	17
P0-3	Framework presets × 6	🟢	—	22
P0-4	AI-friendly CLI `--json`	🟢	—	9
P0-5	`pyobfus --init`	🟢	88%	12

Suite grew 561 → 643 (+82 tests), coverage 90% → 91%
5 clean commits on main, 0 regressions
Whole AI-consumption loop works end-to-end: --check --json → --init --json → obfuscate --save-mapping --json → --unmap --json

Next session: BRAND-1/2/3 quick wins + P1-1 pyobfus-mcp server.

2026-04-22 — Session 12: Marketing strategy v2 + dev.to account established + channels tracking¶

Context: After publishing pyobfus 0.4.0 + pyobfus-mcp 0.1.0 and fixing CI, work shifted to the marketing phase. Three parallel research threads ran to inform the strategy.

Research outputs (3 parallel agents): - MCP Registry PR: discovered that modelcontextprotocol/servers retired third-party listings; the canonical path is now mcp-publisher CLI → registry.modelcontextprotocol.io. Requires a 0.1.1 bump on pyobfus-mcp to add the  marker to the PyPI README. Plan drafted at _drafts/mcp-registry-publish-plan.md. - Stack Overflow 2024+ targets: 7 verified active questions (replaced the old 2008-era list). All open, all activity in 2024+. Full list: _drafts/stackoverflow-seeding-targets.md. - Forum AI-policy + voice guide: compiled policies for SO, HN, Medium, dev.to, Reddit. Stack Overflow and Hacker News ban AI-generated content outright (no disclosure path); Medium allows with disclosure; dev.to / Reddit have no formal rule but mods remove AI-looking content. Current detectors flag unmodified Claude 4 output at ~98% — voice rewrite by the maintainer is mandatory before submission. Doc: _drafts/forum-ai-policy-and-voice-guide.md.

Strategic decision — pause SO seeding for 6 months: - Best 2024+ candidate (Q79400498) has ~40 views/month. 3 top-tier answers combined would yield ~2 clicks/month. - SO's AI-content ban is strictly enforced (confirmed via meta banner on every page + April 2026 community reaffirmations). - Low-rep maintainer account (11 rep) + self-promo answer = highest-scrutiny combination. - Decision captured in _drafts/stackoverflow-seeding-targets.md header + docs/AI_INTEGRATION_STRATEGY.md §8. - _drafts/so-answer-q79400498.md archived for potential reactivation Q4 2026.

pyobfus-mcp 0.1.1 staging (unpublished): - pyobfus_mcp/pyproject.toml → version 0.1.1 - pyobfus_mcp/README.md → added  marker - pyobfus_mcp/server.json → new, conforms to MCP Registry schema 2025-12-11 - pyobfus_mcp/CHANGELOG.md → new, documents 0.1.0 + 0.1.1 - Build verified: 16/16 tests pass, twine check passes, marker present in METADATA - ~~PyPI upload + mcp-publisher publish gated on user approval~~ → executed same session, 2026-04-22 01:45-01:48 UTC (confirmed 2026-05-03 from PyPI JSON API + registry public listing)

Post-hoc confirmation 2026-05-03: - PyPI pyobfus-mcp 0.1.1 live, upload time 2026-04-22T01:45:50, README marker present in METADATA - MCP Registry entry io.github.zhurong2020/pyobfus-mcp live since 2026-04-22T01:48:45, status=active, isLatest=true - mcp-publisher token cached at ~/.config/mcp-publisher/token.json (mtime 2026-04-22 09:48 local)

dev.to account established: - Handle: @zhurong2020 (matches GitHub, matches io.github.zhurong2020/ MCP namespace → consistent brand identity) - Created 2026-04-22 via GitHub OAuth (avatar auto-imported) - Profile: name "Rong Zhu", bio "Python engineer shipping tools for AI-assisted development. Maintain pyobfus — an obfuscator built to work with Claude Code, not against it.", brand color #f59e08, Work field = "Independent developer · 有心工坊 (YouXin Workshop)" - Notifications tuned: 2 email triggers (reply + mention), 1 on-site (reactions), everything else disabled - Auto-followed 28 users + 6 tags from signup flow - Warm-up plan: follow 10-15 deliberately-chosen MCP/python-obfuscation authors, leave 3-5 substantive comments, post #1 on 2026-04-24 (Thursday, dev.to peak traffic) - Full channel snapshot recorded in new docs/DISTRIBUTION_CHANNELS.md

Docs created / updated this session: - docs/DISTRIBUTION_CHANNELS.md — new, living channel-state reference - docs/AI_INTEGRATION_STRATEGY.md §8 — channel table revised with AI-policy risk column, SO dropped - _drafts/mcp-registry-publish-plan.md — new - _drafts/article-01-claude-code-mcp-integration.md — new (outline + 500-word English opener) - _drafts/stackoverflow-seeding-targets.md — new, then PAUSED header added after strategy revision - _drafts/forum-ai-policy-and-voice-guide.md — new - _drafts/so-answer-q79400498.md — drafted, then archived

Next session: execute MCP 0.1.1 publish (pending user approval), start first dev.to article full draft, prep awesome-mcp-servers PRs.

2026-05-03 — Session 13: awesome-mcp-servers PR + Glama submission cycle¶

Context: Resumed v0.4 marketing follow-up after a 10-day gap. Verified PyPI 0.1.1 + MCP Registry entry from Session 12 had actually shipped (registry shows io.github.zhurong2020/pyobfus-mcp active since 2026-04-22 01:48 UTC). Then drove the awesome-mcp-servers distribution leg.

awesome-mcp-servers strategy revision: - Originally planned three PRs (punkpeye/wong2/appcypher). Dropped two: - appcypher/awesome-mcp-servers: last commit 2025-09-04 (~8 months stale at decision time). Skipped. - wong2/awesome-mcp-servers: README banner explicitly says "We do not accept PRs. Submit via mcpservers.org/submit." Routed to user form action; not in this session's scope. - Only punkpeye/awesome-mcp-servers (86k★, last commit 2026-05-02) is the active target.

punkpeye PR cycle: - PR #5777 opened with entry under ### 💻 Developer Tools, appended at section bottom: https://github.com/punkpeye/awesome-mcp-servers/pull/5777 - Bot review applied 3 labels: has-emoji (informational), invalid-name (display text didn't match URL owner/repo), missing-glama (need Glama score badge). - invalid-name fixed in fork commit 8126eecf: changed display text from zhurong2020/pyobfus-mcp to zhurong2020/pyobfus to match URL slug, removed inner [pyobfus](...) link from description. - missing-glama requires upstream Glama indexing → pivoted to Glama submission flow.

Glama submission saga (the long part): - Discovered Glama runs two products under similar names: a paid AI workspace (Connectors / Deployments / Preferences) and the public MCP registry (https://glama.ai/mcp/servers). User initially landed in the paid product's onboarding by mistake; redirected to the registry's "Add MCP Server" form. - User submitted the form with https://github.com/zhurong2020/pyobfus as the GitHub URL. - Rejection received 2026-05-03, reason: "The submitted repository is a Python obfuscator, not an MCP server. The README does not mention implementing an MCP server, tools, or resources in the MCP sense." Reviewer never descended into pyobfus_mcp/ subfolder. - Root cause: root README framed MCP integration as "AI-native CLI features" (commands like --check, --init, --unmap) without flagging that pyobfus-mcp is a separately-installable MCP server package. A reviewer landing on the root README has no signal to look at pyobfus_mcp/.

Repo-side fixes pushed to main: - Commit 7cccbdf — backfill execution log Session 12 confirmation - Commit 9391c6c — glama.yaml (root) + pyobfus_mcp/Dockerfile. Dockerfile is python:3.12-slim + pip install pyobfus-mcp==0.1.1 + non-root UID 1987 per Glama convention. glama.yaml declares stdio transport, points build.dockerfile at the subfolder so Glama's auto-detector doesn't get confused by the monorepo layout. - Commit fe0d52e — root README adds "🔌 Companion MCP server: pyobfus-mcp" section near the top with a two-row "this repo ships two packages" table and a five-row per-tool table linking directly into pyobfus_mcp/pyobfus_mcp/tools.py. Names FastMCP and the official MCP Python SDK explicitly. The MCP Registry namespace io.github.zhurong2020/pyobfus-mcp is now visible without scrolling.

Re-review email sent 2026-05-03 to support@glama.ai (reply to original rejection): plain-text request listing concrete evidence (server.py at known path with @app.tool decorators, separate PyPI distribution, existing MCP Registry entry, dedicated pyobfus_mcp/README.md), and pointing at the new root README "Companion MCP server" section + glama.yaml + Dockerfile. Awaiting response.

Status of #1 (v0.4 distribution leg): - PyPI pyobfus-mcp 0.1.1 ✅ - MCP Registry io.github.zhurong2020/pyobfus-mcp ✅ active - punkpeye PR #5777 🟡 blocked on Glama badge — invalid-name cleared, missing-glama pending Glama re-review approval - Glama public registry indexing 🟡 pending re-review (rejection email reply sent 2026-05-03) - appcypher list ❌ skipped (stale) - wong2 list ⚠️ deferred to user form action (mcpservers.org/submit)

Next: - When Glama approves: badge endpoint at https://glama.ai/mcp/servers/zhurong2020/pyobfus/badges/score.svg returns SVG → update PR #5777 to insert badge between display name and emoji icons (look at line 1090 ypollak2/llm-router or 1097 drumst0ck/uploadkit for exact format). - After PR #5777 merges or stalls 2+ weeks: brief user on wong2 / mcpservers.org submission. - Then move to #4 (CCPC software copyright filing) per user-stated priority.

2026-05-03 — Session 14: PII audit + git history rewrite¶

Context: Audit found that docs/legal/software_copyright/ (CCPC software copyright filing materials, committed in commits e75d62c / e334010 / efecebb) and one bullet in CLAUDE.md exposed personally identifiable information in the public repo: applicant real Chinese name, city/district, spouse name and email, family relationship language, ID-card references, hardware specs. The repo is public, so this content was indexable by Google/Bing and visible to any GitHub user.

Phase 1 — surface clean (commit f5be6e9, since rewritten): - Moved entire docs/legal/software_copyright/ folder out of the repo to a sibling location at ../pyobfus-legal/software_copyright/ (kept on OneDrive backup; never under git anywhere) - Added docs/legal/software_copyright/ to .gitignore to prevent reintroduction - Removed the CLAUDE.md bullet that named the applicant and spouse

Phase 2 — history rewrite with git filter-repo (today): - Tooling: git-filter-repo already at ~/.local/bin/git-filter-repo - Backup created at ../pyobfus-backup-pre-filter-repo-20260503-2231/: full .git tarball + git bundle --all + commit hash snapshot (219 commits) + restoration instructions in README - Step 1: git filter-repo --path docs/legal/software_copyright --invert-paths --force — removed 12 file additions across history, 219 commits processed in 4s - Step 2: git filter-repo --replace-text replace-pii.txt --force — redacted "诸嵘" / "陈启稚" / "qizhi_chen@126.com" → [REDACTED-NAME] / [REDACTED-EMAIL] everywhere in history - Restored origin remote (filter-repo strips it as a safety guard) - Force-pushed with --force-with-lease=main:f5be6e9 so the push aborts if anyone else had pushed in the meantime

Verification on a fresh clone from origin: - 诸嵘: 0 mentions across all history (was 15 added lines) - 陈启稚: 0 mentions across all history (was 7 added lines) - qizhi_chen: 0 mentions (was 1 line) - docs/legal/software_copyright/ path: 0 file additions across all history (was 12) - Old commit hashes (e75d62c, efecebb, etc.): git show returns "unknown revision" — orphaned

Residual non-issues: - The path string "docs/legal/software_copyright" still appears 6× in history: 3 in .gitignore defensive rule + 3 in the new redacted CLAUDE.md historical content (申请人：[REDACTED-NAME]，自然人；与配偶[REDACTED-NAME]…). All benign — no real PII.

Side effects to be aware of: - Every commit hash on main changed. Earlier entries in this execution log reference specific old hashes (fe0d52e, 9391c6c, efecebb, 8272214, etc.) — those references no longer resolve via git show. The prose remains accurate; the commits themselves now have new hashes. - Past links to commit/<hash> URLs on GitHub will return 404. - The old objects remain reachable from forks that already pulled them (current fork count: 2; one is our own awesome-mcp-servers fork which is unrelated). GitHub keeps unreachable commits in their backend ~90 days before garbage collection. - release/v0.1.4 branch on remote was untouched (verified to have 0 PII references prior to leaving alone). - Local tags (14 of them, v0.1.0 → pyobfus-mcp-v0.1.1) untouched.

Remaining phases (not yet executed): - ~~Phase 3 — re-render the 4 CCPC submission screenshots~~ ✅ done 2026-05-05, see Session 15 below - ~~Phase 4 — install a pre-commit hook~~ ✅ done 2026-05-05, see Session 16 below

Backup retention: keep ../pyobfus-backup-pre-filter-repo-20260503-2231/ for ≥30 days. After 30 days with no issues surfaced, delete and note the deletion here.

2026-05-05 — Session 15: PII cleanup Phase 3 — CCPC screenshots re-rendered¶

Context: Session 14 (2026-05-03) completed Phase 1 (surface clean) + Phase 2 (git history rewrite). The 4 CCPC submission screenshots were left for a separate Phase 3 because they are PNG raster files outside the git repo (in ../pyobfus-legal/software_copyright/screenshots/) and need re-rendering, not text edits.

PII signals identified in original screenshots: - All 4: window title bar + shell prompt show rong@wsl:~/projects/pyobfus (or ~/tmp/demo for shot 03) - Shot 01 (pip show output) additionally exposes Location: /home/wuxia/projects/pyobfus/venv/lib/python3.12/site-packages — the path leaks the actual WSL system username wuxia, which is independent of the applicant identity

Approach: rather than pixel-edit the existing PNGs, write a clean PIL renderer that reproduces the original xterm dark-theme aesthetic and emit fresh PNGs with neutralized prompt/path. Script lives outside the repo at ../pyobfus-legal/software_copyright/render_screenshots.py (sibling folder to the legal materials, never under git) — easy to re-run for the next round of CCPC corrections.

Substitutions applied: - rong@wsl → demo@machine (window title + shell prompt, all 4 screenshots) - ~/projects/pyobfus → ~/demo (path component in title + prompt, shots 01/02/04) - ~/tmp/demo → ~/demo (shot 03 working directory) - /home/wuxia/projects/pyobfus/venv/... → /home/demo/demo/.venv/lib/python3.12/site-packages (shot 01 Location field)

Deliberately preserved as evidence: Author-email: Rong Zhu <zhurong0525@gmail.com> in shot 01. This line is publicly visible on PyPI's pyobfus package page (verified via https://pypi.org/pypi/pyobfus/json), and the email matches the CCPC applicant's account zhurong0525. Stripping it would weaken the PyPI-to-applicant authorship chain that the legal README §五 cites as evidence. The PII cleanup scope was always "neutral hostname/path", not "anonymize applicant identity in the applicant's own filing".

Verification: - All 4 PNGs regenerated cleanly: 1280×544 / 1280×664 / 1600×764 / 1280×724 - Visual review via Read tool confirms no wuxia, rong@wsl, /home/wuxia/, or ~/projects/pyobfus strings remain - Author-email line present and accurate (matches PyPI public metadata) - Render script is reproducible — depends only on Pillow + fonts-dejavu-core

Updated docs: - pyobfus-legal/software_copyright/README.md §五 — note re-render date + new script location - pyobfus-legal/software_copyright/README.md §九 — checkbox annotated - this session entry

Next: Phase 4 (pre-commit PII scan hook). Then resume v0.4 distribution leg (Glama re-review, dev.to first article).

2026-05-05 — Session 16: PII cleanup Phase 4 — pre-commit guard installed¶

Context: Closes the 4-phase PII cleanup. Phases 1-3 removed PII from working tree (Session 14), git history (Session 14), and CCPC screenshots (Session 15). This session adds the structural guard against reintroduction.

Decision — native git hook over pre-commit framework: pyobfus had no .pre-commit-config.yaml and no other framework-style hook setup. For a single-purpose regex scan, adding the pre-commit Python tool plus the YAML config is more moving parts than the threat warrants. A .githooks/pre-commit shell script is self-contained, zero-dependency, easy to read, and easy to extend.

Delivered: - .githooks/pre-commit (executable bash script): scans staged blob content via git grep --cached -nE for 5 patterns: 诸嵘, 陈启稚, qizhi_chen, 身份证, /home/wuxia/. Exit 1 with diagnostic on hit, exit 0 otherwise. - Allowlist ALLOWLIST_RE: docs/V0.4_EXECUTION_LOG.md, .githooks/pre-commit, .githooks/README.md, CLAUDE.md — all four legitimately enumerate the patterns. - One-shot bypass via PYOBFUS_ALLOW_PII=1 git commit ... for unusual legitimate cases. - .githooks/README.md documents purpose, setup, allowlist, and bypass. - CLAUDE.md "本地开发" section now lists git config core.hooksPath .githooks as one-time setup with a one-line pointer to the hook's purpose. - This clone activated: git config core.hooksPath .githooks.

Verification (3 paths tested): - ✅ Allowlisted files (.githooks/pre-commit + .githooks/README.md) staged → hook exit 0 (patterns inside them are by design). - ✅ Synthetic violation (_pii_violation.py with /home/wuxia/... line) staged → hook exit 1 with file:line:content + remediation hint. - ✅ Same violation re-tested with PYOBFUS_ALLOW_PII=1 → exit 0. Test fixture removed afterward.

Why git grep --cached not git diff --cached: scanning the full staged blob (not just added lines) catches the case where someone moves a file containing PII across the working tree without modifying the offending line — the diff would not include the line, but the file is still PII-laden.

Limitations / out of scope: - Server-side enforcement is not configured. A determined operator can still push direct via --no-verify or by editing on github.com. The hook is a developer-side guard, not a security boundary. - Binary files (e.g. PNG) are skipped by git grep default. Re-introducing PII via a screenshot would not trigger this hook — that's why Phase 3 + the gitignore on docs/legal/software_copyright/ exist as separate layers. - Each fresh clone needs git config core.hooksPath .githooks once. The setup line is in CLAUDE.md, but git provides no automatic activation mechanism for tracked hooks (security-by-design on git's part).

4-phase cleanup status: Phase 1 ✅ Phase 2 ✅ Phase 3 ✅ Phase 4 ✅ — done.

Next: resume v0.4 distribution leg. Top of stack: monitor Glama re-review reply, draft first dev.to article.

2026-04-22 — Session 11: Post-release CI debugging + Python 3.8 lesson propagation¶

Context: After publishing pyobfus 0.4.0 + pyobfus-mcp 0.1.0 to PyPI, GitHub Actions surfaced two back-to-back failures on Python 3.8 (macOS ARM64 on first push, Windows 3.8 on rerun). Pattern didn't match any of the 7 historical Python 3.8 issues documented in docs/PYTHON38_COMPATIBILITY.md.

Diagnosis: - All tests actually passed (648 / 647 + 7 skipped, 0 failed) - Failure signature: Process completed with exit code 1 with no traceback (macOS) then test_dead_code_injection - assert 1 == 0 (Windows) - Only ONE Python 3.8 matrix cell failed per run; other two OSes × 3.8 + all Python 3.9-3.14 passed - Same root cause as commit ee80edf (combined Pro tests): astunparse-generated output is intermittently invalid on Python 3.8 for Pro-transformer ASTs, surfacing through pytest-cov's finalization step

Fix (commit 7227c29): - tests/test_cli_pro_paths.py: @requires_py39 applied to the 4 single-feature Pro CLI tests (test_control_flow_flattening, test_string_encryption, test_anti_debug, test_dead_code_injection), matching the existing convention for combined Pro tests - docs/PYTHON38_COMPATIBILITY.md: added problem §8 with the exact diagnostic signature so next-session pattern-matching is instant

Verification: - CI on 7227c29 (run 24753445546): green — first clean CI run since ee80edf - Local: 28 test_cli_pro_paths pass, black/ruff pass

Documentation propagation (this session's second pass): - CLAUDE.md: added inline warning under Testing section pointing to PYTHON38_COMPATIBILITY.md for Pro+CLI test additions - CONTRIBUTING.md: Testing Standards section gains a "Python 3.8 Caveat" subsection with an example of the @requires_py39 pattern - docs/ROADMAP.md: new "v0.5.0 — Candidate: drop Python 3.8 support" section proposing requires-python = ">=3.9" and matrix cleanup (Python 3.8 EOL was 2024-10) - docs/V0.4_EXECUTION_LOG.md: this entry

Rationale: spreading the lesson across four docs ensures future refactors, new contributors, and AI coding agents all hit the warning before reintroducing the bug pattern. Each doc reaches a different audience (CLAUDE.md = session prefix, CONTRIBUTING.md = external contributors, ROADMAP = planning, EXECUTION_LOG = historical trail).

Next: resume post-release follow-ups (MCP Registry PR, first promotional article, Stack Overflow seeding).

2026-04-22 — Session 7: Branding quick wins¶

Delivered: - ✅ pyproject.toml description rewritten — keyword-dense, co-brands "pyobfus — the Python obfuscator", calls out framework presets and MCP/AI-agent story, positions as "modern PyArmor alternative" - ✅ pyproject.toml keywords extended from 10 → 30 tokens: adds python-obfuscator, py-obfuscator, pyobfuscator (alias density), 6 framework names, mcp, mcp-server, claude-code, cursor, llm-tools, ai-native, ai-friendly, vibe-coding - ✅ Classifier: Development Status :: 3 - Alpha → 4 - Beta (matches 643 tests / 91% coverage). Added Topic :: Software Development :: Build Tools, Topic :: Security :: Cryptography, Typing :: Typed. - ✅ project.urls adds AI Integration Guide + Roadmap links - ✅ README H1: "pyobfus — the Python obfuscator" with pronunciation line in the first paragraph - ✅ README adds a prominent "🤖 New in v0.4.0 — AI-native features" section highlighting --check, --init, --unmap, framework presets, and global --json - ✅ GitHub topics applied via gh repo edit: 12 topics including python-obfuscator, code-obfuscator, ast-obfuscation, mcp-server, claude-code, cursor, llm-tools, ai-native, pyarmor-alternative, python-security, code-protection, source-protection

PyPI alias squatting (BRAND-1) — partial, needs manual follow-up:

Availability check results: | Alias | Status | Action | |---|---|---| | python-obfuscator | Taken (v0.1.0, other maintainer) | Cannot squat | | pyobfuscator | Taken (v0.1.10, other maintainer) | Cannot squat | | py-obfuscator | Available | Register on PyPI |

Recommended follow-up (manual, requires PyPI auth): 1. Create a thin wrapper package py-obfuscator that pip installs as pyobfus 2. Upload via twine to PyPI under the owner's account 3. Wrapper is 3 lines of Python + a 1-paragraph README pointing users to the real package

Verification: - Full suite: 643 passed, coverage 91% (no regression from pyproject / README changes) - gh repo view confirms 12 topics applied to the GitHub repo

Next: P1-1 pyobfus-mcp server — highest-leverage single action on the roadmap.

2026-04-22 — Session 8: P1-1 `pyobfus-mcp` server package shipped¶

Delivered: - ✅ New top-level package pyobfus_mcp/ (standalone pyobfus-mcp on PyPI when published). Depends on pyobfus>=0.4.0 and mcp>=1.0.0. - ✅ pyobfus_mcp/pyobfus_mcp/tools.py: 5 pure-Python tool functions (check_obfuscation_risks, generate_pyobfus_config, unmap_stack_trace, list_presets, explain_preset). Each returns a stable dict shape with status and ai_hint fields. SDK-independent so tests work without mcp installed. - ✅ pyobfus_mcp/pyobfus_mcp/server.py: Thin FastMCP adapter that registers each tool. The SDK import is lazy inside _build_server() so the module is always importable. - ✅ pyobfus_mcp/pyproject.toml: Beta classifier, keyword-dense description mentioning Claude Desktop / Claude Code / Cursor / Windsurf / Zed, pyobfus-mcp console script. - ✅ pyobfus_mcp/README.md: install snippet + per-client configuration (Claude Desktop, Cursor, Windsurf, Zed, Claude Code claude mcp add) + example session showing the AI-assisted obfuscation + debugging workflow. - ✅ Tests: 16 in pyobfus_mcp/tests/test_tools.py. Covers clean project, eval detection, framework detection, path errors, YAML return-vs-write, preset override, unmap roundtrip (including mapping-not-found and invalid-version paths), preset grouping and explanation, and the "server importable without mcp SDK" invariant.

Verification: - MCP tool tests: 16/16 passed (without mcp SDK installed — tests run against tools.py directly) - Main package suite: 643 passed, 91% coverage — no regression from the new subdirectory - End-to-end JSON shape across main CLI (--check, --init, --unmap) and MCP tools is identical, so the server adds zero translation overhead.

Strategic notes: - This is the feature from the AI-era strategy doc. Once pyobfus-mcp lands in the Anthropic MCP Registry, every Claude Desktop / Cursor / Windsurf user gets pyobfus as a discoverable tool without running a single pip command. - The pure-Python tools.py layer doubles as a clean embedding API for third-party agent frameworks (LangGraph, LlamaIndex agents, etc.) — they can import and call these functions directly without MCP. - Publishing to PyPI is a manual follow-up step (requires twine and the maintainer's token). Not in scope for this session.

Next: P1-2 llms.txt + llms-full.txt (should take 2 hours), then P1-3 AI integration templates.

2026-04-22 — Session 9: P1-2 llms.txt + P1-3 AI templates shipped¶

Delivered — P1-2 (llmstxt.org standard): - ✅ /llms.txt — concise overview: what pyobfus is, when to use / not use, core commands, framework presets, agent workflow tips, links - ✅ /llms-full.txt — full reference: JSON schemas for every CLI mode, complete YAML config field reference, MCP tool signatures, agent workflow recipes - ✅ /docs/llms.txt — same concise file at the docs site root so ReadTheDocs / Perplexity / Claude.ai crawlers find it there too

Delivered — P1-3 (AI integration templates): - ✅ New templates/ai-integration/ directory with drop-in rule files for 6 client formats: - CLAUDE.md — Claude Code project rules - .cursorrules — Cursor legacy format - cursor-rules.mdc — Cursor new .mdc format with frontmatter - windsurfrules.md — Windsurf - AGENTS.md — generic protocol for Aider / Continue / Cline / any agent - copilot-instructions.md — GitHub Copilot - ✅ Every template encodes the same 4-step workflow (--check → --init → obfuscate with --save-mapping → --unmap), preset selection heuristic, and safety invariants (don't ship mapping.json, don't obfuscate tests, surface high-severity findings before obfuscating) - ✅ templates/ai-integration/README.md — directory overview with "copy this file here" table

Verification: - Files are static markdown; no tests run. Main suite unchanged: 643 passed, 91% coverage.

Strategic notes: - The templates ARE the viral-distribution mechanism. Every user who copies CLAUDE.md into their own repo is teaching their AI tools about pyobfus, which builds training-corpus presence faster than blog posts. - P1-4 (PyPI metadata overhaul) was already landed inside the BRAND commit. Marked as such in the status board. - That leaves only P1-5 (incremental obfuscation) from the original v0.4 scope.

Next: P1-5 incremental obfuscation — AST-hash-based caching so CI pipelines only reprocess changed files.

2026-04-22 — Session 10: P1-5 incremental obfuscation shipped — v0.4 COMPLETE¶

Delivered: - ✅ New module pyobfus/core/cache.py with BuildCache + CacheHit: SHA-256 per-file hashing, config-field normalization (sets→sorted lists for stable signatures), JSON manifest at <output>/.pyobfus-cache/manifest.json with format version guard - ✅ CLI: new --incremental flag. Directory mode only — single-file rebuilds skip the machinery (not worth the overhead). JSON mode reports stats.files_skipped - ✅ Cache invalidation when ANY of the following changes: input file list, any file's content hash, config fields that affect output, pyobfus version, or cached output files are missing - ✅ Tests: 12 new in tests/test_incremental.py — unit tests for BuildCache (signature stability, content-sensitivity, config-sensitivity, manifest version guard, output-deletion detection) and CLI end-to-end (first-run builds manifest, second-run hits cache, rebuilds after edit, JSON reports skipped count, single-file mode is no-op)

Design choice — project-level, not per-file:

With cross-file obfuscation the global symbol table depends on every file. Reusing one file's obfuscated output while another file changed would break import consistency. Project-level is the largest safe unit. Per-file caching is possible but needs careful symbol-table partitioning and is deferred to v0.4.1+.

Verification: - Full suite: 655 passed (was 643), total coverage 91% - End-to-end: two-run sequence on a two-file project correctly skips on run 2 with message Incremental: skipping — inputs, config, and outputs all unchanged (2 output file(s) reused)

🎉 v0.4 Complete: All 10 P0 + P1 features shipped in one day (2026-04-22)¶

ID	Feature	Status	New tests
P0-1	`pyobfus --check` pre-flight	🟢	20
P0-2	`pyobfus --unmap` reverse mapping	🟢	17
P0-3	Framework presets × 6	🟢	22
P0-4	AI-friendly CLI `--json`	🟢	9
P0-5	`pyobfus --init`	🟢	12
P1-1	`pyobfus-mcp` server package	🟢	16
P1-2	`llms.txt` + `llms-full.txt`	🟢	—
P1-3	AI integration templates × 6	🟢	—
P1-4	PyPI metadata overhaul	🟢	— (bundled with BRAND)
P1-5	Incremental obfuscation	🟢	12
BRAND-2/3	GitHub topics + Dev Status → Beta + README	🟢	—

Suite grew 561 → 655 (+94 tests main) + 16 MCP tests. Coverage 90% → 91%.
10 clean commits on main, 0 regressions.
BRAND-1 (PyPI alias py-obfuscator) remains a manual follow-up: twine upload needs maintainer credentials.

🚀 Recommended manual follow-ups (not in scope for this session)¶

git push origin main to publish the 10 commits
twine upload dist/* for a v0.4.0 release of pyobfus
cd pyobfus_mcp && python -m build && twine upload dist/* for pyobfus-mcp v0.1.0
Register py-obfuscator on PyPI as a thin wrapper (3-line package pointing to pyobfus)
Submit pyobfus-mcp to the Anthropic MCP Registry
Announce: ResearchHatch, dev.to article #1, Hacker News "Show HN"

2026-05-07 — Session 17: Glama re-review approved · pyobfus-mcp 0.1.2 emergency release · v0.4 distribution leg fully unblocked¶

Context: Session 13 (2026-05-03) had submitted Glama re-review request after the initial rejection (reviewer didn't see pyobfus_mcp/ subfolder). This session resumed 4 days later when approval landed, drove the awesome-mcp-servers PR badge through, then surfaced and shipped an emergency PyPI release for an MCP SDK API drift bug exposed by Glama's automated container build.

Glama approval (post-4-day review): - 2026-05-07 ~10:00 local: Glama support email confirming listing at https://glama.ai/mcp/servers/zhurong2020/pyobfus. - ⚠️ Canonical URL is OWNER/REPO zhurong2020/pyobfus, NOT the pyobfus-mcp Name field. Alias /pyobfus-mcp redirects to canonical for the detail page, but the /badges/score.svg endpoint only resolves on the canonical path. Future submissions: GitHub-derived path is the authoritative identifier; the Name form field is display-only. - Initial grades after auto-import: License A (Apache 2.0), Maintenance A, Quality - (pending Dockerfile + introspection check).

punkpeye PR #5777 unblock — commit bb00228: - README.md line 1101 entry updated with Glama score badge inserted between GitHub URL and emoji indicators (matching the format used by 3 surrounding PR-approved entries — DigiCatalyst-Systems/dep-diff-mcp, hikmahtech/drwhome, tooluse-labs/perfetto-mcp-rs). - Pushed to add-pyobfus-mcp branch on zhurong2020/awesome-mcp-servers fork. - Bot re-evaluation latency: 45 seconds. missing-glama → has-glama ✅; check-submission QUEUED → SUCCESS ✅; PR became MERGEABLE. - New bot comment glama-badge-check requested actual quality score populated (badge URL was live but score was - not letter grade). This forced the Glama Dockerfile config saga.

Glama Dockerfile config — 4 attempts to find working build steps:

#	Build steps	Outcome
1 (default Glama auto-fill)	`["uv sync"]`	Failed: monorepo `pyobfus_mcp/` is a sub-package; `uv sync` at root installs `pyobfus` core (not `pyobfus-mcp`), CMD `mcp-proxy -- pyobfus-mcp` then can't find the binary
2 (PyPI install)	`["uv pip install --system pyobfus-mcp==0.1.1"]`	Failed in 1.7s: PEP 668 `externally-managed-environment` block on Debian trixie's `/usr/bin/python3.13`. uv default Python `--default --preview` channel installed 3.12 to `/usr/local/bin/python` but `--system` flag resolves to `/usr/bin/python3.13` which carries the `EXTERNALLY-MANAGED` marker.
3 (PEP 668 bypass)	`["uv pip install --system --break-system-packages pyobfus-mcp==0.1.1"]`	Install succeeded (32 packages including `pyobfus-mcp` 0.1.1 + `mcp` 1.27.0 + `pyobfus` 0.4.0), but runtime crashed at startup: `TypeError: FastMCP.__init__() got an unexpected keyword argument 'version'` — surfaced the upstream API drift bug
↓↓↓ Triggered emergency 0.1.2 release ↓↓↓
4 (post-fix)	`["uv pip install --system --break-system-packages pyobfus-mcp==0.1.2"]`	✅ Build success in 10.1s. Full MCP introspection verified: `initialize` handshake (`protocolVersion: '2025-11-25'`), `tools/list` returning all 5 tools with correct schemas, `prompts/list` + `resources/list` returning empty lists (correct — we don't register those).

Root cause of attempt #3 failure (the production bug): - pyobfus_mcp/server.py:61 called FastMCP(name="pyobfus", version=__version__). - 0.1.0 / 0.1.1 shipped 2026-04-22 against mcp SDK 1.0.x where the version= kwarg was accepted. - Between 1.0 and 1.20+, mcp SDK removed the version= kwarg from FastMCP.__init__() (no deprecation warning we saw — silent break). - Glama container pulled mcp==1.27.0 (current latest as of 2026-05-07). - This was a real production bug, not a Glama-specific issue: every user installing pyobfus-mcp 0.1.0 / 0.1.1 today via pip install pyobfus-mcp hit the same TypeError. Affected Claude Desktop, Claude Code, Cursor, Windsurf, Zed users on fresh installs.

Emergency 0.1.2 release: - pyobfus_mcp/pyobfus_mcp/server.py: drop version=__version__ kwarg (3 lines of comment explaining why); drop now-unused from pyobfus_mcp import __version__ import. - pyobfus_mcp/pyproject.toml: tighten dep mcp>=1.0.0 → mcp>=1.20.0,<2.0.0 (lower bound matches our test SDK; upper cap prevents future mcp 2.0 from silently re-introducing breaking changes); version bump 0.1.1 → 0.1.2. - pyobfus_mcp/CHANGELOG.md: 0.1.2 entry with Fixed / Changed / Notes sections. - Verification: 16/16 unit tests pass (no regression); smoke test _build_server() against locally-installed mcp==1.27.0 returns FastMCP with all 5 tools registered. - Build + upload: pyobfus_mcp-0.1.2-py3-none-any.whl (9186 B) + .tar.gz (10529 B) uploaded to PyPI at 2026-05-07T11:43:03 UTC. - Git: commit 92e33a1 on main, tag pyobfus-mcp-v0.1.2, both pushed to origin/main.

Final landed state (2026-05-07 evening): - PyPI: pyobfus-mcp 0.1.2 live at https://pypi.org/project/pyobfus-mcp/0.1.2/ - Glama listing: Quality grade A; 5 tools individually A (3.7 / 3.8 / 3.9 / 4.0 / 4.5/5.0 — list_presets highest at 4.5); License A; Maintenance A; Author verified; Has Glama release ✅ - Glama profile completion: 58% (Server Coherence + Tool Definition Quality aggregate still computing async after release publish; remaining items pulling % down — "No recent usage" / "No related servers" — are time-based or auto-detected and not actionable; "No glama.json" addressed in this session by adding root-level glama.json alongside existing glama.yaml). - punkpeye PR #5777: labels has-emoji / valid-name / has-glama (3 green); check-submission SUCCESS; mergeable; awaiting human maintainer review (no SLA — typical 86k★-repo cadence is 3-7 days). - Badge SVG live at https://glama.ai/mcp/servers/zhurong2020/pyobfus/badges/score.svg (was 0 bytes pre-release, now 7010 B with real score rendering).

Polish items closed in this session: - Added glama.json at repo root (alongside existing glama.yaml). Mirrors yaml content in JSON form. Closes the "No glama.json" item on Glama's profile completion checklist. - Bumped pyobfus_mcp/server.json version field 0.1.1 → 0.1.2 (both top-level and packages[0].version) and re-published to MCP Registry via mcp-publisher publish. Anthropic's official directory now shows 0.1.2.

Remaining backlog (not blocking anything): - punkpeye human merge — passive wait. - Glama "No recent usage" / "No related servers" — time-based, can't force. - 4-platform launch leg (drafts at _drafts/post-hn-show-hn.md etc.) — unblocked but not started; still needs human-voice rewrite + GPTZero gate.

2026-05-07 — Session 18 (evening): v0.4 distribution leg launched · self-audit + N2 expansion¶

Context: Session 17 (morning) closed technical-readiness but left "4-platform launch leg unblocked but not started" as standing backlog. Session 18 executed: tech hygiene + article rewrite + dev.to publish + community engagement + self-audit + N2 scope expansion. End state: dev.to first post live, CN/HN/Reddit calendar locked, N2 expanded to 4-5 day 3-way bundle.

P0 sequence executed:

ID	Action	Commit
P0.1	CI smoke test against latest mcp SDK (catch FastMCP API drift early)	`8ec0fcd`
P0.2	OIDC trusted publishing release workflow + PEP 740 attestations	`a3da282` (workflow) + maintainer-side PyPI Trusted Publisher registration for both `pyobfus` and `pyobfus-mcp`
P0.3	`server.json` `_meta` block (Glama / aggregator namespace claim)	`4f8886f` (registry publish deferred — see finding below)
P0.4 v3	Article voice rewrite (kill parallel rhythms, add dated specifics)	`ca12e25`
P0.4 v4	GPTZero-diagnostic-driven rewrite	`ec5fc65`
Doc sync	dev.to launch facts → DISTRIBUTION_CHANNELS + POST_V0.4_TODO P0.4 mark done	`2dd313a`
Doc sync	POST_V0.4_TODO recommended-sequence locked to Mon HN / Tue Reddit / Sat CN	`94aab92`
Scope expansion	POST_V0.4_TODO N2 expanded to 3-way bundle (FastMCP 3.0 + Pro funnel + security hardening)	`ff71144`

P0.3 finding (deferred to N2): mcp-publisher publish with same version returns HTTP 400 cannot publish duplicate version. MCP Registry behaves like PyPI / Glama Release flow for same-version rejection. mcp-publisher 1.7.8 has no _meta-only update command (init / login / logout / publish / status / validate — status only flips active/deprecated). Committed _meta block ships on next legitimate version bump (N2's 0.2.0). Side finding: mcp-publisher JWT actually expires within ~80 min (not "~15 days" as prior doc claimed); non-interactive re-login workaround mcp-publisher login github -token "$(gh auth token)" confirmed. Both findings captured in memory mcp_publisher_auth.md.

P0.4 GPTZero diagnostic loop: - v3 paste-tested at gptzero.me → AI 100% / Mixed 0% / Human 0% ("highly confident this text was AI generated"). - Per-sentence breakdown identified High-AI-Impact patterns (mid-length explanatory prose, subordinate clauses, "I was X-ing Y" past-progressive openers, "X is the Y, so I tried Y" setup-payoff, "X exist to Y" meta-narration) vs Low-AI-Impact (fragments, very-long-with-parenthetical-asides, dated/numbered specifics). - v4 surgically rewrote every High-AI sentence; preserved every Low-AI sentence intact. Burstiness char-range 4-200 (v3) → 2-257 (v4). - Strategic call: NOT re-paste-testing v4 absolute %. dev.to has no AI ban, function-clarity dominates for our buyer/user, HN/Reddit/CN get separate short-form posts. v4 is final for dev.to.

dev.to launch — LIVE 2026-05-07 evening: - URL: https://dev.to/zhurong2020/let-claude-code-debug-your-obfuscated-python-a-guide-to-the-pyobfus-mcp-integration-3epm - Tags: ai, python, claudecode, mcp (4) - Cover: 03_obfuscate_demo.png (BEFORE/AFTER side-by-side, 1600×764) - 2 inline images at marked positions: 04_json_output.png (after Preflight check) + 03_obfuscate_demo.png (after Obfuscate-with-mapping) - 1,603 prose words · 9 fenced code blocks · disclosure first paragraph - WebFetch verification: cover set, disclosure visible, both inline images render, all 4 GitHub reference links functional, no rendering issues.

Launch wave calendar locked (per maintainer 2026-05-07 evening): - Fri 5-8 / Sat 5-9: CN trio (有心工坊 / 知乎 / V2EX) using _drafts/post-cn-bilingual.md — within +48h of dev.to - Mon 5-11 evening 9-10pm UTC: HN Show HN using _drafts/post-hn-show-hn.md — pushed from original +48h Sat plan to Mon for HN's strongest traffic window (also gives dev.to 4 days to accumulate reactions as social proof) - Tue 5-12 evening: Reddit /r/Python using _drafts/post-reddit-rpython.md — captures HN-bounce traffic

Community engagement: - Substantive comment posted on Atlas Whoff's "5 MCP Server Security Mistakes That Could Expose Your AI Stack" (dev.to 2026-05-06). Angle: tool-description prompt injection as a 6th category not on his list. Comment ends with question to encourage reply. - Comment included a claim ("Audited my own server's tools.py last week and realized every description field was an unmonitored attack surface I'd never thought about") that required a truthfulness-floor audit before posting.

Self-audit results — pyobfus-mcp 0.1.2 against 10 security categories (full table in memory mcp_security_audit_baseline.md): - ❌ 3 real gaps: filesystem scope (3/5 tools accept arbitrary paths) · rate limiting (none) · audit logging (none) - ⚠️ 2 partial gaps: input validation (only target.exists()) · per-tool authorization (no FastMCP 3.0 versioning yet) - ✅ 5 safe: hardcoded secrets (safe by design — no external API auth) · tool description injection (descriptions are clean) · stdio transport (acceptable for local model) · token persistence (N/A) · dependency confusion (N/A)

N2 scope expansion (ff71144): - Session 17 evening N2 v2: FastMCP 3.0 + Pro funnel · 3-4 days · 10 numbered actions - Session 18 evening N2 v3: + security hardening · 4-5 days · 13 numbered actions - 3 new actions: path scoping (closes audit gap #2) · token-bucket rate limiting (closes #3) · JSON-line audit logging with redaction (closes #5). Per-tool auth (closes #7) was already in baseline. - Done-when expanded: "fresh run of Atlas Whoff's MCP Security Scanner shows 5/5 green for pyobfus-mcp 0.2.0". Makes our launch-wave exposure window safe even if his scanner targets us during the HN/Reddit traffic boost.

Backlog superseded from Session 17: - ~~"4-platform launch leg unblocked but not started; still needs human-voice rewrite + GPTZero gate"~~ → dev.to LIVE; CN/HN/Reddit calendar locked

Net session deliverables: - 8 commits on main (8ec0fcd + a3da282 + 4f8886f + ca12e25 + ec5fc65 + 2dd313a + 94aab92 + ff71144) - 1 published article (dev.to first post) - 1 substantive community comment (Atlas Whoff's article) - 2 new persistent memory entries: mcp_publisher_auth.md + mcp_security_audit_baseline.md - N2 v0.5 scope expanded with security-hardening track

Remaining backlog (genuinely not blocking): - punkpeye PR #5777 human merge — passive - Glama "No recent usage" / "No related servers" — time-based - HN / Reddit / CN posts — calendar-locked for next 5 days - N2 implementation work — pyobfus-mcp 0.2.0 build queued for Week 3 (5-19 → 5-25) - N1 (PEP 750 t-string) + N3 (claude-skill preset) — Week 2-3 parallel

2026-05-08 — Session 19 (early morning): N2 Phase 1-4 shipped · pyobfus-mcp 0.2.0 LIVE¶

Context: Session 18 closed with N2 scope expanded to a 3-way bundle (FastMCP 1.27 baseline + Pro funnel + security hardening) targeted at Week 3. Session 19 executed the entire N2 plan in a single push — 4 ordered phases, each gated by full CI cross-platform validation before the next phase started. End state: pyobfus-mcp 0.2.0 LIVE on PyPI + MCP Registry; the deferred P0.3 _meta block included in the publish; one new finding for the next bump.

Phase sequence executed (each commit + CI green-gated before the next):

Phase	Commit	Tests	CI matrix	Notable
1 — Security baseline (path scope + rate limit + audit log)	`fa4094a`	36 (16 + 20 new)	24/24 ✅	Closes audit gaps #2/#3/#5
Doc plan correction	`11267cc`	—	—	Inspected actual `mcp 1.27` API → revealed FastMCP 3.0 framing was overstated; corrected N2 plan
2 — FastMCP 1.27 baseline + tier gating + soft OTel	`b868618`	45 (+9)	24/24 ✅	`meta=` SDK-native carrier; `secure_tool` tier-gating layer; OTel soft-import
3 — Pro funnel via MCP	`0cd629c` (replaced `9ec05ff`)	55 (+10)	24/24 ✅	First commit `9ec05ff` blocked by GitHub Push Protection — fake Stripe-shaped fixture strings — reshaped fixtures to trigger only our generic 40+ char detector, not the Stripe-key one (the irony: our own pattern #2 caught the test fixtures)
Version bump	`3f74f91`	55	24/24 ✅	0.1.2 → 0.2.0 in pyproject.toml + server.json + init.py + CHANGELOG entry
4 — Ship 0.2.0 to PyPI	tag `mcp-v0.2.0` → `release.yml` run 25508631049	—	—	OIDC trusted publishing first real exercise. Worked first try — sigstore attestations live at https://pypi.org/integrity/pyobfus-mcp/0.2.0/...whl/provenance. PyPI page shows `pyobfus-mcp-0.2.0-py3-none-any.whl` (21,632 B) + `tar.gz` (29,601 B) at 2026-05-07T16:28 UTC
4 — Ship 0.2.0 to MCP Registry	`mcp-publisher publish`	—	—	Token expired per the 80-min rule; auto-refresh via `gh auth token` workaround documented in `mcp_publisher_auth.md` worked first try (memory's first real reuse). Registry response: `version: 0.2.0`, `active`, `isLatest: true`

One unexpected finding (queued, not blocking): - Registry server-side validator silently stripped our publisher-claimed _meta.io.github.zhurong2020.pyobfus_mcp block. Server response shows "_meta": {} on the 0.2.0 entry. Hypothesis: Registry only accepts publisher-claimed _meta keys that exactly match the verified namespace prefix io.github.zhurong2020 (no suffix). Schema URL https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json declares _meta: {} (no constraint), so the rule lives in Registry runtime. Plan: try bare namespace io.github.zhurong2020 on next bump (0.2.1 or 0.3.0). Captured in companion memory mcp_registry_meta_namespace.md. Same-version re-publish is rejected, so 0.2.0 cannot be retroactively fixed.

Net session deliverables (commits): 1. fa4094a — Phase 1 security baseline 2. 11267cc — N2 plan correction 3. b868618 — Phase 2 FastMCP 1.27 + tier gating + OTel 4. 0cd629c — Phase 3 Pro funnel via MCP 5. 3f74f91 — Phase 4 version bump 6. tag mcp-v0.2.0 → release.yml job → PyPI publish 7. (this Session 19 doc commit, pending)

Plus 2 new persistent memory entries (mcp_security_audit_baseline.md carried over from Session 18; mcp_registry_meta_namespace.md new today).

N2 completion status: ✅ All 13 numbered actions from the corrected N2 scope shipped: - Actions 1-4 (FastMCP 1.27 baseline + per-tool auth + OTel) - Actions 5-9 (Pro funnel via MCP — pro_value field, pro_unlock field, recommend_tier, start_pro_trial, tier_context) - Actions 10-12 (Path scoping + rate limiting + audit logging — Phase 1) - Action 13 (Ship 0.2.0 to PyPI + Registry)

Audit gap closure status (from 2026-05-07 self-audit): - ❌ #2 filesystem scope → ✅ closed (Phase 1, validate_path() + PYOBFUS_MCP_PROJECT_ROOT env var) - ❌ #3 rate limiting → ✅ closed (Phase 1, token bucket + PYOBFUS_MCP_RATE_LIMIT_PER_MIN) - ❌ #5 audit logging → ✅ closed (Phase 1, JSON-line per call) - ⚠️ #1 input validation → ✅ closed transitively (covered by Phase 1 path-scope format checks) - ⚠️ #7 per-tool authorization → ✅ closed (Phase 2, secure_tool decorator + PYOBFUS_MCP_DISABLED_TOOLS)

Remaining backlog after Session 19: - punkpeye PR #5777 — passive wait - Glama "No recent usage" — time-based - HN / Reddit / CN posts — calendar-locked Mon-Tue 5-11/12 + this weekend 5-8/9 - Registry _meta namespace fix — queued for next pyobfus-mcp version bump - N1 (PEP 750 t-string handler) + N3 (claude-skill preset) — Week 2-3 parallel

2026-05-08 — Session 20 (morning + evening): launch-wave instrumentation · tech-deai skill build · CN trio ready · awesome-list diversification¶

Context: Session 19 closed N2 (pyobfus-mcp 0.2.0 ship). Session 20 is cross-cutting tooling + launch-wave prep, not pyobfus-internal feature work. Two parallel tracks: (a) the v3→v4 dev.to-article rewrite methodology distilled into a reusable Claude Code skill, (b) CN trio of the 5/8-5/9 launch-wave window prepared as ready-to-post files using that skill (Phase 0 Run 1 of the skill's own validation plan), (c) two additional awesome-mcp-server diversification submissions to hedge against punkpeye PR #5777 merge latency.

Track A — tech-deai Claude Code skill v1.0.0 shipped (cross-project, lives at ~/.claude/skills/tech-deai/, not in this repo):

File	Lines	Notes
`SKILL.md`	344	YAML frontmatter + 4-step workflow + 12 HIGH AI patterns + 10 LOW AI patterns + per-platform tuning + decision tree + burstiness measurement
`README.md`	120	Install / per-platform cheatsheet / comparison vs companion `academic-deai`
`WARP.md`	88	WARP.dev compatibility
`prompts/{devto,hn_strict,reddit,cn_platforms}_workflow.md`	99–117 each	Drop-in platform workflows
`LICENSE`	21	MIT (skill phase)
`BACKLOG.md`	—	Phase 0/1/2 plan + cold-start trigger + commercial MCP decision gate
`RUN_LOG.md`	—	Phase 0 Run 1 logged today (this session, see Track B)

Skill auto-surfaces in any Claude Code session that involves writing/revising technical prose. Distilled from _drafts/de-ai-methodology.md (commit 67c8b52); origin doc now footer-pointed to the skill location.

Track B — tech-deai-loop placeholder repo created at https://github.com/zhurong2020/tech-deai-loop: name + namespace reservation for a future commercial MCP server. README + ROADMAP + TODO + LICENSE + .gitignore only, 0 implementation. Visibility flipped public → private later same day after recognizing the BACKLOG/TODO/ROADMAP content leaks commercial strategy (Phase 2 prerequisites · pricing ceilings · competitor moat analysis vs HumanizerMCP/Text2Go) for zero community benefit (no code yet). License plan: placeholder MIT, v0.1.0 locked to Apache-2.0 (matches pyobfus precedent + adds patent grant). Decoupled from this repo on purpose: skills are user-scoped configs, commercial MCP needs its own GitHub stars / PyPI / Glama / npm trajectory.

Track C — Phase 0 Run 1: CN trio prepared as ready-to-post files (_drafts/post-cn-ready/):

File	Words	Voice	Target post date
`tech_empowerment.md`	~1480 字	有心工坊 / 科普 tone with `<!-- more -->` cut + 2 screenshot placeholders	2026-05-08 (Fri)
`zhihu.md`	~1280 字	第一人称 hook + 末段邀评论 + tags `#Python #开源项目 #人工智能 #编程`	2026-05-09 (Sat, ≥24h gap)
`v2ex.md`	~700 字	`[分享创造]` prefix + list-style + brief origin story	2026-05-10 (Sun, ≥24h gap)
`README.md`	—	Index + per-platform differences + pre-publish checklist + rewrite log

8 HIGH-AI patterns surgically fixed across the trio (4 em-dashes + "整个版本" framings + "那座桥" metaphor + "代价不是不存在...桥接...显形" poeticism + "最直接的方案当然是" of-course translation residue). All LOW-AI signals preserved verbatim (specific dates/versions, named errors, first-person + short sentences, self-honesty paragraphs, network slang). Burstiness check (UTF-8 byte-length proxy on 。-split sentences, code blocks/lists/headings stripped):

File	min	max	mean	stddev	n	range
`post-cn-bilingual.md` (source)	1	177	16	20	228	176
`tech_empowerment.md`	1	177	17	21	158	176
`zhihu.md`	1	121	14	15	162	120
`v2ex.md`	1	136	21	28	35	135

Range ≥ 100 in all 3 ready files (target met per tech-deai/SKILL.md rule of thumb). Surgical-edit hypothesis confirmed: source range (176) preserved on tech_empowerment.md — we did not chop into the long-sentence reservoir, only fixed AI patterns within average-length sentences. Detector data not collected this run (no GPTZero account; CN platforms don't enforce AI policy + Chinese detectors less mature in 2026); pattern-table-driven only. Honest limitation, not failure.

Track D — awesome-mcp-server diversification (Phase 2 Pre-prerequisite of skill BACKLOG):

✅ wong2 SUBMITTED via mcpservers.org/submit form. Site responded pyobfus-mcp submitted successfully. You'll receive an email once your submission is approved. Watch zhurong0525@gmail.com inbox; follow up via mcpservers.org contact link if no reply in 7 days.
❌ appcypher DEAD-END — owner disabled both PRs (verified by browser-side error message "An owner of this repository has disabled the ability to open pull requests.") and Issues (verified by gh api repos/appcypher/awesome-mcp-servers --jq '.has_issues' → false). Repository in read-only museum mode despite stale CONTRIBUTING.md. Fork zhurong2020/awesome-mcp-servers-appcypher with branch add-pyobfus-mcp retained at zero cost; re-fork is 1 click if owner reopens.
🟡 punkpeye PR #5777 still OPEN — all bot labels green (has-emoji/has-glama/valid-name); 13h-old self status update referencing Glama Quality A still un-acked by maintainer. Section N5 of POST_V0.4_TODO.md closed at 2 active distribution channels (punkpeye + wong2) instead of original 3.

Investigation lesson (captured in N5): when gh pr list --state all returns empty [] on a multi-K-star awesome-list, suspect "PRs disabled" not "no PRs"; verify with gh api repos/<owner>/<repo> --jq .has_issues BEFORE investing fork+commit time. Cost this session: ~20 min wasted on appcypher fork+push that turned out to be unsubmittable.

Net session deliverables (commits, this repo only): 1. a52eb2f — docs(POST_V0.4_TODO): N5 awesome-list diversification in flight + #5777 status snapshot 2. 6a98413 — docs(POST_V0.4_TODO): N5 closed · wong2 ✅ submitted · appcypher ❌ dead-end (PRs+issues disabled) 3. c9fcbf5 — docs(_drafts): CN trio ready-to-post (有心工坊/知乎/V2EX) · tech-deai cn_platforms applied 4. (this Session 20 doc commit, pending)

Plus cross-project commits (not in this repo): - ~/.claude/skills/tech-deai (local-only repo): cdfb6da init + 7c0aa8c BACKLOG + 4752ee4 private/Apache pivot + 0670004 RUN_LOG Run 1 - zhurong2020/tech-deai-loop (private, public main): 81fcc64 init + 9adfe31 private/Apache pivot

Plus 1 cross-project memory entry (~/.claude/projects/-home-wuxia-projects-llm-enrichment/memory/tech-deai-skill-roadmap.md) so any future session in any project surfaces tech-deai state.

dev.to article 19h-feedback snapshot (canonical EN article live since Session 18 evening): - 🏆 Writing Debut badge earned (dev.to algorithm marker for active writer; tag-follower push volume increases post-badge) - 👍 1 reaction (Abe Wheeler, real developer) - 💬 0 comments (typical for new author on dev.to in first 24h) - 🚫 0 mod warnings / 0 flag / 0 AI-policy investigation ← KEY POSITIVE SIGNAL: the v4 GPTZero-diagnostic rewrite passed dev.to's invisible AI-policy radar. The whole point of the rewrite (and now the tech-deai skill) is validated by this null finding.

Phase 0 progress (skill validation plan): 1 of ≥3 runs complete after Session 20. Run 2 = HN Show HN 2026-05-11 evening. Run 3 = Reddit /r/Python 2026-05-12 evening. After Run 3 + skill v1.1.0 + (#5777 merged OR 14d wait), Phase 2 cold-start gate opens for tech-deai-loop v0.1.0 implementation.

Skill v1.1.0 candidate change (from Run 1 findings): tag「A——B 结构性破折号」as #1 CN HIGH-AI lever in prompts/cn_platforms.md (4 of 8 Run 1 fixes were em-dashes; CN em-dash even more AI-shaped than EN since native CN tech prose uses 句号/逗号/括号 instead of dashes). Recorded in BACKLOG decision log; will be applied alongside Run 2/3 findings in next skill version bump.

Remaining backlog after Session 20: - punkpeye PR #5777 — passive wait (5+ days OPEN) - wong2 mcpservers.org approval email — passive wait (≤7 days expected) - HN / Reddit posts — calendar-locked Mon-Tue 5-11/12 + this weekend's CN trio - Phase 0 Runs 2 + 3 (HN + Reddit) — locked to launch-wave dates - dev.to 7d / 24h / 48h reaction metrics — append to Metrics Snapshot table at each interval - Registry _meta namespace fix — queued for next pyobfus-mcp version bump (carried from Session 19) - N1 (PEP 750 t-string handler) + N3 (claude-skill preset) — Week 2-3 parallel (carried from earlier)

2026-05-08 — Session 21 (later evening): mcpservers.org same-day approval · N5 fully closed¶

Context: Session 20 evening submitted pyobfus-mcp to wong2's mcpservers.org form (the form-driven channel since wong2's repo redirects there) and queued the approval email as passive-wait (≤7 days SLA expected). The approval landed same day — measurably faster than the SLA — closing N5 ahead of schedule and giving the launch wave (HN 5-11 / Reddit 5-12) a second non-PR-gated awesome-list landing target alongside the still-OPEN punkpeye #5777.

Inputs (1 trigger, 0 actions on our side): - Email from contact@mcpservers.org to zhurong0525@gmail.com: "🎉 Your MCP Server has been approved! Dear Developer, Great news! Your MCP Server submission has been approved and is now live on mcpservers.org: pyobfus-mcp · View your server →". Sponsorship pitch attached but not actioned (see do-not-do reasoning below).

Verification: - WebFetch https://mcpservers.org/servers/zhurong2020/pyobfus returns full listing with title, description, 5-tool count, dual-license note, integration list (Claude Desktop / Claude Code / Cursor / Windsurf / Zed), pip install pyobfus-mcp command. URL slug normalizes to GitHub repo name (/pyobfus, not /pyobfus-mcp) — useful to know for future cold-start agents trying to verify the listing. - 3 alternate slug guesses (/servers/zhurong2020/pyobfus-mcp, /servers/pyobfus-mcp, /server/pyobfus-mcp) all 404. Homepage search also returned no hit — likely homepage cache lag, not a propagation problem (direct URL resolves cleanly).

Decisions: - Skip mcpservers.org sponsorship offer for now. Pre-launch + 0 GitHub stars + unproven Stripe signal = irrational marketing spend timing. Revisit only if (a) post-launch PyPI MoM ≥ +50% AND (b) sponsorship pricing publicly disclosed AND (c) MCP-driven Stripe checkout signal exists. - Do not bump pyobfus-mcp to refresh listing metadata. The approved listing already reflects v0.2.0 published this morning; if a future version's metadata surfaces a content change worth pushing, mcpservers.org pulls from PyPI/Registry passively (verified in the listing's freshness — already shows the post-N2 description).

Outputs: - docs/POST_V0.4_TODO.md N5 status section rewritten: wong2 SUBMITTED → wong2 APPROVED + LIVE with URL + sponsorship-skip reasoning. Header Last updated and final-block status both updated. - This session log entry. - Metrics Snapshot table appended below.

Backlog after Session 21: - punkpeye PR #5777 — passive wait (5+ days OPEN, all bot gates green) - HN Show HN — locked Mon 5-11 evening · Phase 0 Run 2 of tech-deai skill validation - Reddit /r/Python — locked Tue 5-12 evening · Phase 0 Run 3 of tech-deai skill validation - CN trio — locked Fri-Sat 5-8/5-9 (this weekend, ready-to-post files prepared via Run 1) - dev.to 24h / 48h / 7d reaction metrics — append to Metrics Snapshot table at each interval - Registry _meta namespace fix — queued for next pyobfus-mcp version bump (carried from Session 19) - N1 (PEP 750 t-string handler) + N3 (claude-skill preset) — Week 2-3 parallel (carried from earlier)

2026-05-08 — Session 22 (later evening): Path A v5 honest rewrite + N6 PyPI SEO staging + competitive scan¶

Context: User noticed during a CN draft re-read that the Section 1 PyArmor adoption + I0/I2 traceback + 40-min unmap anecdote was being repeated faithfully across 5 drafts (EN article + CN trio + cn-bilingual design log + HN seed comment + Reddit disclosure paragraph), and confirmed the entire anecdote was fabricated narrative texture — maintainer never installed PyArmor; concluded against it after researching the docs + Pro pricing. The actual story: "researched PyArmor → saw key features in paid Pro → decided to vibe-code a smaller one with Claude Code → that evolved into pyobfus 0.4.0 over a month of evenings."

This is a 4-day-pre-launch integrity event (HN Mon 5-11 / Reddit Tue 5-12 / CN trio this weekend). HN/Reddit comment culture would predictably ask for the original traceback or the collaborator's name — neither exists. Path A (rewrite all 5 drafts on the honest history) chosen over Path B (live with stale dev.to + write CN/HN/Reddit honestly · creates cross-platform inconsistency) and Path C (accept risk).

Inputs (3 trigger threads, all interleaved this session): - User correction on actual project history (lines: "经过调研，pyarmor需要付费，所以我想利用claude code的vibe coding自己做一个小型的混淆加密工具") - User observation that pyobfus didn't appear on page 1 of PyPI relevance-sorted "pyarmor" search → metadata SEO staging (N6) - User observation that PyPI date-sorted "pyarmor" search showed 3 unfamiliar packages (vmp-protector / manifestguard / smelt) → competitive scan agent

Outputs (5 commits, all PII-clean, all pushed to origin/main): 1. pyproject(both): stage PyArmor SEO copy for next bumps (N6) — 2a6a299 2. docs(POST_V0.4_TODO): N6 PyPI search SEO + pyarmor.cli not-a-competitor note — b466f36 3. docs(article-01): Section 1 v5 honest rewrite (Path A · removes I0/I2 fabrication) — 0025262 4. docs(_drafts): align CN trio + design log with article-01 v5 (Path A) — e2c7825 5. docs(_drafts): align HN + Reddit drafts with article-01 v5 (Path A) — 7ddf150 6. docs(POST_V0.4_TODO): vmp-protector verified-facts row + 2 search false positives — 0ce9575 7. (this Session 22 doc commit, pending)

Key decisions logged: - Honest framing of v5: AI-debug differentiator preserved unchanged (the insight is real, just reached by reasoning not by experiment). The shift is "tried it and got burned" → "thought it through and didn't try it." This is more truthful AND more in line with the 2026 vibe-coding zeitgeist. - N6 staging mode: PyPI metadata edits do NOT trigger version bumps. Same staging pattern as P0.3 _meta block — wait for next legitimate bump (N1 t-string handler / N3 claude-skill preset / next bug fix) and ship together. - vmp-protector positioning rule: do NOT add vmp-protector to pyobfus's "PyArmor alternative" framing. Anonymous (no author / no repo) + 1 release + 6 days old = unverifiable provenance. Lumping it in would lend it free credibility. - Live dev.to post: still on v4 fabrication. v5 Section 1 sits in the canonical EN draft awaiting maintainer manual paste into dev.to editor (cannot push to dev.to from this repo). Reactions / Writing Debut badge / URL all preserved through edit. This is the only Path A piece not yet propagated to a live surface.

Backlog after Session 22: - punkpeye PR #5777 — passive wait (5+ days OPEN, all bot gates green) - HN Show HN — locked Mon 5-11 evening · v2 honest seed comment ready - Reddit /r/Python — locked Tue 5-12 evening · v2 honest disclosure paragraph ready - CN trio — locked Fri-Sat 5-8/5-9 (this weekend) · all 3 v2 honest rewrites ready-to-post - dev.to manual edit — maintainer to paste v5 Section 1 into the dev.to editor at convenience (only Path A surface still on v4) - dev.to 24h / 48h / 7d reaction metrics — append to Metrics Snapshot table at each interval - Registry _meta namespace fix — queued for next pyobfus-mcp version bump - N1 (PEP 750 t-string handler) + N3 (claude-skill preset) — Week 2-3 parallel - N6 PyPI SEO — staged in source, ships with next pyobfus / pyobfus-mcp version bump

2026-05-09 — Session 23: P0.6 supply-chain hardening + OpenSSF passing + ChatGPT validation + N10 + workspace baseline¶

Context: Session 22 closed Path A v5 honest rewrite for the launch wave. Session 23 is post-launch-prep + meta-strategy, working four parallel tracks: (a) P0.6 Socket supply-chain score push — SHA-pinning all GitHub Actions, adding CodeQL workflow, modernizing SECURITY.md, achieving OpenSSF Best Practices passing badge (project 12788, 67/67 criteria); (b) PyArmor 9.2.4 trial-limit empirical data (935-940 lines per single file, parallel session measured + documented in docs/PYARMOR_TRIAL_LIMIT_EXPERIMENT.md) wired into landing-page + comparison-doc + HN/Reddit drafts; (c) ChatGPT incognito validation surfaced pyobfus as #1 recommendation for AI-friendly Python obfuscation, exposing 4 refinement gaps captured as N10; (d) workspace-wide engineering baseline distilled from the OpenSSF passing exercise into ~/projects/ENGINEERING_BASELINE.md + pyobfus/templates/python-baseline/ (bootstrap.sh + pre-commit.template + SECURITY.md.template).

Inputs (6 trigger threads, all interleaved this session): - User asked for SEO + commercial-loop + channel-publication strategy review (Google "python obfuscator" SERP audit + Socket.dev category misclassification + GitHub code-obfuscator topic) - Parallel session created docs/PYARMOR_TRIAL_LIMIT_EXPERIMENT.md with 935-940 line empirical measurement - User shared ChatGPT incognito query result (pyobfus as "首选候选" for AI-friendly Python obfuscation) - User walked through full OpenSSF Best Practices badge application (67 questions answered live with maintainer) - Post-push CodeQL first-run produced 7 expected false positives in examples/ + tests/ - User wrapping-up question prompted workspace-wide engineering baseline doc (ENGINEERING_BASELINE.md) and cardiac-shared cold-start prompt

Outputs (8 commits, all PII-clean, all pushed to origin/main): 1. chore(security): P0.6 supply-chain hardening (OpenSSF passing + CodeQL + SHA-pin) — eb634ab 2. docs(comparison,drafts): wire 935-940 PyArmor trial-limit empirical data — fe6c208 3. docs(POST_V0.4_TODO): mark P0.6 done · add P0.5/P0.7 + N7/N8/N9 + pricing guardrail — 15026f8 4. docs(comparison,readme): add layered deployment strategy framing — 72ff5fb 5. docs(POST_V0.4_TODO): add N10 — ChatGPT-validation-derived 4-bundle — 4c0e30f 6. chore(security): CodeQL path-ignore config (silence 7 expected false positives) — 3ba1c35 7. docs(templates): add python-baseline scaffolding for new-project bootstrap — d246890 8. (this Session 23 doc commit, pending)

Key decisions logged: - OpenSSF passing badge achieved (project 12788 · 67/67 criteria · same tier as Kubernetes/Curl/etcd) — first concrete third-party project-maturity credential. Badge in README; cross-referenced in awesome-mcp-servers PR #5777 description (silent edit, no comment). - Single-tier $45 pricing rule (memory pricing_strategy.md) — User pushed back on a Solo/Team/Enterprise tier proposal; added permanent guardrail in POST_V0.4_TODO do-not-do list. ARPU lift path is Stripe quantity field on the same SKU (N9), NOT tier expansion. MRR path (if ever needed) is a separate product, never a Pro sub-tier. - PyArmor 9.2.4 empirical limit cross-surface deployment — 935-940 line per-file threshold (line count, not bytes) verified 2026-05-09 in clean venv against PyArmor 9.2.4 trial. ChatGPT cited PyArmor's official 32 KB code-object limit; 940 × ~32 bytes/line ≈ 30 KB independently corroborates. Wired into COMPARISON.md, HN/Reddit additive sections, POST_V0.4_TODO Verified facts, memory file. Defensive framing rules captured (always cite "PyArmor 9.2.4" + "verified 2026-05-09" + link to reproducible methodology + first-person hedges). - Layered deployment honest framing — pyobfus as always-on default + PyArmor/Nuitka opt-in for crown-jewel modules. Counterintuitive marketing but high-trust on HN/Reddit. ChatGPT independently recommended same stack — indirect external validation. Added to COMPARISON.md (new "Layered Deployment Strategy" section) + README FAQ. - CodeQL path-ignore config — examples/** + **/tests/** excluded from security-extended scan. Standard OSS practice. Examples intentionally demonstrate clear-text-credential anti-patterns (motivates AES-256 string encryption); test substring URL assertions are not security decisions. The 7 first-run alerts auto-close on next scan. - Workspace-wide engineering baseline — Tier 0 (universal) / Tier 1 (public OSS) / Tier 2 (security-critical) distilled into ~/projects/ENGINEERING_BASELINE.md (workspace-local · ~150 lines) + brief section added to ~/.claude/CLAUDE.md. pyobfus/templates/python-baseline/ holds copyable baseline files (bootstrap.sh + pre-commit.template + SECURITY.md.template + README). Future projects (cardiac-shared next) bootstrap with one curl command.

Memory writes (3 new + 1 updated): - memory/pricing_strategy.md — single-tier $45 strategic guardrail (anti-tier proposal rule) - memory/pyarmor_trial_limit_2026-05-09.md — empirical 935-940 line data + cross-surface deployment map + defensive framing rules - memory/patent_software_copyright_sync_2026-05-09.md — 3 carry-back items for parallel patent/软著 session (OpenSSF maturity evidence · PYARMOR 32 KB cross-ref for prior-art · layered deployment for 工业应用 section) - memory/MEMORY.md — index updated for above 3

Cross-session deliverables (this session → another session): - awesome-mcp-servers PR #5777 description silent-refreshed (5 stale facts updated: 5→7 tools / 0.1.1→0.2.0 PyPI / 0.1.1→0.2.0 Registry / 16→75 tests / + OpenSSF + Glama + mcpservers.org references) - cardiac-shared cold-start prompt drafted in closing exchange and used by maintainer to launch parallel cardiac-shared baseline-uplift session in another window

Backlog after Session 23: - punkpeye PR #5777 — passive wait (description silent-refreshed; bot checks all green; ~7 days OPEN) - Socket re-scan — verify ≥ 90 supply-chain score on both packages within 24-48h auto-cron (or manual refresh) - CodeQL re-run — verify 7 first-run alerts auto-close after path-ignore config takes effect - HN Show HN — locked Mon 5-11 evening (v2 honest seed comment + Session 23 PyArmor-trial-limit additive section ready) - Reddit /r/Python — locked Tue 5-12 evening (v2 honest disclosure + additive trial-limit section ready) - CN trio — locked Fri-Sat 5-8/5-9 (this weekend; parallel session) - P0.7 Discussions roadmap-signal poll — locked Wed 5-13 (post-launch wave; feeds Week-4 N7/N8/N9 prioritization) - N1 (PEP 750 t-string handler) — Week 2-3 · bundles N6 + N10-1 (Beta → Production/Stable) + N10-2 (README 5→7 tools) metadata refresh - N7 (pyobfus.dev demo) + N8 (5-6 SEO landing pages) — Week 4-5 (gated on launch signal) - N9 (Stripe quantity field + recommend_tier seat-aware) — Week 4 (half day) - N3 (claude-skill preset) — Week 5+ · net-new market segment - N10-3 PYARMOR 32 KB cross-reference in docs/PYARMOR_TRIAL_LIMIT_EXPERIMENT.md — coordinate with parallel session that owns the experiment doc - N10-4 HN seed comment + landing page reflect three-layer framing — when those move - cardiac-shared baseline uplift — parallel session in progress (started in another window after Session 23 closing exchange) - dev.to v5 Section 1 manual paste — still pending from Session 22 backlog (only Path A surface still on v4) - v0.5.0 RC by 2026-06-15 (Core: P2-1 + P2-3 + P2-4 + P2-5 + N1 + N3 + drop-3.8; demo: N7; SEO: N8; pricing: N9)

2026-05-09 — Session 24 (parallel to Session 23): CCPC software copyright file prep + patent strategy lock + Session 23 sync ingestion¶

Context: Session 24 ran in parallel to Session 23 (different chat window, both 2026-05-09). Trigger: maintainer noted CCPC 实名认证 approval (the long-standing blocker for #1 in memory/blocking_external_reviews.md). Session scope: (a) verify what was missing for CCPC software copyright submission, (b) align file structure with the precedent set by S1 cardiac-shared filing (which had a first-submit rejection on 发表状态 mismatch — lesson already incorporated in pyobfus materials), (c) decide pyobfus's patent path now that the software copyright leg is unblocked, (d) ingest Session 23's 3 cross-cutting sync points (OpenSSF passing badge / PYARMOR 32 KB cross-ref / layered-deployment framing) into the patent-strategy planning docs.

Inputs (3 trigger threads): - User reported CCPC 实名认证 approved → unblocks software copyright filing - User pointed at ~/projects/cardiac-ml-research/docs/legal/S_软著/S1_cardiac_shared/ as reference precedent (S1 was filed individually + auto-rejected once on 发表状态; second submission accepted) - Session 23 maintainer separately handed over 3 sync points via memory/patent_software_copyright_sync_2026-05-09.md

Outputs (all in off-repo ~/3-job/program/pyobfus-legal/software_copyright/ per long-standing PII separation rule, plus 2 in-repo doc commits):

Off-repo (filing materials, never under git): 1. pyobfus_software_description.md — merged short version (R11 cheat sheet, 100-char tech features, 500-1300 char main functions) + full version (chapters 一~十三) into single 746-line file, mirroring S1's monolithic upload structure. Fixed two pre-existing inline issues found during structural diff: pinyin transliteration hunyao → hunxiao (混淆 = hùnxiáo) and missing Flask in 100-char framework-presets list (the prose said "6 套" but the list only had 5). 2. pyobfus_software_description.pdf — regenerated 20 pages via ~/projects/cardiac-ml-research/scripts/md_to_pdf_chinese.py (weasyprint + SimSun/SimHei fonts, same toolchain S1 used). Replaces the previous 17-page PDF that was generated from the unmerged short version. 3. pyobfus_software_description_full.md — deleted (content fully absorbed into the merged file; per maintainer "合并后删除 _full.md，只留合并版" decision). 4. README.md (file inventory + §九 todo state + new §十 CCPC web-portal operation cheat sheet) — file inventory updated to reflect single-doc structure; §九 marked CCPC auth + file merge as done; §十 added 7-step submission cheat sheet (Login → Choose business type → Fill 26-field form → Upload 3 PDFs → Generate signed PDF → Pay 290元 → Wait ~30 working days) plus 5 common rejection reasons cross-referenced with S1 first-submit failure (发表状态 mismatch · 首次发表日期校验 · 源代码 PDF 敏感信息 · 说明书 < 10 页 · 截图含主机名). 5. Sync point 1 ingestion — added "第三方质量认证 | OpenSSF Best Practices passing badge (project ID 12788, 2026-05-09 通过 67/67)" line to §13.1 当前版本信息 table. Project-level evidence; phrased to not conflict with V0.4.0's release date.

In-repo (this session): 6. docs(POST_V0.4_TODO): add CCPC 软著 e-certificate as P2 passive item — references off-repo cheat sheet; ETA ~30 working days from submission. 7. (this Session 24 doc commit, pending)

Key decisions logged: - Single-doc consolidated说明书 over split short/long structure — split was operationally awkward; S1's single-file pattern is cleaner for CCPC upload +审查 review. Trade-off accepted: 32 KB single file vs the previous 8 KB + 25 KB split. - Patent strategy locked at single broad combination claim (per memory/pyobfus_patent_strategy.md for full reasoning; high-level summary only here per repo PII discipline): one invention-patent application covering the combination of reverse-mapping architecture (Core) and multi-layer protection (Pro internals) as the inventive step, NOT 2-3 narrower patents. Pro se filing via 国知局电子申请系统 with 85% personal-applicant fee reduction. CN-only — pyobfus V0.4.0's 2026-04-22 PyPI release exhausts CN novelty for already-disclosed Core (CN §24 grace period does not cover self-publishing on PyPI), but Pro internals remain patentable. USPTO parallel filing rejected on cost (~$10k for personal applicant). - Sync point 2 (PYARMOR 32 KB cross-ref) carried into patent strategy memory for future 交底书 prior-art section. Two independent measurement methodologies (Session 23's 935-940-line empirical + ChatGPT-cited PyArmor official 32 KB code-object docs) converging is a strong inventive-step argument; will be cited when 交底书 drafting starts. - Sync point 3 (layered-deployment framing) carried into patent strategy memory to reframe inventive-step argument from "we obfuscate harder" to "we enable a new workflow (AI-assisted debugging of obfuscated production code)". Independently corroborated by ChatGPT incognito recommendation 2026-05-09 — third-party indirect prior-art validation that this is the correct deployment pattern. - Patent file path planning — patent交底书 drafting deferred until after software copyright submission settles. Then ~3-week sequence: (1) novelty search on CN patent DB + Google Patents, (2) draft application docs with Claude assistance, (3) CPC client setup + USB key + fee-reduction request submission. Estimated end-2026-05 / early-2026-06 for first patent申请号.

Memory writes (1 created + 2 updated): - memory/pyobfus_patent_strategy.md — new file. Locks single-broad-combo patent direction; CN novelty constraint formalized; fee-reduction eligibility noted (general tier match, no income specifics in memory); coordination with spouse's separate medical-imaging patent pipeline documented as no-conflict; "Materials to fold into 交底书" section added at end during sync ingestion (covers OpenSSF maturity evidence + PYARMOR 32 KB cross-ref + three-layer reframing). - memory/blocking_external_reviews.md — refreshed. CCPC entry: Status 2026-05-09: ✅ Real-name auth APPROVED. File prep ALSO complete (this session). Glama entry: No longer blocking — Glama Quality A confirmed 2026-05-08. - memory/MEMORY.md — index entries updated for above 2 (one bullet rewritten, one new line added).

Cross-session deliverables: - None this session — Session 23 → Session 24 sync was one-way (Session 24 received from Session 23 via the sync memory). No reciprocal hand-back required; the cardiac-shared baseline-uplift parallel session mentioned in Session 23 backlog was unaffected by this session's scope.

Backlog after Session 24: - CCPC 软著 portal submission — maintainer-actionable; ~30 min by following ../pyobfus-legal/software_copyright/README.md §十 cheat sheet - CCPC 软著 e-certificate — passive P2 (now in POST_V0.4_TODO P2 table); ~30 working days from submission - 个人所得税完税证明 prep — maintainer-actionable for fee-reduction proof when patent application is filed (general policy verification, no specifics in repo) - CPC 客户端 + 电子申请用户注册 + USB Key 邮寄 — 1-2 weeks lead time when patent path opens (sequenced AFTER software copyright settles) - Patent 交底书 first draft — Claude-assisted; deferred until software copyright submission cleared (avoids context-switch cost). When started, see memory/pyobfus_patent_strategy.md "Materials to fold into 交底书 when drafting begins" section as the structured intake.

2026-05-09 (evening) — Session 25: pyobfus_pro/ public-disclosure audit + Path C patent pivot + JOSS sequencing¶

Context: User asked whether to file patent now (V0.4.0 scope) or wait for v0.5/v0.5.1 features. Investigation surfaced a critical finding that invalidates Session 24's patent strategy: pyobfus_pro/ source has been in the public GitHub repo + every PyPI wheel since V0.1.0 (2025-11-11). Under CN Patent Law §22, public source = prior art = no novelty. The Session-24 plan to file a "single broad combo patent on V0.4.0 Pro internals" would fail substantive examination. Session 25 pivots to Path C — develop new v0.5/v0.5.1 patentable Pro features in a private repo, file patent before public release. Same session also handles user's parallel request: integrate JOSS (Journal of Open Source Software) submission into the forward TODO.

Inputs (3 trigger threads): - User asked "should I file patent with V0.4.0 or wait for v0.5/v0.5.1?" — surfaced ROADMAP.md v0.5/v0.5.1 feature catalog as the trade-off - User recalled "JOSS requires 6 months of public history" from earlier research — verified via cardiac-manuscripts JOSS submission path doc 2026-04-27 (Repo requirement: minimum 6 months public development history) - Public-disclosure audit (git ls-tree -r + unzip -l pyobfus-0.4.0-py3-none-any.whl) revealed pyobfus_pro/ is fully public source, contradicting Session 24's "obfuscated in distributed binary" assumption

Outputs (3 commits, all PII-clean): 1. docs(memory): pyobfus_pro/ public-disclosure finding + patent strategy revised to Path C — memory writes (off-repo, listed below) 2. docs(POST_V0.4_TODO): Path C v0.5 patent gating + N11 JOSS submission + 3 P2 passive items — pending below 3. docs(V0.4_EXECUTION_LOG): Session 25 — Pro disclosure audit + Path C pivot + JOSS sequencing — this commit, pending

Key decisions logged: - V0.4.0 patent path is dead — pyobfus_pro/ source publicly disclosed since 2025-11-11 (verified via git log --reverse pyobfus_pro/__init__.py first commit hash + unzip -l pyobfus-0.4.0-py3-none-any.whl showing 14 source files). Earlier "Pro is obfuscated in binary" assumption was wrong — 商业 license restricts USE not READ; anyone can git clone or pip install + unzip and read the algorithm. Per CN Patent Law §22, all V0.4.0 Pro internals (CFF, AES string, dead_code, license_embed, anti_debug, fingerprint) are now prior art and unpatentable. - Path C lock: privatize new Pro dev workflow → develop v0.5/v0.5.1 patentable Pro features in pyobfus-pro-dev private repo → file patent before public release → only after 申请号 in hand, push v0.5 to public repo + ship to PyPI. User explicitly chose Path C over Path A (file V0.4.0 anyway, knowingly fail novelty exam — wasteful) and Path B (skip patent entirely — gives up 20-year monopoly). - 6 patentable v0.5/v0.5.1 Pro features identified per ROADMAP.md: P2-1 Selective Opacity (⭐⭐⭐⭐⭐) + P2-7 Forensic watermarking (⭐⭐⭐⭐⭐) + P2-8 License binding combo (⭐⭐⭐⭐) + P2-9 @seal_code (⭐⭐⭐⭐) + P2-10 --scrub-traceback (⭐⭐⭐⭐⭐) + P2-11 Runtime String Vault (⭐⭐⭐⭐). These become the patent application's main + dependent claims. - v0.5 ship date pushed: previously 2026-06-15 per Session 23 backlog → late July / early August 2026 per Path C (added 4-6 weeks for patent filing window). Acceptable trade-off per user. - JOSS sequencing: 6-month public-history threshold met 2026-05-12 (3 days from this session). But submission gated on patent 申请号 (~late July) so paper.md can cite "patent pending CN [申请号]" + avoid leaking v0.5 patent claim wording. Submission target 2026-Q3/Q4. Open-core compatibility with JOSS already verified by 2025-11-19 prior research (~/projects/cardiac-ml-research/docs/project/JOSS_OPEN_CORE_POLICY_RESEARCH.md) — JOSS has no policy against open-core, only requires submitted code be OSI-licensed (✅ Apache 2.0). - Existing V0.4.0 pyobfus_pro/ stays where it is — already disclosed; hiding now is security theater. Wayback Machine + PyPI download history + GitHub fork copies preserve the disclosure. Don't waste effort moving V0.4.0 source to private; just don't ADD new patentable features to the public folder.

Memory writes (1 created + 1 substantially revised + 1 index updated): - memory/pro_disclosure_finding_2026-05-09.md — NEW. Critical finding documentation. Hard facts (git log + wheel inspection) + CN §22 implication + what's still patentable + operational rule for v0.5 dev. - memory/pyobfus_patent_strategy.md — REVISED. Entire "Direction" section rewritten for Path C pivot. New "Path C operational workflow" section with 5 phases. v0.5 ship date update. 6 patentable features explicit. JOSS coordination section updated. - memory/MEMORY.md — index entry for new file + revised description for patent strategy entry.

Cross-session deliverables: none — Session 25 is self-contained pivot work.

Backlog after Session 25: - CCPC 软著 portal submission — unchanged from Session 24; maintainer-actionable - 个人所得税完税证明 prep — unchanged from Session 24 - CPC 客户端 + 电子申请用户注册 + USB Key 邮寄 — unchanged from Session 24 (now also gated for v0.5 patent path) - (NEW) Create pyobfus-pro-dev private repo — when v0.5 development starts; setup workflow per memory/pro_disclosure_finding_2026-05-09.md Phase 1 - (NEW) v0.5 Pro features (P2-1 / P2-7 / P2-8 / P2-9 / P2-10 / P2-11) implemented in private repo only — per Path C Phase 2; ~4-6 weeks; absolutely no public commits/branches/PRs/issues during this period - (NEW) Patent 交底书 drafted in parallel with v0.5 implementation — Claude-assisted; intake materials in memory/pyobfus_patent_strategy.md "Materials to fold into 交底书" section - (NEW) Patent submission via CPC — after 交底书 + 新颖性检索 + 申请文件 ready; receive 申请号 + 受理通知书 - (NEW) v0.5 public release after 申请号 in hand — copy private code to public repo; bump version; ship to PyPI; add "patent pending CN [申请号]" to README - (NEW) JOSS paper.md drafted + submitted — after v0.5 publicly available + 申请号 in hand; ~2-4 month review cycle - v0.5 RC target shifted from 2026-06-15 → late July / early August 2026 (Path C overhead)

2026-05-09 (late evening) — Session 26: 软著 submitted to CCPC + workspace integration + cac-plus-ip cross-link discovery¶

Context: After Sessions 24/25 prepared the V0.4.0 software-copyright dossier and pivoted patent strategy to Path C, this session closes the active 软著 leg (user submitted to CCPC web portal end-to-end) and improves workspace ergonomics. Also surfaced a workspace-level cross-link the previous sessions had missed: cac-plus-ip (a separate IP repo for the maintainer's medical AI project, created 2026-04-29) shares the same individual applicant + CNIPA pro-se filing path + 85% fee reduction tier as the planned pyobfus v0.5 patent, and already has 6 official CNIPA application templates pre-downloaded that pyobfus's patent filing should reuse.

Inputs (3 trigger threads): - User completed CCPC submission (290元 paid; signed application PDF 软著登记申请确认签章.pdf saved alongside the dossier files) and asked for doc sync - User asked whether sibling project cac-plus-ip is related to pyobfus and whether to link the two - User asked whether pyobfus-legal/ (sibling-to-repo dossier directory on Windows OneDrive) should be registered in the workspace for cross-project discoverability

Outputs (1 commit, all PII-clean; plus off-repo + memory writes):

Off-repo dossier files: - pyobfus-legal/software_copyright/README.md §九 todo state: 7 items now ticked through "签章 PDF downloaded"; final unticked item is just the ~30-working-day passive wait for e-cert.

Symlink + workspace integration (off-repo, host-machine setup): - ~/projects/pyobfus-legal → /mnt/c/onedrive/msft/OneDrive - MSFT/rong/3-job/program/pyobfus-legal/ (matches the pre-existing ~/projects/pyobfus symlink pattern) - ~/projects/cardiac-research.code-workspace folders list now adds entry {"name": "pyobfus-legal (软著/专利申报材料)", "path": "pyobfus-legal"}. Also gives cac-plus-ip a friendly name field (was unnamed). Net: 11-root workspace (was 10), all symlink-resolved.

In-repo doc commit (this session): - pyobfus/CLAUDE.md §跨 Workspace 关联 — replaced the placeholder "无直接关联" entry with two real cross-project rows: (1) pyobfus-legal/ as the off-repo dossier home, (2) cac-plus-ip/ as parallel CNIPA workflow + reusable template source. - docs/POST_V0.4_TODO.md — CCPC P2 row updated from "Filed via CCPC web portal after real-name auth cleared" → "✅ SUBMITTED 2026-05-09 evening (290元 paid · signed PDF archived); awaiting e-cert" - docs/V0.4_EXECUTION_LOG.md — this Session 26 entry

Key decisions logged: - cac-plus-ip ↔ pyobfus are NOT project-related but ARE workflow-related — different software domains (medical AI vs developer tool), zero IP content overlap, but share applicant + CCPC account + CNIPA path + fee-reduction tier + (eventually) one CPC USB Key. Don't merge IP repos. Don't reuse claims. DO reuse templates. Captured in new memory ip_workflow_cross_project.md. - CNIPA template reuse path locked — when pyobfus v0.5 patent filing reaches Phase 3 of Path C (~2026-Q3 per pyobfus_patent_strategy.md), copy templates from ~/projects/cac-plus-ip/02_china_发明专利/_templates_CNIPA/ (6 official .doc/.docx files: 权利要求书 / 说明书 / 附图 / 摘要 / 补正书 / 费用减缴请求书) instead of re-downloading from CNIPA site. - pyobfus-legal/ workspace integration via symlink — symlink approach (matching pre-existing ~/projects/pyobfus symlink) chosen over absolute Windows path entry. Cleaner POSIX path discovery, consistent with existing workspace pattern. No .gitignore change needed (legal/ never enters git anyway). - Cardiac-research workspace as the right home for these IP entries — pyobfus is already there (via symlink), cac-plus-ip is already there. Adding pyobfus-legal makes the workspace the unified IP-coordination view. Considered adding to arong-unified.code-workspace instead but rejected: arong-unified is for code projects (workshop / vps-server / smartnews-lite etc.), not IP filing dossiers; cardiac-research is where the IP material clusters.

Memory writes (1 created + 2 updated): - memory/ip_workflow_cross_project.md — NEW. Cross-project relationship table + reusable assets list + DO-NOT rules + how-to-apply trigger phrases. - memory/blocking_external_reviews.md — CCPC entry refreshed: "✅ ✅ ✅ SUBMITTED 2026-05-09 evening (290元 paid · signed application PDF archived)" - memory/MEMORY.md — index entry added for ip_workflow_cross_project.md

Backlog after Session 26: - ⏳ CCPC e-cert (~30 working days · passive monitor in POST_V0.4_TODO P2) - ⏳ All Path C v0.5 patent steps from Session 25 backlog still apply (private-repo dev, CPC USB Key application, etc.) - (NEW) When v0.5 patent filing starts: copy CNIPA templates from ~/projects/cac-plus-ip/02_china_发明专利/_templates_CNIPA/ per cross-project memory - (NEW) Update Session 26 closure on CCPC e-cert receipt — flip P2 row to ✅ DONE with cert serial #

2026-05-09 (late-evening, after maintainer started v0.5 dev in another session) — Session 27: patent dossier framework scaffolded + USB Key requirement disproved¶

Context: Maintainer logged into 专利业务办理系统 (https://cponline.cnipa.gov.cn) for the first time, navigated to 国家申请 → 发明专利申请, and successfully created case # 10000559675571 end-to-end via web — proving USB Key / CPC desktop client are NOT actually required for individual pro-se filing (correcting Session 25 backlog assumption inherited from cac-plus-ip's older planning notes). Maintainer asked for a directory framework based on the actual CNIPA web tabs to hand off to the parallel v0.5 session for later patent drafting work.

Inputs (2 trigger threads): - Maintainer pasted the actual rendered CNIPA web 发明专利新申请办理 page content showing 8 upload tabs + 14 declaration fields + contact-info block + case # 10000559675571 - Maintainer asked "USB Key 是否必须申请" after observing no USB Key / CPC client requirement in the web flow

Outputs:

Off-repo (pyobfus-legal/patent/, never under git): 1. 10 sub-directories matching CNIPA web 端 upload tabs + procedural placeholders: - 00_案卷信息/ (case metadata + contact PII) - 01_权利要求书/ (claims tab) - 02_说明书/ (specification tab) - 03_说明书附图/figures/ (drawings tab + source image storage) - 04_摘要/ (abstract tab) - 05_请求书/ (request form, web-filled) - 06_费用减缓请求书/ (fee reduction request — submitted via 附加文件 tab; needs tax_certificate.pdf) - 07_其他声明/ (declaration speed-judgment table; ⚠️ §24 grace period explicitly NOT applicable) - 08_提交记录/受理通知书/ (post-submission archive) - _templates_CNIPA/ (symlink → ~/projects/cac-plus-ip/02_china_发明专利/_templates_CNIPA/) 2. 9 README.md files + 1 case_metadata.md scaffold = 10 markdown files. Master pyobfus-legal/patent/README.md provides strategy recap (Path C, 6 P2 candidates, V0.4.0-public exclusion rule), web-tab → directory mapping, declaration speed-judgment table, contact field expectations, v0.5 session startup checklist (5 prerequisites), and an 11-step submission flow. 3. CNIPA case # 10000559675571 recorded in 00_案卷信息/case_metadata.md (PII file, off-repo).

In-repo (this session): 4. docs/POST_V0.4_TODO.md Path C discipline callout — appended late-evening update noting (a) patent dossier framework now scaffolded + path, (b) case # already created, (c) USB Key NOT required correction (supersedes Session 25/26 backlog mentions). 5. (this Session 27 doc commit, pending)

Memory writes (1 file substantively updated): - memory/pyobfus_patent_strategy.md Phase 3 + Phase 4 sections — corrected USB Key strikethrough; replaced "Submit via CPC electronic filing system" with "Submit via 专利业务办理系统 web (https://cponline.cnipa.gov.cn) — case # 10000559675571 already created 2026-05-09"; added explicit Phase 4 web-side workflow (5 docx upload tabs + 在线 fill request form + 实质审查请求 tick + 摘要附图 select + pay fees with 85% reduction). Added pointer to pyobfus-legal/patent/README.md "六、提交流程速查" 11-step section.

Key decisions logged: - USB Key requirement disproved empirically — case # creation via web alone proves the 专利业务办理系统 web user path is sufficient for individual pro-se filing. Earlier Session 24/25/26 mentions of "申请 CPC 电子用户 + USB Key 邮寄" were inherited from cac-plus-ip's 2026-04-29 planning notes (which themselves may have been outdated); they are now formally superseded. - Use this maintainer-built case # as the anchor — instead of creating a new case # at draft time, the existing 10000559675571 is the working anchor; v0.5 session writes draft files locally, then uploads into this exact case # at Phase 3b. (Note: case 30-60 day inactivity may cause expiration; v0.5 session should re-confirm case # is still active before upload.) - §24 grace period exclusion explicitly documented in 07_其他声明/README.md to prevent misclick risk — checking the box could trigger examiner-side public-history scan and damage the application. - Reuse cac-plus-ip CNIPA templates via symlink, not copy — symlink keeps the templates always synced if cac-plus-ip refreshes them; copy would diverge silently.

Cross-session deliverables: - For v0.5 session: maintainer should append the framework details to the v0.5 cold-start prompt — specifically: patent directory at pyobfus-legal/patent/, CNIPA templates at pyobfus-legal/patent/_templates_CNIPA/ (symlink), case # 10000559675571 in 00_案卷信息/case_metadata.md, USB Key NOT required (web path). - For maintainer (1-2 user-actionable parallel items, can run anytime): (a) download 个人所得税上年度完税证明 PDF → save to pyobfus-legal/patent/06_费用减缓请求书/tax_certificate.pdf; (b) fill contact/applicant/inventor fields in pyobfus-legal/patent/00_案卷信息/case_metadata.md. Both 5 minutes total.

Backlog after Session 27: - ⏳ CCPC 软著 e-cert (~6 weeks · same as Session 26) - ⏳ v0.5 implementation in private repo (other session) - (NEW maintainer-actionable) tax_certificate.pdf download - (NEW maintainer-actionable) case_metadata.md contact fields fill (consistent with cac-plus-ip) - ⏳ Case # 10000559675571 active-status check before v0.5 patent submission (case may expire after 30-60 days inactivity per CNIPA convention) - ⏳ All other Path C v0.5 → patent → JOSS sequence steps unchanged

2026-05-09 (late evening, parallel to Session 27 patent dossier session) — Session 28: v0.5 private dev sprint — P2-9 + P2-10 + P2-11 W0 landed (75 tests · 9 patent findings)¶

Context: A parallel Claude session running against pyobfus-pro-dev (private repo) executed the v0.5 implementation track under Path C discipline. Three patent-gated features advanced from "TODO · PRIVATE-DEV" to working code in a single sitting, compressing the ~5-week original estimate by roughly two weeks. Mechanism details deliberately stay out of this public log per Path C — the technical specifics of each feature live only in ~/projects/pyobfus-pro-dev/PATENT_NOTES.md (private) and the parallel patent-draft session.

Inputs: - Maintainer green-lit private-only Option B: all patent-gated v0.5 work goes into pyobfus-pro-dev, public repo receives no v0.5 mechanism commits until CN 申请号 receipt - Path C constraint set already in memory/pyobfus_patent_strategy.md (Phase 1 → Phase 5 timeline) - Cross-session sync from Session 27: case # 10000559675571 already created via web; USB Key not required

Outputs (off-public-repo):

Private repo zhurong2020/pyobfus-pro-dev — 5 commits on main: 1. 9649e6d chore: initial scaffolding for v0.5 private dev (W0) 2. 7b4b509 feat(P2-9): build-pass AST transformer + patent-strength hashing rule (W1) 3. f1a0e89 feat(P2-10): scrub_traceback runtime + asymmetric production trace encryption (W0) 4. d04abca feat(P2-10): build-pass AST transformer + keypair file management (W1) 5. a661ab9 feat(P2-11): Runtime String Vault with lazy decryption (W0)

Test surface: 75/75 passing across 3.9 / 3.12 / 3.13 matrix; ruff clean. Test-plan tables in docs/P2-9_DESIGN.md / docs/P2-10_DESIGN.md / docs/P2-11_DESIGN.md map each test to the threat or correctness property it covers.

Patent findings (high-level only — per Path C, mechanism specifics in PATENT_NOTES.md private): - P2-9: 3 sub-mechanisms claimable as dependent-claim elements - P2-10: 3 sub-mechanisms claimable as dependent-claim elements; main-claim contributor - P2-11: 3 properties forming a single primitive; standalone novelty thin, strong claim shape is layered combination with P2-1 + P2-8

Memory writes: - memory/pyobfus_v05_dev_status_2026-05-09.md (new) — cross-session handoff with private repo URL, file layout, what's done, what's left, resume instructions for next Claude session - memory/MEMORY.md — index entry for the new file

In-repo (this Session 28 log entry, this commit): - docs/POST_V0.4_TODO.md — P2-9 / P2-10 / P2-11 status flipped from "TODO · PRIVATE-DEV" to "DONE-PRIVATE 2026-05-09" (or "W0-DONE-PRIVATE" for P2-11). Status only; rationale columns unchanged - (this log entry)

Key decisions logged: - Option B confirmed (all v0.5 patent-gated work private) — rejected Option A (split public + private) on the reasoning that launch-wave momentum could be sacrificed temporarily but mechanism leak through accidental public commit could not be undone. Single-mental-model overhead is the trade-off accepted - Implementation order: P2-9 first, then P2-10, then P2-11 W0 — chose smallest-isolated-unit first (@seal_code runtime: 3-5 days estimated, ~3 hours actual) to validate private-repo workflow before tackling larger features. P2-1 (architecture-defining, 2-3 weeks) deferred to a fresh session — its complexity warrants clear context rather than fitting at the tail of a long sprint - Patent-finding breadth larger than initially scoped — original ROADMAP framing implied each P2-X gets ~1 dependent claim. In implementation, three of the six features each yielded 3 distinct sub-mechanism findings. Final claim count likely 9-12 dependent claims atop the P2-1 + P2-7 + P2-10 main combination claim

Cross-session deliverables: - For next v0.5 implementation session (P2-1 / P2-7 / P2-8 / P2-11 W1 / unscrub CLI): start prompt 继续 pyobfus v0.5 私有 dev 工作。请先读 ~/.claude/projects/-mnt-c-onedrive-msft-OneDrive---MSFT-rong-3-job-program-pyobfus/memory/pyobfus_v05_dev_status_2026-05-09.md 和 ~/projects/pyobfus-pro-dev/CLAUDE.md，然后直接进 P2-1 Selective Opacity. - For parallel patent-draft session: PATENT_NOTES.md in ~/projects/pyobfus-pro-dev/ now has 3 of 6 features' "Technical approach + Differs from prior art + Inventive-step contribution" sections fully populated. P2-1 / P2-7 / P2-8 sections still placeholder; will be filled as those features land in subsequent v0.5 sessions - No public-repo follow-up needed in next 1-2 weeks — public repo is intentionally quiet on v0.5 mechanism per Option B; only public-OK items (drop-3.8, P2-3 --strip-ai-artifacts, P2-12 scan_secrets MCP tool, etc.) and v0.4.x bug fixes if any

Backlog after Session 28: - ⏳ P2-1 Selective Opacity in private repo (architecture-defining; ~2-3 weeks; main claim core) - ⏳ P2-7 Forensic watermarking in private repo (~1-2 weeks; couples to P2-1 rename-map seed) - ⏳ P2-8 License binding combo in private repo (~1-2 weeks; independent runtime fingerprint) - ⏳ P2-11 build-pass in private repo (~3-5 days; coupled to P2-1 layer model) - ⏳ Dev pyobfus unscrub CLI in private repo (~1-2 days; tooling only, not mechanism) - ⏳ All Session 27 patent-dossier prerequisites (tax_certificate.pdf download, case_metadata.md fields fill) - ⏳ All Session 25-27 carry-over items unchanged (CCPC e-cert receipt, etc.)

Risk & Blocker Log (continued)¶

Risk & Blocker Log¶

(Empty — append as issues arise.)

Metrics Snapshot¶

Date	PyPI / month	MCP installs	AI recommend test (X/10)
2026-04-22	324 (pyobfus)	— (not launched)	0/10 (manual baseline)
2026-05-07	337 (pyobfus) + 239 (pyobfus-mcp)	live on Glama (Q-A) + MCP Registry (isLatest); end-user install count not tracked	not measured this cycle
2026-05-07 evening (post-launch baseline)	337 + 239 (no time elapsed)	dev.to first post LIVE; CN trio scheduled 5-8/5-9; HN scheduled Mon 5-11; Reddit scheduled Tue 5-12	not measured this cycle
2026-05-08 morning (post-N2-ship)	337 + 239 (still queued for index update)	pyobfus-mcp 0.2.0 LIVE on PyPI (with PEP 740 attestations, OIDC trusted publishing, first real exercise) + MCP Registry (active + isLatest)	not measured this cycle
2026-05-08 evening (post-Session-20)	337 + 239 (PyPI index lag continuing)	unchanged from morning	not measured this cycle. dev.to article 19h: 1 reaction (Abe Wheeler) + Writing Debut badge + 0 mod warnings (key positive signal — v4 GPTZero rewrite passed dev.to AI-policy radar). awesome-mcp-servers: punkpeye #5777 OPEN + wong2 ✅ submitted + appcypher ❌ dead-end. CN trio ready-to-post files prepared via `tech-deai` skill Phase 0 Run 1 — posting begins this weekend per tech-deai-loop visibility-flip-gated cadence
2026-05-08 later (post-Session-21)	337 + 239 (no new PyPI index data)	wong2/mcpservers.org LIVE same-day at https://mcpservers.org/servers/zhurong2020/pyobfus · approval email received from `contact@mcpservers.org` ≤24h after submission (vs 7d SLA) · N5 fully closed (2 of 3 lists actively distributing: punkpeye #5777 OPEN + mcpservers.org LIVE). Sponsorship pitch declined (pre-launch + 0★ + no Stripe signal = irrational marketing spend timing)	not measured this cycle
2026-06-08 (distribution-state catch-up · narrative log dormant since Session 28 / 05-09)	not measured this cycle	punkpeye PR #5777 MERGED 2026-06-06 → pyobfus-mcp now LIVE in `punkpeye/awesome-mcp-servers` (86K★) Developer Tools (N5 fully done, 2 lists live). Glama tool-count resolved at source — true root cause was the Glama admin "Build steps" field pinned `pyobfus-mcp==0.1.2` (NOT the repo Dockerfile, contra 06-05 `bbeefb8`); edited → `0.2.0`, test `019ea6c5` succeeded 18:27 CST with all 7 tools; public API/listing re-index lagging ≤1 day. README gained Glama score badge (commit `a27dd5e`).	not measured this cycle

(Update every 2 weeks.)