waypoint-codex 0.9.6 → 0.9.8

package/dist/src/core.js

@@ -106,6 +106,8 @@ function scaffoldOptionalCodex(projectRoot) {
 export function initRepository(projectRoot, options) {
     ensureDir(projectRoot);
     migrateLegacyRootFiles(projectRoot);
+    // Any Waypoint-owned path removed from the scaffold should be added here
+    // so `waypoint init` / `waypoint upgrade` can actively prune stale copies.
     for (const deprecatedPath of [
         "docs/README.md",
         "docs/code-guide.md",
@@ -128,6 +130,7 @@ export function initRepository(projectRoot, options) {
         ".codex/agents/reviewer.toml",
         ".codex/agents/architect.toml",
         ".codex/agents/implementer.toml",
+        ".waypoint/agents",
         ".waypoint/automations",
         ".waypoint/rules",
         ".waypoint/state",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "waypoint-codex",
-  "version": "0.9.6",
+  "version": "0.9.8",
   "description": "Codex-native repository operating system: scaffolding, docs routing, repo-local skills, doctor, and sync.",
   "license": "MIT",
   "type": "module",

package/templates/.agents/skills/backend-context-interview/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: backend-context-interview
-description: Gather and persist durable backend project context when missing or insufficient for implementation, architecture decisions, or ship-readiness review. Use when backend choices depend on scale, criticality, compliance, tenant model, compatibility, reliability, security posture, or similar context that is not clearly documented.
+description: Gather and persist durable backend project context when missing or insufficient for implementation, architecture decisions, or ship-readiness review. Use this to ask project-level questions about deployment reality, scale, criticality, compatibility, tenant model, security posture, reliability expectations, and other durable backend context that is not clearly documented. This is not a feature-discovery skill.
 ---
 
 # Backend Context Interview
 
-Use this skill when relevant backend context is missing, stale, contradictory, or too weak to support correct implementation or review decisions.
+Use this skill when relevant backend project context is missing, stale, contradictory, or too weak to support correct implementation or review decisions.
 
 ## Goals
 
@@ -14,6 +14,8 @@ Use this skill when relevant backend context is missing, stale, contradictory, o
 3. persist durable context into the project root guidance file
 4. avoid repeated questioning in future tasks
 
+This skill is for project-level operating context, not feature requirements gathering.
+
 ## When to use
 
 Use this skill when the current task depends on context such as:
@@ -29,6 +31,7 @@ Use this skill when the current task depends on context such as:
 - infrastructure constraints that materially affect design
 
 Do not use this skill when the answer is already clearly present in `AGENTS.md`, architecture docs, runbooks, or the task itself.
+Do not use this skill to ask about feature-specific behavior, UX details, endpoint shapes, acceptance criteria, implementation preferences, or other concrete requirements that belong in planning or normal task clarification.
 
 ## Workflow
 
@@ -57,6 +60,7 @@ Good triggers:
 - tenant model changes authorization and data-isolation design
 
 Do not ask broad or low-value questions.
+Do not ask feature-specific product questions.
 
 ### 3. Ask concise grouped questions
 
@@ -68,3 +72,9 @@ Suggested categories:
 - data sensitivity and compliance
 
 Do not ask generic product questions that do not affect backend engineering.
+Do ask project-level questions like:
+- whether the product is internal, customer-facing, partner-facing, or public
+- whether there are real users yet or only development/staging use
+- expected traffic, concurrency, or import/job intensity
+- whether backward compatibility is required
+- how costly outages, corruption, or security mistakes would be

package/templates/.agents/skills/frontend-context-interview/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: frontend-context-interview
-description: Gather and persist durable frontend project context when missing or insufficient for implementation or review work. Use when frontend decisions depend on product type, audience, support matrix, accessibility, SEO, localization, design-system constraints, or similar context that is not clearly documented.
+description: Gather and persist durable frontend project context when missing or insufficient for implementation or review work. Use this to ask project-level questions about audience, deployment surface, browser/device expectations, accessibility, SEO, localization, analytics obligations, and other durable frontend context that is not clearly documented. This is not a feature-discovery skill.
 ---
 
 # Frontend Context Interview
 
-Use this skill when relevant frontend context is missing, stale, contradictory, or too weak to support correct implementation or review decisions.
+Use this skill when relevant frontend project context is missing, stale, contradictory, or too weak to support correct implementation or review decisions.
 
 ## Goals
 
@@ -14,6 +14,8 @@ Use this skill when relevant frontend context is missing, stale, contradictory,
 3. persist durable context into the project root guidance file
 4. avoid repeated questioning in future tasks
 
+This skill is for project-level operating context, not feature requirements gathering.
+
 ## When to use
 
 Use this skill when the current task depends on context such as:
@@ -29,6 +31,7 @@ Use this skill when the current task depends on context such as:
 - security or privacy expectations that change frontend behavior
 
 Do not use this skill when the answer is already clearly present in `AGENTS.md`, product docs, or the task itself.
+Do not use this skill to ask about feature-specific UX, copy, flows, acceptance criteria, implementation preferences, or detailed product behavior that belongs in planning or normal task clarification.
 
 ## Workflow
 
@@ -58,3 +61,12 @@ Good triggers:
 
 Do not ask broad or low-value questions.
 Do not ask generic discovery questions that do not affect implementation.
+Do not ask feature-specific product questions.
+
+Good project-level question areas include:
+- whether the product is internal, customer-facing, partner-facing, or public marketing
+- whether there are real users yet or only development/staging use
+- expected device mix and browser support
+- accessibility expectations or compliance targets
+- whether SEO matters for any routes
+- whether backward compatibility in user workflows matters

package/templates/managed-agents-block.md

@@ -52,9 +52,10 @@ Examples of durable context that can materially change the correct approach:
 
 If relevant context is missing, empty, stale, or insufficient and that gap would materially change the correct approach:
 - do not guess silently
-- use `frontend-context-interview` when frontend or product-surface context is missing
-- use `backend-context-interview` when backend, reliability, tenant, compatibility, or security context is missing
+- use `frontend-context-interview` when project-level frontend context is missing
+- use `backend-context-interview` when project-level backend context is missing
 - ask only the missing high-leverage questions
+- ask about the project, deployment reality, and operating constraints rather than the concrete feature
 - persist only durable context back into the project guidance file
 - do not write transient task-specific details into context sections