Add the issue and software-project core subtypes; move the development fields off task and project #3735

Overview

A database is shared by teams that do not all write software, and task and project carry development state today: every task has pull_request and commits, every project has repository and checkout_path. This issue adds two built-in subtypes that hold that state, issue (extends task) and software-project (extends project), typed end to end, and removes the fields from the base types. A plain task and a plain project end up with no development state.

Node type sequence classification: two core subtypes. issue: parent task, same category as task. software-project: parent project, same category as project.

Problem Statement

• A hiring task shows a pull request field and a campaign project shows a repository.
• The review workflow (Adapt the community implement and review workflows into NodeSpace delivery skills: test-first, review by a separate session, a decision per finding #3720) needs two more statuses. Added to task, they appear on every team's tasks, because a database has one task schema.
• Development fields, statuses and rules have no home other than the types everyone uses.

Proposed Solution

• issue extends task. Own fields: pull_request (link), commits (link list), moved from task. Own statuses added to the inherited status field, each with maps_to: changes_requested → in_progress, ready_to_merge → in_review. Everything else inherited.
• software-project extends project. Own fields: repository (link), checkout_path (string, local_only), moved from project. Everything else inherited.
• task and project lose those fields. No fallback read of the old location, no migration: change the shape and reset the database.
• Typed end to end: registry entries, schemas, wire types IssueNode and SoftwareProjectNode with typed updates, proto, daemon, app-lib, generated TypeScript, and frontend components following the *Node naming.
• Binding a checkout matches the git remote against software projects only.
• Seeded skills, Plays and queries that write or read the moved fields are updated (the implementing skill records the pull request and commits on an issue).

Documentation

• ADR-098 - the decision: the two subtypes, their fields and statuses, what a task-scoped and an issue-scoped rule sees
• ADR-078 - extends, projection, enum values on an inherited field with maps_to
• ADR-086, ADR-087, ADR-089 and the node type sequence - mandatory for this change
• creating-node-types.md §6 - the core subtype recipe
• ADR-093 §4 and §8 - a checkout belongs to a project; launched sessions run in the project's checkout
• Updates: components/node-types.md gains issue and software-project sheets and loses the four fields from task and project (pushed just before bun run merge); components/seeded-nodes.md where a seeded skill names the fields

Architecture Impact

Implements ADR-098, which amends ADR-092 §4 and §9. The design note is on nodespace-docs main.

Acceptance Criteria

• issue and software-project exist as core subtypes in the registry, each with a seeded closed schema, a wire type and typed update, and generated TypeScript
• task has no pull_request or commits; project has no repository or checkout_path; writing one of those keys on the base type is refused as undeclared
• An issue accepts changes_requested and ready_to_merge; a plain task refuses them
• A rule or query written against task matches issues and reads changes_requested as in_progress and ready_to_merge as in_review; one written against issue reads the stored value and the issue's own fields
• The seeded task rules (spec, lineage, blockers, criteria), the parent roll-up and Ready tasks behave on an issue as they do on a task, including on a move between two issue statuses that map to the same core status; what each does is written down
• A checkout binds to a software project by its repository and never to a plain project; a session launched for a software project runs in its checkout_path
• The app shows an issue and a software project with their own fields, and a plain task and a plain project without them
• No node_type literal comparison is added; subtype checks go through the registry
• bun run gen:types output committed; bun run types:check and bun run node-types:check pass
• Tests per the node type sequence: registry, wire contract, typed update, closed-schema rejection, subtype inheritance, status vocabulary and maps_to
• Code passes bun run quality:fix and bun run test:changed

Technical Specifications

Reference Files

• packages/nodespace-types/src/core_type.rs - CoreNodeType; task.rs, convert.rs and the project wire type
• packages/core/src/models/core_schemas.rs, packages/core/src/db/core_type_shape.rs
• packages/core/src/playbook/cel.rs, graph_resolver.rs, engine.rs - scope-relative reads and maps_to (already implemented and tested for user-defined subtypes)
• packages/proto/proto/node_service.proto, packages/daemon/src/services/node_service.rs, agent_session_service.rs, packages/desktop-app/app-lib/src/commands/nodes.rs
• packages/desktop-app/src/lib/design/components/task-node.svelte, components/property-forms/task-schema-form.svelte, components/viewers/ai-chat-pty-session.svelte, services/adapter-core.ts
• packages/skill/plugins/shared/nodespace-session.ts - resolving the project for a checkout
• packages/agent/src/seeds/skills/implementing-a-task.md and the seeded Plays and queries

Implementation Details

• How a core subtype declares added values with maps_to on an inherited field in its seeded schema needs settling first; the mechanism exists for schemas a user writes.
• The typed status of an issue needs the two values by name; decide whether that is its own enum or a variant set on the shared one, and keep one definition (ADR-086).
• Existing ai-chat-native / ai-chat-pty and tool-native are the core subtype precedents; none extends a concrete type with nodes of its own, so check what a query for task and a board of tasks do when issues are in the result.
• A rule that needs pull_request or the new statuses is written against issue: a rule against task cannot see them.
• Model-facing text in packages/agent is pinned by the prompt snapshot; regenerate with UPDATE_GOLDEN=1 and review the diff.

Related Issues

• Adapt the community implement and review workflows into NodeSpace delivery skills: test-first, review by a separate session, a decision per finding #3720 (the review flow, which uses the two statuses)
• Adapt the community spec, plan-review and ticket-splitting workflows into NodeSpace planning skills #3719 and Shape a standalone task when it is created, and let a task wait on a person (waiting status and waiting_on) #3722 (the skills that create issues)
• Remove requires_spec from task; the spec rule applies only to a task that links a spec #3718 (the last change to task's fields)

Non-Goals

• Several repositories on one software project
• A status for waiting on an answer
• Retyping a task into an issue, or a project into a software project
• Moving the spec rule to issue