Prepare study-use documentation and public-source review

PUBLICATION_REVIEW.md

@@ -0,0 +1,28 @@
+# Public-source preparation: MCPatch
+
+Status: **preparation only; not cleared for public release**.
+
+## Review performed
+
+Reviewed the default-branch file inventory and selected README, ignore rules, deployment documentation, and configuration. This is not a full source scan, a full Git-history scan, or a review of every branch, tag, issue, attachment, release, and Actions log.
+
+The existing pre-alpha warning and current private/no-license statement are preserved. Registry, publishing, signing, and community-pack materials require explicit separation from anything intended to remain private. No secret-free or history-clean claim is made.
+
+## Required before changing visibility
+
+- [ ] Review all current source files, examples, fixtures, generated assets, screenshots, and operational notes for personal or third-party data.
+- [ ] Scan a complete local clone, including every branch and tag, with a current secret scanner. Use redacted output; never publish reports containing secrets. Suggested command after fetching all refs: `gitleaks git --redact --log-opts="--all"`.
+- [ ] Review author/committer emails, historical file contents, commit messages, pull requests, issues, attachments, releases, workflow logs, and artifacts. Removing a current file does not remove its history.
+- [ ] Rotate or revoke any real credential found before considering history cleanup. Document a clean result against the exact release commit.
+- [ ] Replace real records with synthetic examples. Remove production endpoints and deployment identifiers that are not meant to be public.
+- [ ] Keep employer-owned code, internal configuration, private service backends, operational data, and signing material private.
+- [ ] Resolve licensing deliberately; the README's study/personal-use statement does not change the repository's existing license terms.
+- [ ] Validate clean setup, build, and tests using only documented placeholders and locally supplied credentials.
+- [ ] Make the final visibility decision only after the review above is complete.
+
+If sensitive material exists in history, assess a separate sanitized public snapshot instead of exposing that history. No history rewrite, force push, visibility change, or release is performed by this preparation branch.
+
+References:
+- https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository
+- https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility
+- https://github.com/gitleaks/gitleaks

README.md

@@ -1,5 +1,9 @@
 # MCPatch
 
+> [!IMPORTANT]
+> **Independent study and personal-use project.** MCPatch is experimental work for learning, research, and personal use. It is not an employer product, a hosted production-service offering, or a commitment of support. Use integrations only with systems and accounts you are authorized to access, and read the threat model and security limitations first.
+> Public-source preparation is in progress; see [PUBLICATION_REVIEW.md](PUBLICATION_REVIEW.md) for the remaining review work.
+
 MCPatch turns websites into safe, typed agent capabilities without granting an
 agent unrestricted browser access.
 

docs/portfolio/github-profile-draft.md

@@ -0,0 +1,30 @@
+# Nir Vaknin | Senior DevOps Engineer
+
+I work on reliable infrastructure, cloud operations, automation, CI/CD, and developer platforms. My background spans enterprise IT, Linux administration, cloud operations, and DevOps.
+
+My independent projects explore the same engineering questions: explicit ownership, clear interfaces, safe automation, observability, and recovery.
+
+## Engineering focus
+
+- Infrastructure automation, cloud operations, and dependable delivery.
+- Developer tooling and repeatable operational workflows.
+- Permission boundaries, validated inputs, and controlled state changes.
+- Python, Linux, AWS, Docker, APIs, and CI/CD.
+- AI and MCP integrations as supporting project work.
+
+## Selected independent projects
+
+| Project | Engineering focus |
+| --- | --- |
+| **MCPatch** | Rust/TypeScript capability broker with typed, origin-bound browser tools and explicit permissions. |
+| **Kimi Chart** | Self-hosted decision platform separating market data, validation, and controlled paper-order authority. |
+| **portctl** | GitOps-oriented tooling for developer portal configuration, previews, validation, and drift detection. |
+| **Namlog** | iOS nutrition logging with wearable context, deterministic calculations, and AI-assisted interaction. |
+
+**Project purpose:** These are independent projects for study, research, and personal use. They are not employer products or production-service offerings. Each project's documented status, limitations, and licensing apply. Public source links will be added as repositories complete their release review.
+
+## Working approach
+
+Start from the operational problem. Define contracts and authority boundaries. Keep components focused, validate failure paths, and treat deployment, observability, and recovery as part of the engineering work.
+
+[Contact me on LinkedIn](https://www.linkedin.com/in/nir-vaknin-85736289)