@docyrus/docyrus 0.0.48 → 0.0.50

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@docyrus/docyrus",
-  "version": "0.0.48",
+  "version": "0.0.50",
   "private": false,
   "description": "Docyrus API CLI",
   "main": "./main.js",

package/resources/pi-agent/extensions/server-auto-commit.ts

@@ -14,6 +14,11 @@
  *   GET /api/sessions/:sessionId/config
  *
  * Config is stored at: <agentDir>/session-config/<sessionId>.json
+ *
+ * GitHub token auto-refresh:
+ * When a push fails with an authentication error, the extension automatically
+ * calls `docyrus auth github` (using DOCYRUS_SANDBOX_APP_ID) to regenerate the
+ * token and retry the push.
  */
 
 import type { ExtensionAPI } from "@mariozechner/pi-coding-agent";
@@ -69,6 +74,34 @@ async function isAutoCommitEnabled(sessionId: string): Promise<boolean> {
   }
 }
 
+function isGithubAuthError(stderr: string): boolean {
+  const lower = stderr.toLowerCase();
+  return (
+    lower.includes("authentication failed")
+    || lower.includes("invalid username or password")
+    || lower.includes("could not read username")
+    || lower.includes("the requested url returned error: 401")
+    || lower.includes("the requested url returned error: 403")
+    || lower.includes("bad credentials")
+  );
+}
+
+async function tryRefreshGithubToken(cwd: string): Promise<boolean> {
+  const appId = process.env.DOCYRUS_SANDBOX_APP_ID?.trim();
+  if (!appId) {
+    return false;
+  }
+
+  try {
+    await execFile("docyrus", ["auth", "github", "--appId", appId, "--cwd", cwd], { cwd });
+    return true;
+  } catch (error: unknown) {
+    const err = error as { stderr?: string; message?: string };
+    process.stderr.write(`[server-auto-commit] github token refresh failed: ${err.stderr || err.message || String(error)}\n`);
+    return false;
+  }
+}
+
 export default function(_pi: ExtensionAPI) {
   _pi.on("agent_end", async(_event, ctx) => {
     const sessionId = ctx.sessionManager.getSessionId();
@@ -96,6 +129,19 @@ export default function(_pi: ExtensionAPI) {
 
     const push = await runGit(["push", "--no-verify"], ctx.cwd);
     if (push.code !== 0) {
+      if (isGithubAuthError(push.stderr)) {
+        process.stderr.write(`[server-auto-commit] push failed with auth error, attempting token refresh\n`);
+        const refreshed = await tryRefreshGithubToken(ctx.cwd);
+        if (refreshed) {
+          const retryPush = await runGit(["push", "--no-verify"], ctx.cwd);
+          if (retryPush.code === 0) {
+            process.stderr.write(`[server-auto-commit] committed and pushed after token refresh at ${timestamp}\n`);
+            return;
+          }
+          process.stderr.write(`[server-auto-commit] push still failed after token refresh: ${retryPush.stderr}\n`);
+          return;
+        }
+      }
       process.stderr.write(`[server-auto-commit] git push failed: ${push.stderr}\n`);
       return;
     }

package/resources/pi-agent/prompts/coder-system.md

@@ -28,6 +28,17 @@ Core behavior:
 - Treat `.docyrus`, tokens, auth files, session files, generated env-backed provider settings, and runtime settings as sensitive.
 - When platform capability is uncertain, verify against the active tenant context, the local CLI, and the discovered OpenAPI spec before making claims.
 
+End-user UI purity:
+
+- Apps you build are production tools for business end users, not developer dashboards. Every screen must look and behave like a finished product, not a prototype or progress report.
+- Never render project-plan metadata, task descriptions, acceptance criteria, feature summaries, implementation notes, knowledge-base content, or any other developer-facing context in the app UI. These are your internal references for understanding the work — they must never appear on screen.
+- Never display technical badges, tags, or banners that describe implementation status, backend capabilities, data-source wiring, or architecture decisions (e.g., "Docyrus katalog senkronu hazır", "Mock yerine gerçek veri kullanılıyor").
+- Never add "next step" buttons, development roadmap panels, or progress summaries that describe remaining implementation work.
+- Never show explanatory paragraphs or headings that describe what the app is or how it works from a developer perspective. Page titles and descriptions must be written for end users performing their daily work.
+- All visible text, labels, descriptions, and placeholders must be written from the end-user perspective — as if the app has always existed and the user is simply using it.
+- Dashboard cards and stats must display real operational metrics from data sources (record counts, status breakdowns, date ranges), not descriptions of what the metric represents technically or how it is fetched.
+- If a screen has no real data to display yet, show an appropriate empty state (e.g., "Henüz kayıt yok" / "No records yet") rather than developer notes about what will be wired later.
+
 Docyrus platform model you should understand and use accurately:
 
 - apps as top-level containers for product surface area

package/resources/pi-agent/skills/changelog-generator/SKILL.md

@@ -9,6 +9,7 @@ description: >
 - User says "document changes", "what changed since last release"
 - User wants to "prepare a release" and needs a changelog entry
 - User asks to "clean up" or "reformat" an existing changelog
+- User runs `docyrus release new-version` and needs changelog content
 
 **Covers:** Any git-based project.
 
@@ -183,6 +184,41 @@ Flag breaking changes regardless of convention:
 
 Mark breaking entries with **BREAKING:** prefix in the changelog.
 
+### Phase 3b — Docyrus Backend Modifications
+
+In addition to code changes, scan for Docyrus platform modifications made through the CLI or API. These should be included alongside code changes in the changelog.
+
+**Detection methods:**
+
+1. Search git diff for changes to `docyrus/` directory files (data-sources.plan.json, knowledge files, project-plan changes)
+2. Look for commit messages containing: `docyrus studio`, `data source`, `field`, `enum`, `app`
+3. Check for `docyrus/project-plan/` changes that reference architecture tasks
+4. Look for `.docyrus/` configuration changes
+
+**Map to changelog categories:**
+
+- **Added** — New data sources created, new fields added, new enum options, new apps provisioned
+- **Changed** — Field type changes, enum updates, data source configuration changes, knowledge graph updates
+- **Removed** — Deleted data sources, removed fields, removed enum options
+
+**Entry format for backend changes:**
+
+```markdown
+- Add "Contacts" data source with 12 fields (name, email, phone, ...)
+- Add "Priority" enum to Opportunity data source (Low, Medium, High, Critical)
+- Update "Account" data source: add "industry" and "revenue" fields
+- Remove deprecated "legacy_status" field from Tasks data source
+```
+
+When both code changes and Docyrus platform changes exist, include platform changes under a **Docyrus Platform** heading within the version section:
+
+```markdown
+### Docyrus Platform
+
+- Add "Contacts" data source with name, email, phone fields
+- Update "Opportunity" enum: add Critical priority level
+```
+
 ### Phase 4 — Entry Writing
 
 Transform raw commit data into human-readable changelog entries.

package/resources/pi-agent/skills/release-manager/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: release-manager
+description: >
+  Manage project releases, version bumping, changelog generation, and GitHub release creation using the docyrus release CLI.
+  Handles SemVer versioning, changelog assembly (including Docyrus platform changes), git tagging, and optional GitHub release publishing.
+
+**Triggers — use this skill when:**
+- User says "release", "new version", "bump version", "tag release", "cut a release"
+- User wants to publish, ship, or prepare a release
+- User asks about the current version, release status, or unreleased changes
+- User says "what's changed since last release"
+
+**Covers:** Projects using the docyrus project plan system with package.json versioning.
+---
+
+# Release Manager
+
+Manage releases using the `docyrus release` CLI commands.
+
+## Quick Reference
+
+### Check release status
+
+```bash
+docyrus release status --json
+```
+
+Returns: current version, latest git tag, unreleased commit count, and suggested bump type.
+
+### Create a release (auto-detect bump)
+
+```bash
+docyrus release new-version
+```
+
+Automatically detects the bump type from commits:
+- Breaking changes → **major**
+- New features (`feat:`) → **minor**
+- Fixes and other changes → **patch**
+
+### Create a release with explicit bump
+
+```bash
+docyrus release new-version --bump minor
+```
+
+### Create a release with explicit version
+
+```bash
+docyrus release new-version --version 1.0.0
+```
+
+### Preview a release (dry run)
+
+```bash
+docyrus release new-version --bump minor --dryRun
+```
+
+Shows the changelog preview and version bump without committing any changes.
+
+### Skip specific steps
+
+```bash
+docyrus release new-version --bump patch --skipGithubRelease
+docyrus release new-version --bump minor --skipTag
+docyrus release new-version --bump minor --skipChangelog
+```
+
+## Release Workflow
+
+When `docyrus release new-version` runs, it performs these steps in order:
+
+1. **Read current version** from `package.json`
+2. **Extract commits** since the last git tag
+3. **Detect bump type** (or use the provided one)
+4. **Generate changelog** — categorizes commits into Added/Changed/Fixed/Removed/Security, plus Docyrus Platform changes
+5. **Update CHANGELOG.md** — inserts new version section at the top
+6. **Update package.json** — bumps the version number
+7. **Update project-plan.json** — sets the `projectVersion` field
+8. **Git commit** — `chore(release): vX.Y.Z`
+9. **Git tag** — `vX.Y.Z`
+10. **GitHub release** — creates a release via `gh release create` (requires `gh` CLI)
+
+## Docyrus Platform Changes
+
+The changelog generator automatically detects Docyrus backend modifications:
+
+- New data sources, fields, and enums created via `docyrus studio`
+- Data source architecture changes from `data-sources.plan.json`
+- Knowledge graph updates
+
+These appear under a **Docyrus Platform** section in the changelog.
+
+## Version Initialization
+
+When a project plan is first created, `package.json` is initialized to version `0.1.0`. Each phase and feature is stamped with the current `projectVersion` at creation time.
+
+## After Release
+
+After creating a release, consider:
+- Pushing the commit and tag: `git push && git push --tags`
+- Notifying the team about the new version
+- If authenticated with Docyrus, the release record is automatically created in the platform