Career Evidence

Career Evidence reconstructs engineering work history by connecting tasks from ClickUp, Linear, or Jira Cloud with branches, commits, and changes across Git repositories. Review the results in the CLI or bundled local Web UI, then export a detailed evidence dataset and compact task summaries.

The Web UI described here is the dashboard served on your computer by this CLI. This guide includes installation, integration setup, configuration, and troubleshooting for the installed package.

• Recover implementation history across several repositories, including available merged-branch and PR/MR evidence.
• Inspect suggested task-to-code links and confirm or exclude them yourself.
• Add manual context, review technical summaries, and export JSON for later use.
• Start without AI; optionally use a local model or remote AI service for summaries and candidate ranking.

The tool does not generate résumés, assign career levels, or establish business impact. Suggested links and model conclusions need review against the collected sources.

Contents

• Example result
• Quick start
  • Prepare access
  • Install and initialize
  • Replace the template with this minimal configuration
  • Run and view the result
• Everyday CLI workflows
  • Repeated runs
• Local Web UI
• Integrations and analysis modes
• Configuration and paths
• Connection recipes
  • Linear
  • Jira Cloud
  • Task filters and connection checks
  • Existing checkouts and managed clones
  • GitHub PR enrichment
  • GitLab MR enrichment
  • Bitbucket Cloud PR enrichment
• Evidence matching
  • Optional AI ranking
• AI setup
  • Analysis settings and budgets
  • Updating older configuration
• Results and exports
• Data and privacy
• Limitations and troubleshooting

Example result

This illustrative example is one item from the tasks array in task-summaries.json. It uses synthetic test data to show the analyzed output format, not a real collection or model run:

{
  "taskId": "ABC-123",
  "title": "Checkout",
  "startDate": "2025-12-15T00:00:00.000Z",
  "status": "success",
  "summary": "Implemented checkout handling.",
  "signals": ["architecture", "product-thinking"],
  "role": "Implemented checkout request validation and state handling.",
  "results": ["Checkout requests now reject invalid state transitions."],
  "areas": ["backend"],
  "keyChanges": ["Added checkout validation"],
  "technicalNotes": ["Validated request state"],
  "unknowns": [],
  "details": {}
}

Without AI, the same file contains conservative summaries derived from commit subjects and changed paths; signals and results stay empty and the personal role stays unknown. The detailed export separately retains task data, Git evidence, matching decisions, and analysis provenance.

Quick start: ClickUp and an existing Git checkout, without AI

1. Prepare access

You need:

• Node.js 20 or newer, npm, and Git available on PATH.
• A ClickUp personal API token with access to the relevant workspace, tasks, and comments; the workspace ID and assignee user ID(s) to collect.
• An existing Git working tree with committed history and an available base branch, such as main.

Create a token in ClickUp's Settings → Apps → API Token; see ClickUp authentication. GET /api/v2/team (authorized workspaces) and GET /api/v2/user (authenticated user) can identify your workspace and your own user ID. Historical assignee IDs require a token that can still see their tasks.

This scenario contacts ClickUp. It needs no SCM API token or AI service. For useful automatic links, your Git history should reference the collected task IDs in branch names or commit messages; contextual suggestions may require confirmation. Tasks without matching changes retain an explanation of missing evidence.

For Linear or Jira, use the connection recipes below.

2. Install and initialize

Run from any directory; you do not need to clone Career Evidence or enter your source repository:

npm install -g @career-evidence/cli
career-evidence init
career-evidence config path

The @career-evidence/cli package installs the career-evidence command and its alias ce. By default, init creates ~/.config/career-evidence/config.json and preserves an existing file. Use ce init --force only to replace it with a fresh template. config path prints actual configuration and data locations, including XDG overrides.

3. Replace the template with this minimal configuration

Open the printed config file in your editor. The generated template enables remote AI and GitHub enrichment; replace it before running this no-AI scenario:

