@hasna/instructions 0.4.7 → 0.4.9

package/README.md

@@ -192,6 +192,93 @@ manifests for drift, refuses unmanaged file conflicts unless `--force` is
 passed, removes stale managed mirrors only when safe, and writes local snapshots
 before mutating managed files.
 
+### Session renderer ownership
+
+Anything the session renderer writes is off limits to `instructions apply` and
+`instructions sync --to-disk`; those rows are reported as `[owned]` and skipped
+instead of overwriting rendered output. Ownership is decided from the renderer's
+own definitions rather than a hand-maintained path list:
+
+- **Managed directories** — every `managedDir` in `SESSION_TOOL_ADAPTERS`, matched
+  on whole path segments under any target home (`~/.claude/.hasna/instructions/…`,
+  `~/.hasna/accounts/profiles/claude/account003/.hasna/instructions/…`, …), plus
+  the renderer's `.hasna/session-render-manifest.json` and
+  `.hasna/session-render-snapshots/`.
+- **Manifest claims** — any file listed in an ancestor target home's
+  `.hasna/session-render-manifest.json`. This covers provider-native output such
+  as `CLAUDE.md`, `AGENTS.md`, and `opencode.json` exactly where the renderer
+  actually rendered.
+
+`~/.cursor/rules` is deliberately *not* statically reserved: the config fan-out
+writes `cursor-mdc` transform outputs there too, so files in that directory are
+owned only when a manifest claims them.
+
+Renumbering a source (inserting a new lower-order source shifts `01-` → `02-`
+and so on) orphans older `target_path` values that still point inside a managed
+directory. The guard is what neutralises those orphans, so stale rows are inert
+rather than destructive.
+
+Applying a config into renderer-owned space requires the explicit opt-in flag:
+
+```bash
+instructions apply <id> --allow-renderer-owned
+```
+
+It is separate from `--force` on purpose — "overwrite even if unchanged" must
+never silently become "overwrite renderer-owned instruction files".
+
+### Managed project context
+
+`instructions project-context plan|apply` is the sole writer for the strict
+`hasna.projects.project_context_bundle.v1` contract emitted by Projects. It
+accepts bounded structured JSON from a regular file or stdin and never invokes
+Projects, Todos, Conversations, or Mementos while rendering:
+
+```bash
+projects context-bundle <project-id> --json > ./project-context.json
+instructions project-context plan \
+  --runtime codewith \
+  --workspace-root /absolute/workspace \
+  --bundle ./project-context.json \
+  --json
+instructions project-context apply \
+  --runtime codewith \
+  --workspace-root /absolute/workspace \
+  --bundle ./project-context.json \
+  --json
+```
+
+The renderer writes one canonical `.hasna/instructions/project-context.md`
+fragment, then a managed import in `CLAUDE.md`, a managed inline block in
+`AGENTS.md`, and a managed inline block in `.codewith/CODEWITH.md` by default.
+Codewith uses an import only when its existing
+`HASNA_CONFIGS_CODEWITH_NATIVE_IMPORTS=1` capability gate is active or
+`--codewith-native-imports` explicitly selects that supported runtime mode.
+Bytes outside the managed marker pair are preserved. Codewith's
+`.codewith/CODEWITH.override.md` takes precedence and causes the stable
+`PROJECT_CONTEXT_SHADOWED` failure instead of an ignored write.
+Existing Instructions session manifests are updated additively, and later
+`instructions session plan|apply` runs recompose the validated durable project
+context so routine Claude, Codewith, or Codex rerenders cannot discard it.
+
+Input is limited to 8 KiB, output to 4 KiB and six allowlisted argv commands.
+The writer rejects unknown fields, hash/revision inconsistencies, credentials,
+URLs, symlinks, malformed or conflicting markers, and older revisions. Applies
+use a per-workspace lock, compare-and-swap hashes, same-directory fsynced temp
+files and renames, and a metadata-only manifest written last. Existing-file
+updates require an atomic exchange primitive (Linux `renameat2` or macOS
+`renameatx_np`); unsupported platforms, including Windows, fail closed before
+replacement rather than approximating an exchange. A same-project,
+compatible last-known-good cache can be selected explicitly with
+`--allow-stale-cache --expected-project-id <id>`; its bounded age/status is
+visible in the rendered context.
+
+Compatibility remains additive: project-context manifests keep
+`hasna.configs.session-render/v1`, `Managed by @hasna/configs`, and
+`ownedBy: open-configs`, while recording `canonicalOwner: instructions`. The
+legacy `@hasna/configs` 0.2.45 `configs` executable remains available as a bin
+alias; no separate Configs repository or flag-day manifest v2 is introduced.
+
 `instructions init` and `bun run seed` also seed
 `global-agent-rules-standard`, the managed global/system prompt source for
 session renaming, task-scoped worktrees, PR-first landing, protected-branch

