@delma/fylo 1.1.1 → 1.1.2

package/.github/copilot-instructions.md

@@ -1,3 +1,3 @@
-Follow the shared workspace instructions in `../instructions.md` and shared context in `../memory.md`.
+Follow the shared workspace instructions in `../../INSTRUCTIONS.md`, shared context in `../../MEMORY.md`, and shared release process in `../../RELEASE.md`.
 
 If a repo-local instruction file adds stricter rules, follow the repo-local rule.

package/.github/prompts/release.prompt.md

@@ -1,49 +1,10 @@
 ---
-description: "Create a release branch, publish to npm via CI, then merge to main"
+description: "Follow the shared workspace release process"
 agent: "agent"
 tools: [runInTerminal]
 ---
-Create a release branch, publish to npm via CI, then merge to main.
+Follow the shared workspace release process in [../../../RELEASE.md](../../../RELEASE.md).
 
-1. Run `bun test` and stop if any tests fail.
+Use the repo's actual default branch. Do not assume it is `main`.
 
-2. Determine the new version automatically based on unreleased commits:
-   `git log $(git describe --tags --abbrev=0 2>/dev/null || git rev-list --max-parents=0 HEAD)..HEAD --oneline`
-
-   Apply these rules to select the bump type:
-   - **major** — any commit with a `!` breaking-change marker (e.g. `feat!:`, `fix!:`) or a `BREAKING CHANGE` footer.
-   - **minor** — one or more `feat:` commits and no breaking changes.
-   - **patch** — only `fix:`, `chore:`, `docs:`, `refactor:`, `test:`, or `perf:` commits.
-
-   Compute the new version by incrementing the corresponding part of the current `"version"` in [package.json](package.json) and resetting lower parts to zero. Show the chosen version and the reasoning to the user before proceeding.
-
-3. Update `"version"` in [package.json](package.json) to the new version.
-
-4. Fetch the latest main and create a release branch from it:
-   ```
-   git fetch origin main
-   git checkout -b release/<version> origin/main
-   ```
-
-5. Stage all changes and commit:
-   `git add -A && git commit -m "chore: release v<version>"`
-
-6. Push the branch:
-   `git push -u origin release/<version>`
-
-7. Tell the user that the `publish` workflow will now run on GitHub Actions:
-   - It verifies the branch name matches `package.json` version.
-   - It runs tests, publishes to npm, creates a git tag, and opens a GitHub release.
-   - The NPM_TOKEN secret must be set in repo Settings → Secrets → Actions.
-
-8. Once the workflow passes (user confirms), create a PR and merge it to main:
-   ```
-   gh pr create --title "chore: release v<version>" --body "Release v<version>" --base main --head release/<version>
-   gh pr merge --merge --delete-branch
-   ```
-
-9. Switch back to main and pull:
-   ```
-   git checkout main
-   git pull
-   ```
+If repo-local workflows impose stricter checks or branch requirements, follow the repo-local workflow and then update the shared release guide later if that rule becomes the new standard.

package/AGENTS.md

@@ -1,3 +1,3 @@
-Follow the shared workspace instructions in [../instructions.md](../instructions.md) and shared context in [../memory.md](../memory.md).
+Follow the shared workspace instructions in [../INSTRUCTIONS.md](../INSTRUCTIONS.md), shared context in [../MEMORY.md](../MEMORY.md), and shared release process in [../RELEASE.md](../RELEASE.md).
 
 Repo-local rules may add to or override the shared files when explicitly stated.

package/CLAUDE.md

@@ -1,3 +1,3 @@
-Follow the shared workspace instructions in [../instructions.md](../instructions.md) and shared context in [../memory.md](../memory.md).
+Follow the shared workspace instructions in [../INSTRUCTIONS.md](../INSTRUCTIONS.md), shared context in [../MEMORY.md](../MEMORY.md), and shared release process in [../RELEASE.md](../RELEASE.md).
 
 Repo-local rules may add to or override the shared files when explicitly stated.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@delma/fylo",