{
  "projects": {
    "my-project": {
      "taskSource": {
        "provider": "clickup",
        "apiKey": "<clickup-personal-api-token>",
        "workspaceId": "123456",
        "userIds": ["789"]
      },
      "scm": {
        "provider": "github",
        "enabled": false,
        "apiKey": "",
        "repositories": [
          {
            "name": "application",
            "localPath": "/absolute/path/to/your/repository",
            "baseBranches": ["main"],
            "enrichment": false
          }
        ]
      },
      "analysis": {
        "enabled": false
      }
    }
  }
}

Replace the token, workspace ID, user ID, and repository path with your values. Set baseBranches to branches available in that checkout; localPath must be absolute, without ~. my-project is your chosen project name and the argument in later commands. ClickUp includes completed tasks by default and filters by the supplied assignee IDs.

The schema requires a valid scm.provider selector even with its API disabled; this example uses "github". Keep both scm.enabled: false and repository enrichment: false. Local Git collection still works for checkouts from other hosts. The checkout is read in place without fetching or switching branches; uncommitted changes are ignored.

Credentials are direct values in this JSON file. Keep it private and out of version control. Environment-variable substitution and automatic .env loading are not supported.

4. Run and view the result

career-evidence config validate my-project
career-evidence run my-project
career-evidence web

Validation checks configuration, Git, and the local checkout; it does not test provider credentials. run collects tasks and evidence, creates deterministic summaries without AI calls, and writes all-tasks.json and task-summaries.json. Look for both Created paths and review any collection warnings.

Open the URL printed by web, normally http://127.0.0.1:4310, and select my-project. You can also open the JSON files directly under ~/.local/share/career-evidence/projects/my-project/ by default. If no tasks appear, see troubleshooting. Press Ctrl+C in the server terminal to stop; an active background job finishes before shutdown.

Everyday CLI workflows

Use career-evidence --help or <command> --help for full options:

For separate analysis after collection, run ce analyze my-project, then ce export my-project. collect can call AI if you explicitly configure AI correlation ranking, even with summary analysis disabled. The quick start uses the default local ranking and makes no AI calls.

Correlation review groups alternative task links by branch, commit, or PR/MR. Select a numbered link and Confirm or Exclude it; Next skips the artifact for this session, Back returns to its alternatives, and Quit leaves the remaining review untouched. Omitting the project selects the only configured project or prompts when several exist.

Decisions are saved in state/correlation-overrides.json and tied to the current artifact revision. Saving a decision rebuilds the affected task from cached source data and checkouts, then updates exports. Updated analysis may call the configured AI provider. Changed artifacts require a new decision. One artifact may legitimately be confirmed for several tasks; rank alone is not proof of implementation.

Repeated runs

ce run my-project checks the task source online, reuses compatible task/SCM caches within their TTLs, and rebuilds evidence and summaries when inputs change. Managed clones fetch updates. localPath checkouts use only available local history; fetch them yourself to include newer remote refs.

• ce run my-project --force bypasses collection and analysis caches. With AI configured, it can make new paid requests.
• ce run my-project --retry-failed retries failed analysis while preserving reusable successful summaries and intermediate chunks. Changed evidence is reanalyzed regardless. It cannot be combined with --force.
• ce analyze my-project --force regenerates analysis from saved evidence; run ce export my-project afterward.

Exports overwrite all-tasks.json and refresh generated fields in task-summaries.json, preserving manual details and deleted task IDs. A previous valid compact export is saved as task-summaries.backup.json. Edits to generated fields can be replaced by later exports or task Sync; use details for durable context. Narrower source filters do not automatically delete historical evidence or summary rows.

Local Web UI

After initializing a valid config, run career-evidence web (alias ce app) and open the printed loopback URL. Use career-evidence web --port 4500 to choose another port. The installed npm package includes the built UI; no frontend development server or separate database is needed. The server binds to 127.0.0.1, and only one dashboard can use a data directory at a time.

Search tasks, review links, edit summaries, and add manual details. Sync runs the initial collection/analysis/export for a project without summaries. Find new tasks adds tasks without replacing existing rows. A row's Sync refreshes that task's generated fields while preserving details. These actions use configured integrations and may call AI.

