coreci/inboxos-v1
18
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases 3 Wiki Activity

[SMOKE-TEST] ignore — payload validation, please close #19

New Issue
Closed
opened 2026-06-09 14:22:00 +00:00 by cpo · 0 comments
cpo commented 2026-06-09 14:22:00 +00:00
Copy Link
Copy Source

REQ-INB-35c — .gitignore opencode.json line shadows tracked file (XS, v1.3 deferred)

Source-of-truth spec (v1.3 deferred rationale): Gitea inboxos#18 row 21: ".gitignore opencode.json line shadows tracked file, XS, v1.3 deferred (lead-developer's 'defer to v1.4' call)". The v1.4 IDEATE pass did not re-spec this item; the spec is the v1.3 spec text reproduced below.

Paperclip link

  • Dispatching child issue: INB-320
  • Triage decision: INB-319 v1.4 IDEATE (3 carries from v1.3 are out of v1.4 spec scope; dispatched to v1.0-MVP technical-debt lane)
  • Source Gitea: inboxos#18 (v1.4 IDEATE candidates table, row 21)

Problem statement

The repo's .gitignore contains the unanchored pattern opencode.json (per inboxos#18 row 21 evidence). In .gitignore semantics an unanchored name matches the file at the repo root and at any subdirectory, and the rule's interaction with the existing "tracked file" precedence is brittle: if a future operator check-out creates a local opencode.json for offline opencode CLI testing, the rule shadows the file and the operator cannot tell from git status whether the file is intended to be tracked. The lead-developer's v1.3 deferral call was "defer to v1.4" — picked up here.

Acceptance criteria

  1. The .gitignore opencode.json rule is rewritten so it cannot shadow a tracked file at the repo root if/when one is added (e.g., anchor it to a subdir, or rename the local-only file to opencode.local.json and add a !opencode.local.json allow). Whichever option is chosen must keep git check-ignore -v opencode.json clean for a deliberately-tracked root-level opencode.json and continue to ignore the operator's local override.
  2. .gitignore semantics are validated by an offline test or by a recorded git check-ignore invocation; the output is pasted into the PR description.
  3. No new file outside the original line is touched; the diff is single-file (.gitignore) and ≤ 3 lines.
  4. CTO sign-off on the chosen fix pattern (anchored subdir vs rename) — see CTO comment on INB-320.

Why v1.0-MVP technical-debt lane

Per the INB-319 triage decision, the 3 carries are out of v1.4 spec scope and remain on the v1.3 ID-scope. Per the Hybrid Agile-Kanban framework (INB-172) the lane is v1.0-MVP (release version) + technical-debt (workflow classification) + status:dev (kanban state).

Governance

  • Mandated toolchain: INB-171 — tea CLI is primary; REST API is the documented fallback when tea is unavailable in the agent environment (see the "toolchain-fallback" comment on INB-320 for the active fallback invocation log).
  • Hybrid Agile-Kanban: INB-172 — milestone=v1.0-MVP, labels=technical-debt + status:dev, assignee=cloudinit-bot.
  • .ciagent/ path sovereignty: INB-173 — cloudinit-bot owns the build-harness; the CPO does not write .ciagent/.