-  "version": "1.1.1",
+  "version": "1.1.2",
   "main": "./dist/index.js",
   "types": "./dist/types/index.d.ts",
   "bin": {

package/.github/prompts/issue.prompt.md

@@ -1,19 +0,0 @@
----
-description: "Create a GitHub issue for a bug or feature request"
-argument-hint: "Describe the bug or feature request"
-agent: "agent"
-tools: [runInTerminal]
----
-Create a GitHub issue. The user's description is provided as the argument.
-
-Determine whether the description sounds like a bug or a feature request, then create the issue with `gh issue create` using the following structure:
-
-**For a bug:**
-- Title: "fix: <short description>"
-- Body sections: **Describe the bug**, **Steps to reproduce**, **Expected behaviour**, **Actual behaviour**, **Possible cause** (reference relevant lines in `src/index.ts` if applicable), **Environment** (Bun version, TypeScript version, AWS/S3 endpoint details).
-
-**For a feature request:**
-- Title: "feat: <short description>"
-- Body sections: **Problem**, **Proposed solution**, **Alternatives considered**, **Affected API** (list any methods in `src/types/fylo.d.ts` or `src/types/query.d.ts` that would change).
-
-Apply the appropriate label (`bug` or `enhancement`) via `--label`. Print the issue URL when done.

package/.github/prompts/pr.prompt.md

@@ -1,18 +0,0 @@
----
-description: "Create a pull request for the current branch into main"
-agent: "agent"
-tools: [runInTerminal]
----
-Create a pull request for the current branch into `main`.
-
-1. Run `git status` and stop if there are uncommitted changes — ask the user to commit or stash them first.
-2. Run `git log main..HEAD --oneline` to list commits on this branch.
-3. Run `git diff main...HEAD` to understand all changes.
-4. Push the branch to origin if it has no upstream: `git push -u origin HEAD`.
-5. Create the PR with `gh pr create` using:
-   - A concise title (≤ 70 chars) derived from the branch name and commits.
-   - A body with three sections:
-     - **Summary** — bullet list of what changed and why.
-     - **Test plan** — checklist of how to verify the changes (reference `bun test` where relevant).
-     - **Breaking changes** — any changes to public API in [src/types/fylo.d.ts](src/types/fylo.d.ts) or [src/types/query.d.ts](src/types/query.d.ts); write "None" if there are none.
-6. Print the PR URL.

package/.github/prompts/review-pr.prompt.md

@@ -1,19 +0,0 @@
----
-description: "Review a pull request by number or URL"
-argument-hint: "PR number or URL (e.g. 42)"
-agent: "agent"
-tools: [runInTerminal]
----
-Review the pull request given as an argument (PR number or URL).
-
-1. Fetch the PR details: `gh pr view <arg> --json title,body,headRefName,baseRefName,files`
-2. Fetch the diff: `gh pr diff <arg>`
-3. Review the changes with focus on:
-   - **Correctness** — logic errors, edge cases missed in query parsing ([src/core/parser.ts](src/core/parser.ts)), S3 operations ([src/adapters/s3.ts](src/adapters/s3.ts)), or directory/index management ([src/core/directory.ts](src/core/directory.ts)).
-   - **Type safety** — use of `any` instead of `unknown`, missing type guards, incorrect use of types in [src/types/](src/types/).
-   - **Tests** — whether new behaviour is covered in [tests/](tests/); flag any missing cases across document, collection, or schema tests.
-   - **Public API** — unintended changes to [src/types/fylo.d.ts](src/types/fylo.d.ts) or [src/types/query.d.ts](src/types/query.d.ts).
-   - **CI** — whether the workflow files in [.github/workflows/](.github/workflows/) are still valid for the change.
-4. Post the review as inline comments using `gh pr review <arg> --comment --body "<feedback>"`.
-   Group feedback by file. Prefix each point with **[suggestion]**, **[issue]**, or **[nit]**.
-5. Summarise the overall verdict: Approve / Request changes / Comment only.

package/.github/prompts/sync-main.prompt.md

@@ -1,14 +0,0 @@
----
-description: "Rebase the current branch onto the latest main from origin"
-agent: "agent"
-tools: [runInTerminal]
----
-Safely bring the current branch up to date with the latest `main` from origin.
-
-1. Confirm the current branch with `git branch --show-current`. If already on `main`, just run `git pull` and stop.
-2. Stash any uncommitted changes with `git stash push -m "sync-main auto-stash"` and note whether anything was stashed.
-3. Fetch the latest: `git fetch origin main`.
-4. Rebase the current branch onto `origin/main`: `git rebase origin/main`.
-5. If the rebase has conflicts, list the conflicting files and stop — ask the user to resolve them, then run `git rebase --continue`.
-6. If a stash was created in step 2, restore it with `git stash pop`.
-7. Report: commits rebased, files changed, any stash restored.