Delete hides a summary row and records its ID so later exports and new-task searches do not recreate it. It does not erase raw evidence or delete the remote task. Project creation backs up and updates the local config; edit existing project settings in config.json. Light, Dark (default), and System themes are available.

Background jobs run one at a time and survive restarts: an interrupted running job returns to the queue on the next dashboard start. Ctrl+C finishes the active job and retains later queued jobs. Progress and failures appear in the UI. Correlation review also supports Reset to remove a manual decision. Edit a task's details for durable context about ownership, design, collaboration, delivery, and outcomes; collection and AI never fill these manual fields.

Integrations and analysis modes

• Task sources: ClickUp, Linear, and Jira Cloud on *.atlassian.net, including explicit cloudId routing for scoped tokens. One task source per project, bounded by account visibility and configured scope/assignee filters.
• Local Git: multiple managed clones or existing checkouts per project. SSH keys or HTTPS credential helpers handle Git authentication independently of SCM API credentials.
• Hosting APIs: GitHub PRs, GitLab MRs (including self-managed GitLab), and Bitbucket Cloud PRs. One SCM provider per project. These enrich local Git with review metadata, original commits, and remote diffs when needed; a valid checkout is still required. Jira Server/Data Center and Bitbucket Data Center adapters are not provided.
• AI services: OpenAI, Google Gemini, xAI, Mistral, DeepSeek, Groq, OpenRouter, Alibaba Model Studio, Ollama, and configurable OpenAI-compatible endpoints. Choose an available model explicitly; model discovery is not implemented. External services require suitable access and may charge for usage.

With no AI, set analysis to exactly { "enabled": false } and leave ranking at its default buildIn strategy. Evidence, deterministic summaries, review, editing, and exports remain available.

For local AI, configure Ollama or an OpenAI-compatible local server with an installed model. Ollama defaults to http://localhost:11434/v1. Local processing depends on the endpoint and model service you actually use; changing the endpoint or using a forwarding service may send data elsewhere.

For remote AI, configure the service, API key, and model in analysis.provider. Summary analysis defaults to metadata (task and change metadata); diff additionally sends selected source-code hunks. Independent AI ranking supports metadata, diff, and adaptive; adaptive may escalate uncertain metadata decisions to local diff hunks.

Use the connection recipes for task sources and hosting APIs, and AI setup for provider configuration and budgets. These examples extend the complete quick-start configuration; no additional configuration files are needed.

Configuration and paths

The quick-start JSON is a minimal ClickUp/local-checkout configuration. Add repositories to scm.repositories or projects under projects; repository names within a project must be unique, ignoring case.

Configuration location follows this order:

1. --config <path> selects a file; relative paths resolve from your current directory.
2. Otherwise, an absolute XDG_CONFIG_HOME selects $XDG_CONFIG_HOME/career-evidence/config.json.
3. Otherwise, the file is ~/.config/career-evidence/config.json.

The data root is independently $XDG_DATA_HOME/career-evidence when XDG_DATA_HOME is absolute, otherwise ~/.local/share/career-evidence. Relative XDG values are ignored. --config changes only the config location; the same project name still selects the same data directory. Inspect both with ce --config ./config.json config path.

The selected JSON supplies credentials and analysis settings directly; environment variables do not override them and ${ENV_VAR} is not expanded. No .env is loaded. init, Web config writes, and config backups use mode 0600 where Unix modes are supported. Credentials are plaintext, without application-level encryption; protect backups too.

Defaults include task cache TTL 15 minutes, SCM cache TTL 60 minutes, exact task hierarchy matching, and local buildIn ranking. AI settings come from your JSON; init's template enables it. See evidence matching and AI setup for those settings.

Connection recipes

Start from the complete quick-start configuration. Each fragment below replaces the named block inside projects.my-project; keep the other project blocks. Replace all example credentials, IDs, account names, and URLs with your own values.

Linear

Replace taskSource with:

{
  "taskSource": {
    "provider": "linear",
    "apiKey": "<linear-personal-api-key>",
    "teamIds": ["11111111-1111-4111-8111-111111111111"],
    "userIds": ["22222222-2222-4222-8222-222222222222"]
  }
}

