codiedev 0.8.0 → 0.8.1

package/dist/cli.js

@@ -69,7 +69,6 @@ Artifacts:
                                          "single repo or multiple? where?", then
                                          emits a plan with N+1 split. Lands in
                                          /portal/research/<id>; push to Jira from there.
-                                         Beta — opt-in via betaCreateTicket.
   codiedev create-ticket --submit <path|->
                                          Internal: Claude calls this itself with
                                          a plan JSON to submit. Use - for stdin.
@@ -266,8 +265,6 @@ codiedev create-ticket — forward-write a scoped ticket plan
   Single ticket renders as one ticket; multi-ticket renders as a folder/group.
   Push to Jira from the portal.
 
-  Beta. Opt-in by setting userProfiles.betaCreateTicket = true on your row.
-
   Examples:
     codiedev create-ticket
     codiedev create-ticket "I want to add Google SSO"

package/dist/commands/createTicket.js

@@ -155,13 +155,7 @@ async function runBare(config, prompt) {
         res = await (0, shared_1.apiRequest)("GET", "/api/cli/createTicketProtocol", { config });
     }
     catch (err) {
-        const status = err.status;
-        if (status === 403) {
-            console.error("create-ticket is in beta and not enabled for your account. Ask your CodieDev admin to flip betaCreateTicket on your profile.");
-        }
-        else {
-            console.error(`Failed to fetch create-ticket protocol: ${err.message}. Check your network connection and re-run.`);
-        }
+        console.error(`Failed to fetch create-ticket protocol: ${err.message}. Check your network connection and re-run.`);
         process.exit(1);
     }
     process.stdout.write(substitutePrompt(res.protocol, prompt));

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "codiedev",
-  "version": "0.8.0",
+  "version": "0.8.1",
   "description": "Connect Claude Code, Codex, Cursor, or VS Code Copilot to CodieDev for org-wide session capture and artifact collaboration",
   "bin": {
     "codiedev": "dist/cli.js",

package/dist/createTicketSkill.d.ts

@@ -1,12 +0,0 @@
-/**
- * Skill instructions printed to stdout when `codiedev create-ticket` is
- * invoked without `--submit`. Claude (running the CLI via Bash) reads
- * this content and follows the protocol: ask the dev about repos,
- * investigate locally, emit a plan, call back into the CLI to submit.
- *
- * The scoping rules (#### TICKET QUALITY BAR onwards) are lifted verbatim
- * from `modal/runner.py:_format_ticket_from_analysis` so the CLI path
- * produces structurally-identical plans to the Modal path.
- */
-export declare const CREATE_TICKET_SKILL_INSTRUCTIONS = "\nYou are conducting a forward ticket-writing session for the user via codiedev.\nFollow this protocol exactly. Do not improvise the ticket structure.\n\n## Step 1 \u2014 Ask about repos\nAsk the user once:\n  \"Is this work in a single repo or across multiple? If multiple, please tell me where each one is located on disk.\"\nWait for their reply. They will give you absolute paths like /Users/x/code/foo.\n\n## Step 2 \u2014 Investigate (read-only)\nFor each repo path the user gave you:\n  - cd into the repo\n  - Read the user's intent (their prompt, given below)\n  - Find the primary files related to that intent. Use grep for class names,\n    function names, enum values, constants, file names extracted from the prompt.\n  - For each file found, report what it contains: function signatures, enum\n    values, switch/case statements, existing patterns.\n  - Grep for who imports each file (consumers, dependencies).\n  - Check for existing tests related to those files.\n  - Note migration patterns, naming conventions, barrel exports.\nDO NOT modify any files. This is read-only.\n\n## Step 2.5 \u2014 Ask if the prompt doesn't match the codebase\n\nBefore writing the plan, check: do the user's literal words appear in the codebase as named?\n\n- If they said \"delete X\" but only \"archive X\" / \"setArchived\" exists, ask one question quoting\n  both sides: \"You said `delete`, but I see only `setArchived` \u2014 confirm the modal is for the\n  archive button?\"\n- If they said \"the analytics dashboard\" but the named component (e.g. AnalyticsTab) is already\n  reactive and the only useEffect-fetch lives elsewhere, ask: \"AnalyticsTab is already on\n  useQuery; the only useEffect-fetch I found is in admin/page.tsx LangfuseCostsSection \u2014 is\n  that the target?\"\n- If they named a feature/flag/component that doesn't exist at all, ask which of the closest\n  matches they meant, listing each with a one-line reason it's plausible.\n\nDo NOT silently route to the closest match in these cases. Silently routing buries the mismatch\nin scope OUT and produces a ticket the user didn't ask for. One targeted question that quotes\nthe user's word AND the codebase's actual word is the right move.\n\nIf you also have a separate genuine ambiguity (two plausible places the change could go that\nboth match the user's words), bundle it into the same question \u2014 but don't fabricate ambiguity\nto hit a quota. If the words map to the codebase clearly, do not ask further questions \u2014\nproceed to Step 3.\n\n## Step 3 \u2014 Format the plan\n\nThe user's request defines WHAT to build. The investigation defines HOW to build it.\nYour job is to translate the user's exact request into actionable tickets using\nthe investigation as supporting evidence. The user chose their words carefully \u2014\nuse them.\n\nOutput a plan as one or more tickets. Each ticket becomes a single PR handled\nby a coding agent. The agent works alone and makes one PR per ticket.\n\nEACH TICKET = ONE MERGEABLE PR\nA ticket is ready when its PR can merge to main and the app compiles, renders,\nand passes tests with zero other tickets merged. This is the only rule that matters.\n\nHow to group work:\n- The investigation identified every file that needs to change. Your job is to\n  package that into tickets, not to re-scope. Every file from the investigation\n  appears in at least one ticket.\n- Each ticket becomes one PR. A PR should be focused enough that a reviewer\n  understands it in one sitting and CI validates it fully.\n- Include every file needed for the change to be complete \u2014 don't leave wiring,\n  migrations, or consumer updates for a follow-up.\n- If the work naturally spans independent modules, output multiple tickets ordered\n  by dependency. Use the `dependsOn` field (array of zero-indexed ticket numbers\n  this ticket depends on).\n- \"After this PR merges, the app:\" must describe a working state. If you can't,\n  the ticket is incomplete \u2014 add what's missing.\n- Default to ONE ticket. Only split when ticket 2 could merge to main without\n  ticket 1 and the app still compiles.\n\nQUALITY BAR \u2014 every ticket must:\n- Quantify the problem: count the calls, files, violations. \"6 manager.getRepository()\n  calls\", not \"several calls\".\n- Name the codebase's own patterns: use the exact class names, method names, and\n  conventions found in the investigation. \"injectable wrapper pattern with\n  @InjectRepository\", not \"create a new class\".\n- Include specific file paths with line numbers from the investigation findings.\n- Say what stays the same: \"Keep standard CRUD in AceService\", \"do not export it\",\n  \"no logic changes\".\n- Scope IN/OUT must reference concrete things in the codebase, not abstract categories.\n\nFor each ticket, fill these fields:\n  - title: <80 chars, imperative mood\n  - description: GIVEN/WHEN/THEN format, quantify the problem\n  - technicalDetails: specific files with line numbers, the approach,\n    patterns from the codebase to follow, what to keep unchanged\n  - scope: IN: ... / OUT: ...\n  - targetRepoId: leave empty for now \u2014 the CLI will fill this from the repo paths\n  - targetRepoFullName: \"owner/name\" matching the git remote of the repo this\n    ticket touches (e.g. \"ericlam1114/vm-demo\")\n  - dependsOn: [zero-indexed ticket numbers] or [] if independent\n\n## Step 4 \u2014 Submit\nWhen the plan is ready, write it to a temp file as JSON matching this schema:\n\n{\n  \"plan\": {\n    \"summary\": \"<one sentence: what this plan delivers and how many tickets>\",\n    \"tickets\": [\n      {\n        \"title\": \"...\",\n        \"description\": \"...\",\n        \"technicalDetails\": \"...\",\n        \"scope\": \"...\",\n        \"targetRepoFullName\": \"owner/name\",\n        \"dependsOn\": []\n      }\n    ]\n  },\n  \"prompt\": \"<the user's original intent verbatim>\",\n  \"repoFullNames\": [\"owner/name\", ...]\n}\n\nThen run:\n  codiedev create-ticket --submit <path-to-temp-file.json>\n\nThe CLI will translate `targetRepoFullName` and `repoFullNames` into repo IDs,\nPOST the plan, and print the portal URL. Tell the user the URL when it returns.\n\n## The user's intent\n{{USER_PROMPT}}\n";
-export declare function renderSkillInstructions(prompt: string | undefined): string;

package/dist/createTicketSkill.js

@@ -1,146 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.CREATE_TICKET_SKILL_INSTRUCTIONS = void 0;
-exports.renderSkillInstructions = renderSkillInstructions;
-/**
- * Skill instructions printed to stdout when `codiedev create-ticket` is
- * invoked without `--submit`. Claude (running the CLI via Bash) reads
- * this content and follows the protocol: ask the dev about repos,
- * investigate locally, emit a plan, call back into the CLI to submit.
- *
- * The scoping rules (#### TICKET QUALITY BAR onwards) are lifted verbatim
- * from `modal/runner.py:_format_ticket_from_analysis` so the CLI path
- * produces structurally-identical plans to the Modal path.
- */
-exports.CREATE_TICKET_SKILL_INSTRUCTIONS = `
-You are conducting a forward ticket-writing session for the user via codiedev.
-Follow this protocol exactly. Do not improvise the ticket structure.
-
-## Step 1 — Ask about repos
-Ask the user once:
-  "Is this work in a single repo or across multiple? If multiple, please tell me where each one is located on disk."
-Wait for their reply. They will give you absolute paths like /Users/x/code/foo.
-
-## Step 2 — Investigate (read-only)
-For each repo path the user gave you:
-  - cd into the repo
-  - Read the user's intent (their prompt, given below)
-  - Find the primary files related to that intent. Use grep for class names,
-    function names, enum values, constants, file names extracted from the prompt.
-  - For each file found, report what it contains: function signatures, enum
-    values, switch/case statements, existing patterns.
-  - Grep for who imports each file (consumers, dependencies).
-  - Check for existing tests related to those files.
-  - Note migration patterns, naming conventions, barrel exports.
-DO NOT modify any files. This is read-only.
-
-## Step 2.5 — Ask if the prompt doesn't match the codebase
-
-Before writing the plan, check: do the user's literal words appear in the codebase as named?
-
-- If they said "delete X" but only "archive X" / "setArchived" exists, ask one question quoting
-  both sides: "You said \`delete\`, but I see only \`setArchived\` — confirm the modal is for the
-  archive button?"
-- If they said "the analytics dashboard" but the named component (e.g. AnalyticsTab) is already
-  reactive and the only useEffect-fetch lives elsewhere, ask: "AnalyticsTab is already on
-  useQuery; the only useEffect-fetch I found is in admin/page.tsx LangfuseCostsSection — is
-  that the target?"
-- If they named a feature/flag/component that doesn't exist at all, ask which of the closest
-  matches they meant, listing each with a one-line reason it's plausible.
-
-Do NOT silently route to the closest match in these cases. Silently routing buries the mismatch
-in scope OUT and produces a ticket the user didn't ask for. One targeted question that quotes
-the user's word AND the codebase's actual word is the right move.
-
-If you also have a separate genuine ambiguity (two plausible places the change could go that
-both match the user's words), bundle it into the same question — but don't fabricate ambiguity
-to hit a quota. If the words map to the codebase clearly, do not ask further questions —
-proceed to Step 3.
-
-## Step 3 — Format the plan
-
-The user's request defines WHAT to build. The investigation defines HOW to build it.
-Your job is to translate the user's exact request into actionable tickets using
-the investigation as supporting evidence. The user chose their words carefully —
-use them.
-
-Output a plan as one or more tickets. Each ticket becomes a single PR handled
-by a coding agent. The agent works alone and makes one PR per ticket.
-
-EACH TICKET = ONE MERGEABLE PR
-A ticket is ready when its PR can merge to main and the app compiles, renders,
-and passes tests with zero other tickets merged. This is the only rule that matters.
-
-How to group work:
-- The investigation identified every file that needs to change. Your job is to
-  package that into tickets, not to re-scope. Every file from the investigation
-  appears in at least one ticket.
-- Each ticket becomes one PR. A PR should be focused enough that a reviewer
-  understands it in one sitting and CI validates it fully.
-- Include every file needed for the change to be complete — don't leave wiring,
-  migrations, or consumer updates for a follow-up.
-- If the work naturally spans independent modules, output multiple tickets ordered
-  by dependency. Use the \`dependsOn\` field (array of zero-indexed ticket numbers
-  this ticket depends on).
-- "After this PR merges, the app:" must describe a working state. If you can't,
-  the ticket is incomplete — add what's missing.
-- Default to ONE ticket. Only split when ticket 2 could merge to main without
-  ticket 1 and the app still compiles.
-
-QUALITY BAR — every ticket must:
-- Quantify the problem: count the calls, files, violations. "6 manager.getRepository()
-  calls", not "several calls".
-- Name the codebase's own patterns: use the exact class names, method names, and
-  conventions found in the investigation. "injectable wrapper pattern with
-  @InjectRepository", not "create a new class".
-- Include specific file paths with line numbers from the investigation findings.
-- Say what stays the same: "Keep standard CRUD in AceService", "do not export it",
-  "no logic changes".
-- Scope IN/OUT must reference concrete things in the codebase, not abstract categories.
-
-For each ticket, fill these fields:
-  - title: <80 chars, imperative mood
-  - description: GIVEN/WHEN/THEN format, quantify the problem
-  - technicalDetails: specific files with line numbers, the approach,
-    patterns from the codebase to follow, what to keep unchanged
-  - scope: IN: ... / OUT: ...
-  - targetRepoId: leave empty for now — the CLI will fill this from the repo paths
-  - targetRepoFullName: "owner/name" matching the git remote of the repo this
-    ticket touches (e.g. "ericlam1114/vm-demo")
-  - dependsOn: [zero-indexed ticket numbers] or [] if independent
-
-## Step 4 — Submit
-When the plan is ready, write it to a temp file as JSON matching this schema:
-
-{
-  "plan": {
-    "summary": "<one sentence: what this plan delivers and how many tickets>",
-    "tickets": [
-      {
-        "title": "...",
-        "description": "...",
-        "technicalDetails": "...",
-        "scope": "...",
-        "targetRepoFullName": "owner/name",
-        "dependsOn": []
-      }
-    ]
-  },
-  "prompt": "<the user's original intent verbatim>",
-  "repoFullNames": ["owner/name", ...]
-}
-
-Then run:
-  codiedev create-ticket --submit <path-to-temp-file.json>
-
-The CLI will translate \`targetRepoFullName\` and \`repoFullNames\` into repo IDs,
-POST the plan, and print the portal URL. Tell the user the URL when it returns.
-
-## The user's intent
-{{USER_PROMPT}}
-`;
-function renderSkillInstructions(prompt) {
-    return exports.CREATE_TICKET_SKILL_INSTRUCTIONS.replace("{{USER_PROMPT}}", prompt && prompt.length > 0
-        ? prompt
-        : "(not yet provided — ask the user a single combined question that covers both the intent AND repo locations: \"What are you working on, and is this in a single repo or multiple? If multiple, give me the paths.\" Skip Step 1 since you've folded it into this question. Then proceed to Step 2.)");
-}