Merge dev to main for v0.3.0 - #18
Conversation
…final replies are always provided
…lity and update args type hint in shell_tool function
…thorough text checks before submission
…pt for model sizes
…n flash-onyx-2.Modelfile
… flash-onyx-2.Modelfile
There was a problem hiding this comment.
@Natuworkguy This release PR does not bump flash/version.py (still 0.2.0). Update __version__ before merging.
flash/version.py bumped. Clearing the version guard.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6d0c76c517
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| echo "Registering the flash:// URL handler..." | ||
| "$FLASH_BIN" --register-url-scheme || \ | ||
| echo "Unable to install flash:// URL handler. Continuing." | ||
| FLASH_VERSION="$(flash --version)" |
There was a problem hiding this comment.
Use the resolved flash binary for version output
In a fresh pipx install where PIPX_BIN_DIR is not already on PATH, this unqualified flash lookup fails under set -euo pipefail even though $FLASH_BIN just pointed at the installed executable and the script has a later PATH warning for exactly that case. Use "$FLASH_BIN" --version or tolerate this failure so new installs do not exit non-zero after successfully installing.
Useful? React with 👍 / 👎.
| == Tool calls == | ||
| Only the tools defined in the Tool System Prompt below exist. There is no `ls`, `cat`, or `read` tool, run those through `shell`. Every response you send is either one or more real tool calls made through the function-calling mechanism, or your final natural-language answer, never both, and never a JSON object typed out as text. Typed-out JSON does not execute: nothing runs it, the user just sees raw text, and your turn ends with nothing done. If you want to show the user a command rather than run it, write it as plain text in backticks (for example `ls -la`) instead of describing or half-executing it. When retrying a failed or corrected command, silently call the tool again with the fix, never narrate the fix in text and stop there. Before reaching for any tool, check whether the answer is already given to you verbatim in this prompt (the current date, your scratch directory path); if so, answer directly instead of spending a call to rediscover it. | ||
| You can run tools here. | ||
| Only the tools defined in the Tool System Prompt below exist. There is no `ls`, `cat`, or `read` tool, run those through `shell`. Every response you send is either one or more real tool calls made through the function-calling mechanism, or your final natural-language answer, never both, and never a JSON object typed out as text. Typed-out JSON does not execute: nothing runs it, the user just sees raw text, and your turn ends with nothing done. If you want to show the user a command rather than run it, write it as plain text in backticks (for example `ls -la`) instead of describing or half-executing it. When retrying a failed or corrected command, silently call the tool again with the fix, never narrate the fix in text and stop there. Before reaching for any tool, check whether the answer is already given to you verbatim in this prompt (the current date, your scratch directory path); if so, answer directly instead of spending a call to rediscover it. Every turn must end with a final natural-language reply to the user, never stop right after a tool call with nothing further; once you've gathered what you need, always write the reply, even if the result is empty, uncertain, partial, or an error, state plainly what happened and what it means rather than leaving the user with silence. |
There was a problem hiding this comment.
Remove the stale no-read-tool instruction
Now that flash/tools.py registers a real read tool and the tool prompt tells the model to use it, this earlier system-prompt sentence still says there is no read tool and to use shell instead. For file-inspection requests the model can follow the stale higher-level instruction and bypass the new numbered, paged reader, so update this list to exclude only tools that truly do not exist.
Useful? React with 👍 / 👎.
| if isinstance(old_lines, str): | ||
| tool_result(old_lines, style=ERROR) | ||
| return old_lines | ||
| old_text = "\n".join(old_lines) |
There was a problem hiding this comment.
Preserve line endings when building the write diff
For existing files, reconstructing old_text from _read_lines() strips the final newline and normalizes line endings before _diff_preview runs. If the proposed content differs only by removing the final newline, trailing blank lines, or CRLF/LF bytes, the confirmation preview can report No changes while the later write still changes the file, so compare against the raw text or keep line endings in the diff input.
Useful? React with 👍 / 👎.
No description provided.