Create a personal API key with read access to the selected teams. teamIds and userIds are UUIDs, not names or public issue identifiers. Authenticated GraphQL queries teams { nodes { id name } }, users { nodes { id name } }, and viewer { id } can help discover them; paginate results where needed. See Linear's API guide. Git matching uses public issue IDs such as CE-123.

Jira Cloud

Replace taskSource with:

{
  "taskSource": {
    "provider": "jira",
    "baseUrl": "https://example.atlassian.net",
    "email": "developer@example.com",
    "apiKey": "<jira-api-token>",
    "projectKeys": ["CE"],
    "userIds": ["<atlassian-account-id>"]
  }
}

Use an Atlassian API token, the account email, and Browse Projects permission for the selected issues/comments. For classic read scopes, use read:jira-work and read:jira-user; granular scopes must cover search, comments, and myself. email authenticates the token; userIds filters assignees by account ID, not display name. The authenticated GET /rest/api/3/myself identifies your account. See Jira authentication.

For a scoped API token, add the site's cloudId to taskSource, for example "cloudId": "33333333-3333-4333-8333-333333333333", replacing that UUID. You can obtain it from your site's /_edge/tenant_info endpoint. Requests then use https://api.atlassian.com/ex/jira/{cloudId}/rest/api/3/; otherwise they use the configured site directly. Token routing is explicit; the CLI does not guess token type. See Atlassian's scoped-token guide.

baseUrl must be an HTTPS *.atlassian.net origin without a path, port, query, or embedded credentials. Jira custom domains and Server/Data Center are not supported. Git matching uses issue keys such as CE-123.

Task filters and connection checks

ClickUp requires workspaceId and nonempty userIds. Several user IDs are queried separately and deduplicated, which can include active and historical accounts when your token can see their tasks. Linear requires nonempty teamIds; Jira requires nonempty projectKeys. For Linear/Jira, omit userIds to collect all assignees in that scope; an explicitly empty array is invalid. Several scope values are ORed, several assignees are ORed, and the two groups are ANDed.

All task sources default to includeClosed: true and cacheTtlMinutes: 15. Linear additionally supports includeArchived, default false. With includeClosed: false, Linear excludes completed/canceled tasks and Jira excludes the Done status category. Hidden tasks/comments cannot be reconstructed. Attachments are not downloaded and external links are not followed.

After editing the configuration, run:

ce config validate my-project
ce collect my-project
ce analyze my-project
ce export my-project

collect is the online connection check; it saves the source snapshot and evidence. With the quick start's local ranking it makes no AI calls. analyze and explicitly enabled AI ranking use their configured providers. Check the printed errors and the files under the data directory from ce config path. To force a source refresh, use ce run my-project --force, accounting for any enabled AI requests.

Existing checkouts and managed clones

The quick start reads an existing localPath without fetching, copying, or changing it. Linked Git worktrees are supported. If you also supply url, the checkout's origin must match that remote identity. Enabling repository enrichment requires url and a matching origin.

To let the CLI clone and update a repository, omit localPath and put an entry like this in scm.repositories:

{
  "name": "backend",
  "url": "git@github.com:your-org/backend.git",
  "baseBranches": ["main"],
  "enrichment": false
}

Replace the URL and base branch with your repository's values. Managed clones live at <projects-directory>/<project>/repositories/<name>/ and collection fetches remote refs. Git clone/fetch authentication uses your SSH setup or Git's HTTPS credential helper. Embedded HTTPS credentials are rejected; do not put tokens in clone URLs. Disabling hosting API enrichment does not disable managed Git synchronization.

GitHub PR enrichment

Replace scm with the following to enable the API and use a managed clone:

{
  "scm": {
    "provider": "github",
    "apiKey": "<github-read-token>",
    "repositories": [
      {
        "name": "application",
        "url": "git@github.com:your-org/your-repository.git",
        "baseBranches": ["main"]
      }
    ]
  }
}

The token needs read access to the repository's pull requests; fine-grained tokens require Pull requests: read for the selected repositories. See GitHub's PR API permissions. API authentication is separate from Git authentication, and existing gh authorization is not loaded automatically. To retain an existing checkout, add its absolute localPath alongside the matching url.

