Merge branch 'main' into fix/issue-457-edit-unsuccessfull

Author: nigeldelviero

.changeset/fix-multiline-quoted-command-parsing.md

@@ -0,0 +1,17 @@
+---
+"zoo-code": patch
+---
+
+Fix command auto-approval for multi-line shell constructs that must be treated as a single command.
+
+**Quoted multi-line arguments** (`sh -c '...'`, `sh -c $'...'`, `sh -c "..."`): the parser previously split on every newline before handling quotes, so newlines inside a quoted argument were treated as separate commands, defeating allowlist auto-approval. Single-quoted, ANSI-C (`$'...'`), and double-quoted strings are now masked before the newline split so embedded newlines and operators stay within their command.
+
+**Heredocs** (`<< EOF`, `<< 'EOF'`, `<< "EOF"`, `<<- EOF`): the entire heredoc -- opener line, body, and terminator -- is now treated as a single quoted region. Body lines are not split into independent sub-commands. All heredoc delimiter quoting styles (unquoted, single-quoted, double-quoted, backslash-escaped) are supported. An unterminated heredoc (missing terminator) is treated as malformed and returned as a single opaque token.
+
+**Locale quoting** (`$"..."`): treated as a distinct token analogous to ANSI-C quoting, preserving the `$` prefix and preventing the double-quote handler from stripping it.
+
+Quote masking is comment-aware: a quote character inside a `#` comment is not paired with a quote on a later line, so a comment cannot hide a real newline separator and merge two distinct commands. Commands with an unterminated quote are detected with a quote-aware scanner and returned as a single opaque token, preventing a line inside the unclosed quote from surfacing as an independently auto-approvable command. Genuine unquoted newlines still split into separate sub-commands, each of which must be allowlisted for auto-approval.
+
+**Pattern selector (UI)**: the command pattern breakdown shown after execution now uses the same heredoc- and quote-aware parser (`parseCommand`) before extracting patterns, so an unterminated or terminated heredoc no longer produces spurious tokens like `EOF`, body-line words, or `<<` fragments in the allow/deny selector.
+
+Note: this change only prevents *auto-approval* of fragments from a malformed command; it does not reject malformed commands before execution, which will be addressed in a separate PR to keep the scope focused here.

CONTRIBUTING.md

@@ -20,6 +20,8 @@ Zoo Code is a community-driven project, and we deeply value every contribution.
 - [Before You Contribute](#before-you-contribute)
 - [Finding & Planning Your Contribution](#finding--planning-your-contribution)
 - [Development & Submission Process](#development--submission-process)
+    - [Pull Request Expectations](#pull-request-expectations)
+    - [AI-Assisted Contributions](#ai-assisted-contributions)
 - [Legal](#legal)
 
 ## Before You Contribute
@@ -136,6 +138,32 @@ pnpm install
 - **Weekly In-depth Review:** Comprehensive assessment.
 - **Iterate promptly** based on feedback.
 
+### Pull Request Expectations
+
+Pull requests should be reviewable, tested, and maintainable. Before opening a PR, please make sure that:
+
+- The change is scoped to a specific issue, bug, or improvement.
+- You can explain what the change does and why it is correct.
+- You have tested the change locally where practical.
+- You are willing to respond to review feedback and make reasonable follow-up changes.
+- The PR does not require maintainers to substantially rewrite, redesign, or take ownership of the implementation before it can be merged.
+
+Maintainers may close PRs that are incomplete, too broad, inactive, not aligned with the project direction, or that create disproportionate review or maintenance burden. Closing a PR is not a judgment on the contributor; it is a maintainer decision that the change cannot be accepted in its present form.
+
+### AI-Assisted Contributions
+
+Use of AI tools is allowed, but contributors remain fully responsible for their submissions.
+
+If you use AI tools to help create a PR, you must:
+
+- Review and understand every meaningful change.
+- Be able to explain the implementation and tradeoffs in your own words.
+- Test the change yourself. If testing is impractical for your environment, explain why in the PR description and describe how reviewers can verify the change instead.
+- Verify that generated code is correct, necessary, and compatible with the project license.
+- Consider disclosing AI assistance in the PR description when it materially shaped the code, tests, or design — this helps reviewers give better feedback.
+
+Please do not submit AI-generated changes that you do not understand or cannot maintain through review. Maintainers may close PRs that appear substantially AI-assisted but lack human verification, clear rationale, or review follow-through.
+
 ## Legal
 
 By contributing, you agree your contributions will be licensed under the Apache 2.0 License, consistent with Zoo Code's licensing.