ros/automaker
1
0
Fork 0
mirror of https://github.com/AutoMaker-Org/automaker.git synced 2026-02-02 20:43:36 +00:00
Code Issues Packages Projects Releases Wiki Activity

massive overhaul of auth system logic, and subtle fixes to UI

Browse Source
This commit is contained in:
trueheads
2025-12-12 15:59:21 -06:00
parent 0bb774375e
commit 62082fbaf5
11 changed files with 373 additions and 112 deletions
Download Patch File Download Diff File Expand all files Collapse all files

98
apps/app/electron/services/spec-regeneration-service.js
View File

@@ -588,7 +588,7 @@ You should:
4. Based on the user's project overview, create a comprehensive app specification
5. Be liberal and comprehensive when defining features - include everything needed for a complete, polished application
6. Use the XML template format provided
7. Write the specification to .automaker/app_spec.txt
7. **MANDATORY: Write the spec to EXACTLY \`.automaker/app_spec.txt\` - this exact filename, no alternatives**
When analyzing, look at:
- package.json, cargo.toml, requirements.txt or similar config files for tech stack
@@ -598,11 +598,17 @@ When analyzing, look at:
- API structures and patterns
You CAN and SHOULD modify:
- .automaker/app_spec.txt (this is your primary target)
- .automaker/app_spec.txt (this is your ONLY target file - use EXACTLY this filename)
You have access to file reading, writing, and search tools. Use them to understand the codebase and write the new spec.
You have access to file reading, writing, and search tools. Use them to understand the codebase and WRITE the new spec to .automaker/app_spec.txt.
**IMPORTANT:** Focus ONLY on creating the app_spec.txt file. Do NOT create any feature files or use any feature management tools during this phase.`;
**IMPORTANT:** Focus ONLY on creating the app_spec.txt file. Do NOT create any feature files or use any feature management tools during this phase.
**CRITICAL FILE NAMING RULES:**
- The spec file MUST be named exactly \`app_spec.txt\`
- Do NOT create project-spec.md, spec.md, or any other filename
- Do NOT use markdown (.md) extension - use .txt
- The full path must be: \`.automaker/app_spec.txt\``;
}
/**
@@ -639,7 +645,11 @@ ${APP_SPEC_XML_TEMPLATE}
- **development_workflow**: Note any testing or development patterns
- **implementation_roadmap**: Break down the features into phases - be VERY detailed here, listing every feature that needs to be built
4. **IMPORTANT**: Write the complete specification to the file \`.automaker/app_spec.txt\`
4. **MANDATORY FILE WRITE**: You MUST write the spec to EXACTLY this file path: \`.automaker/app_spec.txt\`
- The filename MUST be exactly \`app_spec.txt\` - do NOT use any other name
- Do NOT create \`project-spec.md\`, \`spec.md\`, or any other filename
- Do NOT output the spec in your response - write it to the file
- Use the Write tool with path \`.automaker/app_spec.txt\`
**Guidelines:**
- Be comprehensive! Include ALL features needed for a complete application
@@ -648,8 +658,9 @@ ${APP_SPEC_XML_TEMPLATE}
- The implementation_roadmap should reflect logical phases for building out the app - list EVERY feature individually
- Consider user flows, error states, and edge cases when defining features
- Each phase should have multiple specific, actionable features
- **CRITICAL: Write to EXACTLY \`.automaker/app_spec.txt\` - not project-spec.md or any other name!**
Begin by exploring the project structure.`;
Begin by exploring the project structure, then generate and WRITE the spec to \`.automaker/app_spec.txt\`.`;
}
/**
@@ -848,7 +859,7 @@ You should:
3. Understand the current architecture and patterns used
4. Based on the user's project definition, create a comprehensive app specification that includes ALL features needed to realize their vision
5. Be liberal and comprehensive when defining features - include everything needed for a complete, polished application
6. Write the specification to .automaker/app_spec.txt
6. **MANDATORY: Write the spec to EXACTLY \`.automaker/app_spec.txt\` - this exact filename, no alternatives**
When analyzing, look at:
- package.json, cargo.toml, or similar config files for tech stack
@@ -861,9 +872,15 @@ When analyzing, look at:
Your task is ONLY to update the app_spec.txt file - feature files will be managed separately.
You CAN and SHOULD modify:
- .automaker/app_spec.txt (this is your primary target)
- .automaker/app_spec.txt (this is your ONLY target file - use EXACTLY this filename)
You have access to file reading, writing, and search tools. Use them to understand the codebase and write the new spec.`;
You have access to file reading, writing, and search tools. Use them to understand the codebase and WRITE the new spec to .automaker/app_spec.txt.
**CRITICAL FILE NAMING RULES:**
- The spec file MUST be named exactly \`app_spec.txt\`
- Do NOT create project-spec.md, spec.md, or any other filename
- Do NOT use markdown (.md) extension - use .txt
- The full path must be: \`.automaker/app_spec.txt\``;
}
/**
@@ -892,37 +909,40 @@ ${projectDefinition}
- Think about user experience, error handling, edge cases, etc.
- Architecture Notes: Any important architectural decisions or patterns
3. **IMPORTANT**: Write the complete specification to the file \`.automaker/app_spec.txt\`
3. **MANDATORY FILE WRITE**: You MUST write the spec to EXACTLY this file path: \`.automaker/app_spec.txt\`
- The filename MUST be exactly \`app_spec.txt\` - do NOT use any other name
- Do NOT create \`project-spec.md\`, \`spec.md\`, or any other filename
- Do NOT output the spec in your response - write it to the file
- Use the Write tool with path \`.automaker/app_spec.txt\`
**Format Guidelines for the Spec:**
**Format Guidelines for the Spec (use XML format in app_spec.txt):**
Use this general structure:
Use this XML structure inside app_spec.txt:
\`\`\`
# [App Name] - Application Specification
## Product Overview
[Description of what the app does and its purpose]
## Tech Stack
- Frontend: [frameworks, libraries]
- Backend: [frameworks, APIs]
- Database: [if applicable]
- Other: [other relevant tech]
## Features
### [Category 1]
- **[Feature Name]**: [Detailed description of the feature]
- **[Feature Name]**: [Detailed description]
...
### [Category 2]
- **[Feature Name]**: [Detailed description]
...
## Architecture Notes
[Any important architectural notes, patterns, or conventions]
\`\`\`xml
<project_specification>
<project_name>[App Name]</project_name>
<overview>
[Description of what the app does and its purpose]
</overview>
<technology_stack>
<frontend>[frameworks, libraries]</frontend>
<backend>[frameworks, APIs]</backend>
<database>[if applicable]</database>
</technology_stack>
<core_capabilities>
[List all the major capabilities]
</core_capabilities>
<implementation_roadmap>
<phase_1>[Foundation features]</phase_1>
<phase_2>[Core features]</phase_2>
<phase_3>[Polish features]</phase_3>
</implementation_roadmap>
</project_specification>
\`\`\`
**Remember:**
@@ -930,9 +950,9 @@ Use this general structure:
- Consider user flows, error states, loading states, etc.
- Include authentication, authorization if relevant
- Think about what would make this a polished, production-ready app
- The more detailed and complete the spec, the better
- **CRITICAL: Write to EXACTLY \`.automaker/app_spec.txt\` - not project-spec.md or any other name!**
Begin by exploring the project structure.`;
Begin by exploring the project structure, then generate and WRITE the spec to \`.automaker/app_spec.txt\`.`;
}
/**

2
apps/app/src/components/views/analysis-view.tsx
View File

@@ -399,7 +399,7 @@ ${Object.entries(projectAnalysis.filesByExtension)
`;
// Write the spec file
const specPath = `${currentProject.path}/app_spec.txt`;
const specPath = `${currentProject.path}/.automaker/app_spec.txt`;
const writeResult = await api.writeFile(specPath, specContent);
if (writeResult.success) {

4
apps/app/src/components/views/kanban-card.tsx
View File

@@ -207,10 +207,12 @@ export const KanbanCard = memo(function KanbanCard({
// - Backlog items can always be dragged
// - skipTests items can be dragged even when in_progress or verified (unless currently running)
// - waiting_approval items can always be dragged (to allow manual verification via drag)
// - Non-skipTests (TDD) items in progress or verified cannot be dragged
// - verified items can always be dragged (to allow moving back to waiting_approval or backlog)
// - Non-skipTests (TDD) items in progress cannot be dragged (they are running)
const isDraggable =
feature.status === "backlog" ||
feature.status === "waiting_approval" ||
feature.status === "verified" ||
(feature.skipTests && !isCurrentAutoTask);
const {
attributes,

4
apps/app/src/components/views/settings-view/api-keys/authentication-status-display.tsx
View File

@@ -61,13 +61,15 @@ export function AuthenticationStatusDisplay({
{claudeAuthStatus.method === "oauth_token_env"
? "Using CLAUDE_CODE_OAUTH_TOKEN"
: claudeAuthStatus.method === "oauth_token"
? "Using stored OAuth token (claude login)"
? "Using stored OAuth token (subscription)"
: claudeAuthStatus.method === "api_key_env"
? "Using ANTHROPIC_API_KEY"
: claudeAuthStatus.method === "api_key"
? "Using stored API key"
: claudeAuthStatus.method === "credentials_file"
? "Using credentials file"
: claudeAuthStatus.method === "cli_authenticated"
? "Using Claude CLI authentication"
: `Using ${claudeAuthStatus.method || "detected"} authentication`}
</span>
</div>

4
apps/app/src/components/views/settings-view/hooks/use-cli-status.ts
View File

@@ -74,8 +74,8 @@ export function useCliStatus() {
apiKeyValid?: boolean;
};
// Map server method names to client method types
// Server returns: oauth_token_env, oauth_token, api_key_env, api_key, credentials_file, none
const validMethods = ["oauth_token_env", "oauth_token", "api_key", "api_key_env", "credentials_file", "none"] as const;
// Server returns: oauth_token_env, oauth_token, api_key_env, api_key, credentials_file, cli_authenticated, none
const validMethods = ["oauth_token_env", "oauth_token", "api_key", "api_key_env", "credentials_file", "cli_authenticated", "none"] as const;
type AuthMethod = typeof validMethods[number];
const method: AuthMethod = validMethods.includes(auth.method as AuthMethod)
? (auth.method as AuthMethod)

2
apps/app/src/components/views/setup-view/hooks/use-cli-status.ts
View File

@@ -40,6 +40,8 @@ export function useCliStatus({
"oauth_token",
"api_key",
"api_key_env",
"credentials_file",
"cli_authenticated",
"none",
] as const;
type AuthMethod = (typeof validMethods)[number];

41
apps/app/src/components/views/spec-view.tsx
View File

@@ -14,7 +14,8 @@ import {
DialogHeader,
DialogTitle,
} from "@/components/ui/dialog";
import { Save, RefreshCw, FileText, Sparkles, Loader2, FilePlus2, AlertCircle, ListPlus } from "lucide-react";
import { Save, RefreshCw, FileText, Sparkles, Loader2, FilePlus2, AlertCircle, ListPlus, CheckCircle2 } from "lucide-react";
import { toast } from "sonner";
import { Checkbox } from "@/components/ui/checkbox";
import { XmlSyntaxEditor } from "@/components/ui/xml-syntax-editor";
import type { SpecRegenerationEvent } from "@/types/electron";
@@ -311,14 +312,22 @@ export function SpecView() {
// The backend sends explicit signals for completion:
// 1. "All tasks completed" in the message
// 2. [Phase: complete] marker in logs
// 3. "Spec regeneration complete!" for regeneration
// 4. "Initial spec creation complete!" for creation without features
const isFinalCompletionMessage = event.message?.includes("All tasks completed") ||
event.message === "All tasks completed!" ||
event.message === "All tasks completed";
event.message === "All tasks completed" ||
event.message === "Spec regeneration complete!" ||
event.message === "Initial spec creation complete!";
const hasCompletePhase = logsRef.current.includes("[Phase: complete]");
// Intermediate completion means features are being generated after spec creation
const isIntermediateCompletion = event.message?.includes("Features are being generated") ||
event.message?.includes("features are being generated");
// Rely solely on explicit backend signals
const shouldComplete = isFinalCompletionMessage || hasCompletePhase;
const shouldComplete = (isFinalCompletionMessage || hasCompletePhase) && !isIntermediateCompletion;
if (shouldComplete) {
// Fully complete - clear all states immediately
@@ -337,9 +346,29 @@ export function SpecView() {
setProjectOverview("");
setErrorMessage("");
stateRestoredRef.current = false;
// Reload the spec to show the new content
loadSpec();
} else {
// Reload the spec with delay to ensure file is written to disk
setTimeout(() => {
loadSpec();
}, SPEC_FILE_WRITE_DELAY);
// Show success toast notification
const isRegeneration = event.message?.includes("regeneration");
const isFeatureGeneration = event.message?.includes("Feature generation");
toast.success(
isFeatureGeneration
? "Feature Generation Complete"
: isRegeneration
? "Spec Regeneration Complete"
: "Spec Creation Complete",
{
description: isFeatureGeneration
? "Features have been created from the app specification."
: "Your app specification has been saved.",
icon: <CheckCircle2 className="w-4 h-4" />,
}
);
} else if (isIntermediateCompletion) {
// Intermediate completion - keep state active for feature generation
setIsCreating(true);
setIsRegenerating(true);

1
apps/app/src/store/setup-store.ts
View File

@@ -17,6 +17,7 @@ export type ClaudeAuthMethod =
| "api_key_env" // ANTHROPIC_API_KEY environment variable
| "api_key" // Manually stored API key
| "credentials_file" // Generic credentials file detection
| "cli_authenticated" // Claude CLI is installed and has active sessions/activity
| "none";
// Claude Auth Status