GitLab MR enrichment

Replace scm with:

{
  "scm": {
    "provider": "gitlab",
    "apiKey": "<gitlab-access-token>",
    "repositories": [
      {
        "name": "application",
        "url": "git@gitlab.com:your-group/your-repository.git",
        "baseBranches": ["main"]
      }
    ]
  }
}

Use a personal/project/group access token with read_api and visibility of the project; the CLI sends PRIVATE-TOKEN. Deploy tokens are not supported for MR access. For self-managed GitLab, add scm.apiBaseUrl with the full API root, such as https://gitlab.company.example/api/v4, and use your actual clone URL. The default is https://gitlab.com/api/v4. Repository projectId may be a positive numeric ID or full namespace/project path; supply it explicitly when SSH and API hosts differ. See GitLab authentication.

Bitbucket Cloud PR enrichment

Replace scm with:

{
  "scm": {
    "provider": "bitbucket-cloud",
    "apiKey": "<bitbucket-api-token>",
    "email": "developer@example.com",
    "repositories": [
      {
        "name": "application",
        "url": "git@bitbucket.org:your-workspace/your-repository.git",
        "baseBranches": ["main"]
      }
    ]
  }
}

The API root defaults to https://api.bitbucket.org/2.0. An Atlassian email selects Basic authentication with the API token; omit it for a Bearer access token. API tokens need read:pullrequest:bitbucket and read:repository:bitbucket, or equivalent read permissions for Bearer tokens. Use API tokens rather than app passwords. A repository can override URL inference with both workspace and repoSlug; supply both or neither. See Bitbucket API tokens.

For all hosting providers, scm.enabled and repository enrichment default to true. Set a repository's enrichment: false to skip its hosting API while keeping Git collection. When disabling SCM enrichment, keep the required apiKey field and use "" if no token is needed. Every SCM block still needs at least one repository.

Optional SCM request settings are cacheTtlMinutes (default 60), maxRequestsPerRun (1,000), requestDelayMs (100), and rateLimitReserve (50). GitHub also supports apiBaseUrl, default https://api.github.com. Request budgets and rate limits can defer enrichment while local Git processing continues. When incomplete local evidence needs that enrichment, AI analysis is deferred without a model request; complete local evidence can still be analyzed. A later collection retries enrichment.

Evidence matching

By default, matching uses exact task references and immediate task identity. Contextual candidates show matching terms, paths, and rank for review. Configure optional hierarchy and developer attribution inside your project:

{
  "evidence": {
    "taskHierarchy": "exact",
    "ranking": { "strategy": "buildIn", "minRank": 0 },
    "developer": {
      "gitEmails": ["developer@example.com"],
      "githubLogins": ["your-login"]
    }
  }
}

Replace identities with your own or omit developer. For other hosts use gitlabLogins or bitbucketAccountIds; Bitbucket account UUIDs include braces when returned that way by its API. Identities mark authored/co-authored Git commits and authored PRs/MRs; they do not remove team evidence or establish sole ownership.

