Bump RFC — Incan Project

Overview

RFCs move through four statuses. Each transition requires specific file edits, GitHub actions, and prerequisites.

Read the RFC's current Status: field, then follow the matching section below.

Draft → Planned

Prerequisites

All answered: nothing open under ## Unresolved questions; settled record under ## Design Decisions (see review-rfc → Planned+ rule). No fake questions.

Before bumping, verify:

• No open bullets under ## Unresolved questions (if present). No disguised open items under Design Decisions.
• At least one review round has been completed (use /review-rfc if not done).
• GitHub issue exists and is linked in the RFC header.
• User has confirmed the bump (ask if unclear).
• Discuss any open design decisions with the user.

File changes

Outcome: Planned+ rule — no ## Unresolved questions; tail is ## Design Decisions only.

1. Both ## Design Decisions and ## Unresolved questions: merge remainder into Design Decisions, drop ## Unresolved questions.
2. Only ## Unresolved questions: rename → ## Design Decisions.
3. Only ## Design Decisions: leave as-is.
4. Strip EOF <!-- Rename this section to "Design Decisions"... --> if present.
5. Status: Draft → Status: Planned.

GitHub actions

# Remove RFC label, add feature label
gh api repos/dannys-code-corner/incan/issues/<NNN>/labels/RFC -X DELETE
gh api repos/dannys-code-corner/incan/issues/<NNN>/labels -X POST --input - <<'EOF'
{"labels":["feature"]}
EOF

# Post a status comment
gh issue comment <NNN> --repo dannys-code-corner/incan --body \
  "RFC has moved to **Planned** status. Design is settled; implementation can begin."

Planned → In Progress

Prerequisites

• At least one implementation PR has been opened or a contributor has picked up the work.
• User has confirmed the bump.

File changes

When an implementation PR exists, record its link in RFC PR and retain other implementation PR links. If work has started without an implementation PR, leave RFC PR as — until one is opened. Never use a proposal or documentation-only PR for this field.

After the ## Layers affected section, add a ## Progress Checklist section. An RFC describes the end state, so a delivery plan with phases belongs on the GitHub issue, not in the RFC.

## Progress Checklist — fine-grained - [ ] items, grouped by area. These will be ticked as PRs land. Example shape:

## Progress Checklist

### Spec / design

- [ ] Lock down edge cases for `<X>` and add to "Design Decisions".

### Parser / AST

- [ ] Lexer: emit new token for `<keyword>`.
- [ ] Parser: parse `<construct>` in declaration/expression position.
- [ ] AST: represent as `<NodeKind>` with correct span.
- [ ] Formatter: round-trip `<construct>` stably.

### Typechecker

- [ ] Validate at declaration sites.
- [ ] Resolve in expression positions.
- [ ] Error: `<diagnostic name>` for invalid usage.

### Lowering / IR

- [ ] Lower `<construct>` to `<IrNode>`.

### Emission

- [ ] Emit correct Rust for `<construct>`.

### Stdlib / Runtime

- [ ] Declare in `stdlib/<module>.incn` (if applicable).
- [ ] Wire Rust backing type in the owning component's facet, `loaves/stdlib/<component>/rust/` (if applicable).

### Tests

- [ ] Existing check cases extended for accepted syntax and valid usage.
- [ ] Existing check cases extended for invalid usage → correct diagnostic code.
- [ ] Existing behavior cases extended for `<construct>` in expression position and observable execution.
- [ ] Smallest relevant case/area selectors pass during development; affected whole families pass at commit points, per `workspaces/contracts/README.md`.

### Docs

- [ ] Update relevant docs-site pages.
- [ ] Add release notes entry.

3. Update the header: Status: Planned → Status: In Progress.

GitHub actions

Post the implementation plan to the GitHub issue, where delivery is tracked:

gh issue comment <NNN> --repo dannys-code-corner/incan --body \
  "RFC has moved to **In Progress**. Implementation plan below; the RFC carries the progress checklist.

<the implementation plan and checklist>"

In Progress → Implemented

Prerequisites

• All - [ ] items in the Progress Checklist are - [x].
• Implementation is complete and covered by a merge-ready PR, or already merged to main.
• Required local and/or CI verification has passed for the implementation PR.
• Release version is known.
• User has confirmed the bump.

File changes

1. Update the header: Status: In Progress → Status: Implemented.
2. Fill the release field with the actual Incan release version:
   • If the RFC uses Shipped in:, set Shipped in: vX.Y.
   • If the RFC uses Implemented version:, set Implemented version: X.Y.Z.
3. Move the RFC document into workspaces/docs-site/docs/RFCs/closed/implemented/ and keep the same filename.
4. Optionally rename ## Progress Checklist → ## Implementation log to signal it is historical rather than active.

GitHub actions

Ensure the implementation PR body includes a closing keyword for the issue, for example Closes #<NNN>. Do not manually close the issue as part of the RFC bump; the PR merge should close it.

Optionally post a traceability comment while the PR is still open:

gh issue comment <NNN> --repo dannys-code-corner/incan --body \
  "RFC has moved to **Implemented** in the implementation PR. Implementation is complete and targeted for vX.Y; the issue will close when the PR merges."

Release notes

Add an entry to workspaces/docs-site/docs/release_notes/<vX_Y>.md following the project's release notes style:

- **<Area>**: <One-line description of the feature> (RFC NNN, #<issue>)

Quick reference