package/dashboard/README.md

@@ -0,0 +1,73 @@
+# React + TypeScript + Vite
+
+This template provides a minimal setup to get React working in Vite with HMR and some ESLint rules.
+
+Currently, two official plugins are available:
+
+- [@vitejs/plugin-react](https://github.com/vitejs/vite-plugin-react/blob/main/packages/plugin-react) uses [Babel](https://babeljs.io/) (or [oxc](https://oxc.rs) when used in [rolldown-vite](https://vite.dev/guide/rolldown)) for Fast Refresh
+- [@vitejs/plugin-react-swc](https://github.com/vitejs/vite-plugin-react/blob/main/packages/plugin-react-swc) uses [SWC](https://swc.rs/) for Fast Refresh
+
+## React Compiler
+
+The React Compiler is not enabled on this template because of its impact on dev & build performances. To add it, see [this documentation](https://react.dev/learn/react-compiler/installation).
+
+## Expanding the ESLint configuration
+
+If you are developing a production application, we recommend updating the configuration to enable type-aware lint rules:
+
+```js
+export default defineConfig([
+  globalIgnores(['dist']),
+  {
+    files: ['**/*.{ts,tsx}'],
+    extends: [
+      // Other configs...
+
+      // Remove tseslint.configs.recommended and replace with this
+      tseslint.configs.recommendedTypeChecked,
+      // Alternatively, use this for stricter rules
+      tseslint.configs.strictTypeChecked,
+      // Optionally, add this for stylistic rules
+      tseslint.configs.stylisticTypeChecked,
+
+      // Other configs...
+    ],
+    languageOptions: {
+      parserOptions: {
+        project: ['./tsconfig.node.json', './tsconfig.app.json'],
+        tsconfigRootDir: import.meta.dirname,
+      },
+      // other options...
+    },
+  },
+])
+```
+
+You can also install [eslint-plugin-react-x](https://github.com/Rel1cx/eslint-react/tree/main/packages/plugins/eslint-plugin-react-x) and [eslint-plugin-react-dom](https://github.com/Rel1cx/eslint-react/tree/main/packages/plugins/eslint-plugin-react-dom) for React-specific lint rules:
+
+```js
+// eslint.config.js
+import reactX from 'eslint-plugin-react-x'
+import reactDom from 'eslint-plugin-react-dom'
+
+export default defineConfig([
+  globalIgnores(['dist']),
+  {
+    files: ['**/*.{ts,tsx}'],
+    extends: [
+      // Other configs...
+      // Enable lint rules for React
+      reactX.configs['recommended-typescript'],
+      // Enable lint rules for React DOM
+      reactDom.configs.recommended,
+    ],
+    languageOptions: {
+      parserOptions: {
+        project: ['./tsconfig.node.json', './tsconfig.app.json'],
+        tsconfigRootDir: import.meta.dirname,
+      },
+      // other options...
+    },
+  },
+])
+```