taskHierarchy accepts exact (default), include-parent (also the immediate parent's ID), or aggregate-children (also immediate child IDs). Evidence records which task reference caused a match. minRank is an integer from 0 to 100: contextual links below it are excluded while exact references and manual decisions retain priority. Lowering it and collecting again recalculates those exclusions. Built-in contextual candidates require confirmation before contributing implementation evidence.

Optional AI ranking

AI ranking is independent of summary generation. For example, replace evidence with this to rank using a locally installed Ollama model, including when analysis.enabled is false:

{
  "evidence": {
    "ranking": {
      "strategy": "ai",
      "minRank": 50,
      "decisionMode": "review",
      "ai": {
        "mode": "metadata",
        "provider": { "type": "ollama", "model": "<installed-model-id>" }
      }
    }
  }
}

Replace the model ID with one available in your local runtime. Any analysis provider configuration can also be used at evidence.ranking.ai.provider. Omit that provider only when summary analysis is enabled and its provider should be reused. Preserve any other evidence settings you already use.

decisionMode: "review" leaves supported links for manual confirmation. "auto" can accept model-supported links at or above minRank; uncertain/unavailable links still require review. ai.mode is metadata, diff, or adaptive. Adaptive escalates only uncertain metadata decisions to bounded local hunks. Invalid responses, unavailable providers, or exhausted budgets retain candidates for a later retry or manual review.

Ranking budget fields live in evidence.ranking.ai: maxInputChars defaults to 20,000 per payload, maxInputTokensPerRun to 2,500,000, maxOutputTokensPerRequest to 8,192, and maxRequestsPerRun to 100. Adaptive can use two requests per artifact. Valid ranking responses are cached under state/correlation-ranking/; run --force bypasses that cache.

AI setup

Keep analysis: { "enabled": false } for deterministic summaries. To enable local Ollama analysis, replace the project's analysis block with:

{
  "analysis": {
    "enabled": true,
    "mode": "metadata",
    "provider": { "type": "ollama", "model": "<installed-model-id>" }
  }
}

Start your local runtime with the model installed and replace the model ID. Ollama's baseUrl defaults to http://localhost:11434/v1; set it inside provider when your endpoint differs.

For a remote service, use its API key and a model available to your account:

{
  "analysis": {
    "enabled": true,
    "mode": "metadata",
    "provider": {
      "type": "openai",
      "apiKey": "<provider-api-key>",
      "model": "<provider-model-id>"
    }
  }
}

The same apiKey/model provider shape supports openai, gemini, xai, mistral, deepseek, groq, and openrouter; change type and use that service's key/model. alibaba-model-studio additionally requires an explicit baseUrl matching your region/workspace. Qwen or Llama is a model choice under its hosting provider, not a provider type. Native Anthropic Messages API is not supported.

For another OpenAI-compatible server, declare endpoint and authentication explicitly. This example uses Ollama's default local endpoint; replace it with your server's actual API base URL:

{
  "analysis": {
    "enabled": true,
    "provider": {
      "type": "openai-compatible",
      "model": "<provider-model-id>",
      "baseUrl": "http://localhost:11434/v1",
      "authentication": { "type": "none" },
      "outputTokenParameter": "max_tokens"
    }
  }
}

For Bearer authentication, replace authentication with { "type": "bearer", "apiKey": "<provider-api-key>" }. Base URLs must be HTTP(S) without embedded credentials, queries, or fragments; the CLI appends /chat/completions. Select the endpoint's supported output parameter, max_tokens (default) or max_completion_tokens. Named providers choose their own parameter automatically.

Analysis settings and budgets

These optional fields belong beside enabled and provider in analysis:

Lower character limits can create more chunks. Input budgets use a conservative estimate before a call, then provider-reported usage when available; estimates are not exact token counts or prices. Results that omit evidence because of budgets record that in unknowns. A task without usable implementation evidence receives a deterministic result rather than a speculative model summary.

After changing analysis settings, run ce analyze my-project, then ce export my-project. Valid final summaries are reused only while their evidence and analysis configuration match. Model, endpoint, mode, language, or policy changes can regenerate summaries; rotating an API key alone does not invalidate them. Use --force for explicit regeneration. Successful intermediate summaries under state/analysis-chunks/ can be reused with --retry-failed; that cache does not store raw diff text or credentials and is not automatically pruned.

ce usage my-project (or --json) reads request counts, token usage when reported, separately labeled estimates, and workflow/model breakdowns from state/ai-usage.json. History retains up to 500 records; it is local accounting, not a billing statement.

Updating older configuration

Loading config never migrates or rewrites it automatically. If an older file is rejected, update it to the complete quick-start shape and add your desired options above:

• Replace the old clickup block with taskSource, add its provider, and convert userId to a userIds array.
• Move project-level repositories and old github settings into scm; set its provider and use direct apiKey values instead of tokenEnv.
• Put AI service settings inside analysis.provider. Remove old flat analysis fields and environment-reference fields such as apiKeyEnv, modelEnv, or baseUrlEnv. Disabled analysis accepts only { "enabled": false }.

No top-level configuration version is required. Keep repository names and the project name when updating compatible settings to retain the same local artifacts. Validate before running; avoid replacing a configured file with init --force unless you intend to restore the template.

Results and exports

Paths below are relative to the projects directory printed by ce config path, under my-project/:

Both exports are available without AI after run, or after collect, analyze, and export. Every exported task needs a start date: its source start date, otherwise its creation date. Tasks with neither are skipped and logged, as is stale analysis whose evidence fingerprint no longer matches.

To verify a conclusion, inspect analysis.generator, status, unknowns, and evidenceReferences, then follow the corresponding branch, commit hash, or PR in the evidence JSON. Correlation signals retain matched IDs, reasons, and matching decisions. Model summaries are separate from source facts; status: "success" alone does not prove complete reconstruction or personal ownership. Source diffs are available in evidence files, not in the dashboard.

The compact export has version, project, generatedAt, deletedTaskIds, and tasks. Each task has the fields shown in the example result, including manual details. status is success, failed, or deferred; it describes analysis, while evidenceStatus in the detailed export separately describes reconstruction. Deleted IDs suppress compact rows only; all-tasks.json can still contain their evidence.

The controlled signals values are architecture, technical-direction, influence-without-authority, production-incident, reusability, mentoring, knowledge-sharing, developing-others, initiative, developer-productivity, and product-thinking. AI is instructed to select only supported signals and consequences, with uncertainty recorded in unknowns. Review the compact file before sharing it or attaching it to another tool.

Data and privacy

Config, snapshots, Git evidence, summaries, caches, and jobs are stored locally. The Web queue is <data-root>/web-jobs.json, outside individual projects. Evidence can contain proprietary code, task text, comments, author identities, and repository URLs. The application does not encrypt this storage.

Network access depends on settings:

• Online collection authenticates to the selected task source even before compatible snapshot reuse. Enabled hosting enrichment calls its SCM API. Managed clones clone/fetch through Git; localPath checkouts are not fetched by the tool.
• Remote summary AI receives bounded task IDs, titles, descriptions, comments, hierarchy/tags, repository/branch names, commit subjects, changed paths/statistics, and PR/MR metadata. diff adds selected hunks. AI ranking sends bounded candidate task text, artifact identity/text, and matching paths; diff/adaptive modes may add local hunks.
• Local AI sends that input to the configured local endpoint. Task-source, SCM, and managed Git calls depend on their own settings. Disabling summary AI does not disable separately configured AI ranking.
• Default local matching/ranking does not send code context to an embedding or semantic-search service. export reads saved local data without provider calls.

Diff input is selected locally as complete relevant hunks within configured budgets; binary/generated files, lock files, minified files, and build/vendor output are excluded. Common credential patterns are redacted before model requests; this cannot guarantee removal of every secret or confidential detail. Metadata may itself be sensitive. Review provider, endpoint, and mode before enabling AI. Local AI accounting contains counts and identities, not prompts or diffs. The application has no implemented telemetry reporting.

Limitations and troubleshooting

Reconstruction depends on available committed history, readable tracker data, and matching references. Contextual suggestions inspect bounded samples (up to 40 eligible branches and 50 recent commits), rather than all history. Uncommitted changes and inaccessible source data cannot establish implementation. Ranks are sorting aids, not probabilities; incomplete evidence and uncertainty remain visible.

Changing a project's source provider, site, or authenticated account after evidence exists may be rejected to prevent mixed namespaces. Create a separate project; data is not automatically migrated or erased. Scope/filter changes within the same source refresh its snapshot while preserving historical artifacts and curated rows. Online collection checks current authentication; offline export cannot recheck permissions. After changing access, perform a forced online collection.

For a support report, collect ce --version, Node/Git versions, OS, the exact command, expected/actual behavior, and a minimal sanitized config or synthetic reproduction. Include relevant error categories or evidence status. Remove keys, authorization headers, credential-bearing URLs, private task/code/comment text, personal identities, and local paths from logs or attachments. Do not attach your actual config or entire data directory.