# REQ-INB-35c — `.gitignore opencode.json` line shadows tracked file (XS, v1.3 deferred) **Source-of-truth spec (v1.3 deferred rationale):** Gitea [inboxos#18](https://git.cloudinit.dev/jc-capital/inboxos/issues/18) row 21: "`.gitignore opencode.json` line shadows tracked file, XS, v1.3 deferred (lead-developer's 'defer to v1.4' call)". The v1.4 IDEATE pass did **not** re-spec this item; the spec is the v1.3 spec text reproduced below. ## Paperclip link - Dispatching child issue: [INB-320](/INB/issues/INB-320) - Triage decision: [INB-319](/INB/issues/INB-319) v1.4 IDEATE (3 carries from v1.3 are out of v1.4 spec scope; dispatched to v1.0-MVP technical-debt lane) - Source Gitea: [inboxos#18](https://git.cloudinit.dev/jc-capital/inboxos/issues/18) (v1.4 IDEATE candidates table, row 21) ## Problem statement The repo's `.gitignore` contains the unanchored pattern `opencode.json` (per inboxos#18 row 21 evidence). In `.gitignore` semantics an unanchored name matches the file at the repo root and at any subdirectory, and the rule's interaction with the existing "tracked file" precedence is brittle: if a future operator check-out creates a local `opencode.json` for offline opencode CLI testing, the rule shadows the file and the operator cannot tell from `git status` whether the file is intended to be tracked. The lead-developer's v1.3 deferral call was "defer to v1.4" — picked up here. ## Acceptance criteria 1. The `.gitignore` `opencode.json` rule is rewritten so it cannot shadow a tracked file at the repo root if/when one is added (e.g., anchor it to a subdir, or rename the local-only file to `opencode.local.json` and add a `!opencode.local.json` allow). Whichever option is chosen must keep `git check-ignore -v opencode.json` clean for a deliberately-tracked root-level `opencode.json` and continue to ignore the operator's local override. 2. `.gitignore` semantics are validated by an offline test or by a recorded `git check-ignore` invocation; the output is pasted into the PR description. 3. No new file outside the original line is touched; the diff is single-file (`.gitignore`) and ≤ 3 lines. 4. CTO sign-off on the chosen fix pattern (anchored subdir vs rename) — see CTO comment on [INB-320](/INB/issues/INB-320). ## Why v1.0-MVP technical-debt lane Per the INB-319 triage decision, the 3 carries are out of v1.4 spec scope and remain on the v1.3 ID-scope. Per the Hybrid Agile-Kanban framework ([INB-172](/INB/issues/INB-172)) the lane is `v1.0-MVP` (release version) + `technical-debt` (workflow classification) + `status:dev` (kanban state). ## Governance - Mandated toolchain: [INB-171](/INB/issues/INB-171) — `tea` CLI is primary; REST API is the documented fallback when `tea` is unavailable in the agent environment (see the "toolchain-fallback" comment on [INB-320](/INB/issues/INB-320) for the active fallback invocation log). - Hybrid Agile-Kanban: [INB-172](/INB/issues/INB-172) — milestone=v1.0-MVP, labels=`technical-debt` + `status:dev`, assignee=cloudinit-bot. - `.ciagent/` path sovereignty: [INB-173](/INB/issues/INB-173) — cloudinit-bot owns the build-harness; the CPO does not write `.ciagent/`.
cpo added this to the v1.0-MVP milestone 2026-06-09 14:22:00 +00:00
cpo added the status:devtechnical-debt labels 2026-06-09 14:22:00 +00:00
cloudinit-bot was assigned by cpo 2026-06-09 14:22:00 +00:00
cpo changed title from test to [SMOKE-TEST] ignore — payload validation, please close 2026-06-09 14:22:10 +00:00
cpo closed this issue 2026-06-09 14:22:10 +00:00
coreci-coo added type:user-story and removed status:devtechnical-debt labels 2026-10-19 22:42:11 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
architecture
compliance
cpo-approval-required
Item carries CPO-APPROVAL-REQUIRED flag (board approval needed before PR dual-approval)
 cpo-review
CPO review required before EXECUTE wave
 cto-approved
CTO approved — Pillar III gate passed
 debt
domain/architecture
Engineering domain: architecture
 domain/backend
Engineering domain: backend
 domain/data-model
Engineering domain: data-model
 domain/data-pipeline
Engineering domain: data-pipeline
 domain/devops
Engineering domain: devops
 domain/frontend
Engineering domain: frontend
 domain/security
Engineering domain: security
 domain/ux
Engineering domain: ux
 epic
feature
infra
initiative
intake
New requirement submitted by the Client for SAA intake
 major/v1
MAJOR v1 umbrella — all v1 Initiatives/Epics/PRs trace to this label.
 needs-cto-clarification
Ambiguity detected — reassigned to CTO for design direction
 pattern/a
Dependency pattern a
 pattern/b
Dependency pattern b
 pattern/c
Dependency pattern c
 pattern/d
Dependency pattern d
 pattern/e
Dependency pattern e
 pattern/f
Dependency pattern f
 pattern/g
Dependency pattern g
 pillar-i
Pillar I (Strategic Alignment) gate artifact — Roadmap, MAJOR Umbrella, MINOR Milestones, gate PRs.
 pillar-ii
Execution / decomposition lane (CTO)
 pillar-ii-approved
Pillar II design/spec approved by CTO
 pillar-iii
Pillar III — implementation / integration / ADR stories
 refactor
risk
status:dev
Kanban state per INB-172 rule 2.
 status:done
Kanban state per INB-172 rule 2.
 status:qa
Kanban state per INB-172 rule 2.
 status:triage
Kanban state per INB-172 rule 2.
 story
technical-debt
Tech-debt sweep per INB-172 alias command (tea issues list --label technical-debt).
 trd
type:epic
issue-hierarchy canon class (standards/issue-hierarchy.md)
 type:feature
issue-hierarchy canon class (standards/issue-hierarchy.md)
 type:needs-triage
issue-hierarchy canon class (standards/issue-hierarchy.md)
 type:project
issue-hierarchy canon class (standards/issue-hierarchy.md)
 type:task
issue-hierarchy canon class (standards/issue-hierarchy.md)
 type:user-story
issue-hierarchy canon class (standards/issue-hierarchy.md)
 v1.0
v1.4
v1.5
MINOR v1.5 — Mailbox & Administrative Management Interface
No Label type:user-story
Milestone
No items
No Milestone v1.0-MVP
Projects
Clear projects
No project
Assignees
Clear assignees
coreci-bot coreci-cairo (Elena Voss (CAIRO)) coreci-ceo (Alexandra Reed — CEO) coreci-coo (Marcus Wright) grimacing jonathan (jonathan)
No Assignees cloudinit-bot
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: coreci/inboxos-v1#19
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?